How to write a website brief that leads to a better proposal

Define the result and the starting point

Write one primary goal in plain language: generate suitable consultation requests, sell a defined catalogue, support a new service or make an existing business easier to understand. Add the problems you see today. For example, visitors may ask for services you do not offer, miss important preparation information or abandon a long enquiry form.

Include any trustworthy baseline you have, such as enquiry volume, common sales questions or frequently visited pages. Explain how success will be judged. A clearer enquiry with the right project details may matter more than a larger number of unqualified submissions.

Describe who will use the website

List the main audiences and the decisions each needs to make. A homeowner, a business purchaser and a potential partner can require different evidence even when they buy related services. Identify who needs a quick answer, who compares detailed capabilities and who must share information with colleagues before approving a project.

Describe service areas and language needs accurately. If a French experience is required, include navigation, forms, confirmation messages and ongoing content ownership in the scope. Accessibility should be considered from the start, including the ways people navigate, read and complete tasks.

Outline page types and the content behind them

A list of page types is often more useful than a raw page count. Identify service pages, case studies, articles, product pages, team profiles or location pages, then explain what information each needs. Show which content already exists, who can approve it and what must be written, photographed or designed.

Separate real proof from material still to be collected. Client work, testimonials, credentials and performance claims need checking before publication. Add brand assets and a few reference websites with specific observations: readable service explanations, effective mobile navigation or a helpful comparison table. References should guide decisions rather than invite copying.

Specify the enquiry and the systems it enters

Describe the information needed to respond usefully to a lead. That may include service interest, location, existing website, timing and a short project description. Explain who receives the request and what they do next. Decide whether the website is requesting an appointment or confirming a real booking; the interface should make that distinction clear.

List existing tools by purpose: customer records, scheduling, payments, email, reporting or chat. Note what must connect at launch and what can wait. For AI assistance, define approved information, tasks it can perform and when it must hand over to a person.

Make the proposal and handover reviewable

Share your budget range and target timing if you have them, along with fixed dependencies such as a product launch or content approval. Ask the proposal to state assumptions, deliverables, revision boundaries, responsibilities and ongoing costs. Require clear ownership of the domain, content, accounts and any portable source or exports that form part of the agreement.

Agree on acceptance criteria before design starts: essential journeys work on phones, forms reach the intended destination, important existing URLs are handled, and the team can maintain the content it owns. Include training and support expectations so the project ends with an operable website and an understood next step.

Your planning checklist

• State the main business goal and the problem with the current customer journey.
• List audiences, page types, language needs and content owners.
• Describe lead qualification, response handling and required integrations.
• Ask for explicit assumptions, ownership, acceptance criteria and ongoing costs.

Common questions