Website Brief Checklist: What to Prepare Before Asking for a Quote
A useful website brief explains who your business serves, what visitors need to accomplish and what the project must include. Prepare a page list, content inventory, functional requirements, account ownership details and an approval process before requesting quotations. You do not need to choose every technical detail yourself. You do need enough shared information for suppliers to price the same job and explain the assumptions behind their proposals.
Define the business problem before choosing features
Start with a short description of what is happening in the business. Customers may repeatedly ask for information that should be online. The sales team may receive enquiries for services you no longer offer. A retailer may have products on Instagram but no consistent way to present sizes, stock or delivery details. These are observable problems. “We want a modern website” is a design preference, which still leaves the commercial purpose unclear.
Describe the desired change in a sentence that a colleague could recognise. For example, a hypothetical training provider might write: “Visitors should be able to compare our three programmes and send an enquiry for the correct intake.” That statement gives the designer a reason to create a comparison, the writer a reason to explain eligibility and the developer a reason to pass the programme name into the enquiry.
Choose a main objective and a small number of supporting objectives. A site can sell, inform and recruit, but the homepage still needs a clear order of importance. Record how you currently handle the task and what evidence would show improvement. Keep promises proportional to what a website can influence. A clearer enquiry route cannot fix an unavailable product or an unanswered sales inbox.
Describe the customer and the decisions they make
Identify the people who will use the site rather than describing the audience as everyone. A new customer may need an explanation of your service. A returning customer may only need the telephone number. A procurement officer may need a company profile and project examples before inviting you to quote. Each group brings a different question and level of familiarity.
List the information a customer needs before taking the next step. For a professional service, this might include the scope, location served, typical process, relevant experience and how pricing is agreed. For a booking business, it may include availability, meeting point, inclusions and cancellation conditions. Use real sales conversations to build the list, then remove questions that do not affect the decision.
Describe the intended action in practical terms. “Generate leads” is less specific than “open a WhatsApp conversation about the selected service.” Name the person who receives that conversation and what happens after it arrives. If the website needs a detailed form, explain which fields help your team respond and which merely add effort. This audience work becomes the foundation for the website copy, navigation and calls to action.
Separate the page list from functional requirements
Create one list for pages and another for behaviour. Pages might include Home, About, Services, individual service pages, Work, FAQs and Contact. Behaviour might include appointment booking, product filtering, online payment, customer accounts or a connection to a customer relationship management system. A five-page website can be straightforward or technically complex depending on that second list.
For each page, write its main purpose, the content it needs and the next step it supports. Avoid adding pages only because a competitor has them. A dedicated service page is useful when it answers a distinct customer need in enough depth. Five nearly identical pages with a location name changed create more writing and maintenance without necessarily making the website more helpful.
For each feature, describe a real example of use. A booking requirement should explain whether customers choose a live time slot, request a callback or pay a deposit. These are different systems. If an integration is involved, name the existing tool and ask the supplier to confirm the connection method, limitations and recurring costs. Mark uncertain items as questions for discovery rather than treating every idea as an approved deliverable.
Inventory content, photography and brand materials
Make a simple inventory of what already exists. Include the logo files, brand colours, fonts, service descriptions, approved contact information, company registration wording where relevant, photographs and permission to show past work. Note which materials are final, which need updating and which have not been created. This reveals dependencies before a design schedule is promised.
Assign an owner to each missing item. “Client to provide content” is too broad when several people must contribute. Instead, identify who supplies product specifications, who approves service claims and who selects photographs. Give each item a practical deadline that leaves time for review. The build can move faster when the team is not trying to discover the offer while filling empty page layouts.
Check the quality and rights of visual assets. A screenshot copied from a supplier’s social account may not be suitable for a large hero image or licensed for reuse. Where new photography or illustrations are needed, include that in the scope. Write meaningful image descriptions for the brief so the visual supports the actual business. A generic office photograph cannot demonstrate a specialised installation, handmade product or completed interior.
Document platforms, access and ownership
Record your domain registrar, hosting provider, current website platform and any services that must remain connected. Include business email, analytics, payment providers, booking tools and newsletter software. Do not paste passwords into the brief. The supplier needs to know what exists; account permissions can be arranged through an appropriate invitation or access process once the work is agreed.
Clarify who owns the domain and service subscriptions. The business should know where renewal notices arrive and how the accounts can be recovered. If a supplier will manage hosting or maintenance, ask what is included, what happens when the agreement ends and how you obtain a usable copy of the site. These questions are especially important when comparing platforms with different hosting and export arrangements.
Describe who will edit the website after launch. A team publishing weekly articles needs a different workflow from a business changing its telephone number twice a year. Ask for the editing tasks to be demonstrated with realistic examples. If your preferred platform has not been selected, use our WordPress, Webflow and custom website comparison to prepare operational questions before deciding.
Set scope boundaries, approvals and a working schedule
A useful brief distinguishes essential launch requirements from later improvements. Essential means the business cannot use the site properly without it. Later work might include an expanded resource library, a second language or a customer portal that needs separate discovery. This distinction helps the supplier propose a manageable first release without quietly omitting an important requirement.
Name one person who consolidates feedback. Other colleagues can contribute, but a designer should not receive conflicting instructions through three different channels. Agree the review stages, how comments are recorded and what approval means. A round of feedback should be a coherent response to a complete draft rather than an unlimited stream of new directions.
Identify any real launch constraint and its reason. An exhibition, campaign or new service may justify a fixed date. Allow for content delivery, testing, revisions and approval instead of treating development time as the whole schedule. Ask what happens if an input is late or the scope changes. A written change process protects both the business budget and the delivery team’s ability to finish the agreed work.
Ask suppliers to explain the complete cost
Request a quotation that separates setup work from recurring costs. Design, development, content preparation, photography, integrations and product uploads may be priced differently. Domains, hosting, premium software and ongoing support may renew separately. A proposal is easier to compare when it names each responsibility rather than presenting one attractive number with broad exclusions underneath.
Ask how the quoted scope is measured. Page count alone does not describe a product catalogue, booking system or multilingual project. Confirm the number of products or variants, content templates, integration steps and revision stages where those affect the workload. If a quotation includes an allowance, ask what happens when it is exceeded and who approves the additional work.
Compare the same brief across suppliers and read the assumptions carefully. One proposal may include copywriting while another expects finished copy. One may include training and a backup while another ends at publication. Our website cost guide explains how to examine these components without relying on an unsupported market average. Choose the proposal that clearly addresses the business requirement and the ongoing operating model.
Prepare handover and launch acceptance criteria
Write a short list of checks that must pass before the project is accepted. The correct phone number should work. Enquiries should reach the intended person. Page content, product information and business details should be approved. The website should be usable on the devices your customers commonly use. These checks turn a vague impression of readiness into a reviewable handover.
Ask for ownership and maintenance information in a form your team can keep. That may include an account register without passwords, editing guidance, backup instructions, licence responsibilities and the support contact. If the site has forms or transactions, identify how failures are noticed and who investigates them. A website is an operating channel, so its responsibilities continue after the launch announcement.
Finish the brief with the questions that remain unanswered. You can request help deciding whether a feature is needed, how content should be organised or which platform fits the team. The purpose is shared understanding, not pretending to be a developer. When you are ready, send your brief through our website design service and ask for a written scope, cost and delivery plan that responds to it.
Common questions
How detailed should a website brief be?
It should explain the business goal, audience, required pages, features, available content and approval process. A clear short brief is more useful than a long document full of design adjectives. Add detail wherever it changes the workload or customer experience.
Do I need to choose a platform before requesting a quote?
No. Describe the editing tasks, integrations and ownership needs first. A supplier can recommend a platform and explain its tradeoffs. Ask them to show how it handles your actual work, including publishing, enquiries, backups and handover.
Can I request a quote before all the content is ready?
Yes, if you identify what is missing and who will create it. The quote should say whether copywriting, photography and content upload are included. Avoid accepting a launch date that assumes finished materials when none have been prepared.
