How to Write a Website Brief—with a Free Template

A good website brief tells a supplier what the business needs to achieve, who the website serves and what work must be included. It should make quotes easier to compare without dictating every design decision. Start with the customer journey and the business facts, then describe constraints and responsibilities.

From the website builder’s side, a useful brief does not need to be full of technical instructions. We want to understand the business, the people it serves and what a successful website would help them do. Use this template to explain those things clearly, whichever supplier you choose.

Download the free editable website brief template. It is a plain-text file you can open in a document editor, complete and send to any supplier. No email signup is required.

Explain the business and the reason for the project

Describe what you sell, who buys it and where you operate. Then explain why you need website work now. Is the existing site inaccurate, difficult to update, generating unsuitable enquiries or unable to support a new service?

Distinguish evidence from impressions. “The booking link fails on mobile” is a specific finding. “The website feels dated” is a useful preference to discuss, but it does not identify the whole business problem.

Describe the audience and their main tasks

List the people the site must help and the decisions they need to make. A prospect comparing suppliers needs different information from an existing customer looking for support.

For a hypothetical commercial cleaning business, the priority visitor might be an office manager checking service coverage, working arrangements and how to request a site visit. Those needs suggest a clearer brief than “a modern website with wow factor”.

Choose the main next step and explain what happens after it. If the business cannot offer instant booking, do not ask the design to imply that it can.

List pages and required features

Give an initial page list, but invite the supplier to suggest a better structure. Separate content from functionality: an About page is different from a customer login or a booking integration.

• Essential: work required for the first release to function.
• Useful: improvements to price separately if the budget allows.
• Later: ideas that should inform planning but are outside the first scope.

Describe each feature through a real example. Instead of “integrate our CRM”, explain what should happen when a form is submitted, which fields must transfer and who receives failures. Provide the product name and account context without including passwords.

Be clear about content responsibilities

State which words, photographs, logos and brand materials already exist. Confirm whether they are approved and usable. Identify anything the supplier needs to create or source.

If copywriting is required, explain who will provide business facts and who can approve the result. Legal and privacy information needs an appropriate owner too; it should not be assumed to appear automatically as part of design.

Include examples of tone and design you like, with a reason for each. “The service information is easy to compare” helps a supplier more than “make ours like this”. Avoid asking them to copy another business’s content or design.

Record the existing technical situation

List the domain, current platform, hosting arrangement and important connected services. Note what you can access and what is uncertain. Share credentials securely only when needed, never in a brief circulated to several potential suppliers.

If replacing a site, identify important pages, downloads and search traffic that should be considered in the migration. Include email, booking and payment dependencies. Our ownership guide helps you establish the account position.

Give a realistic budget and timetable

A budget range lets suppliers propose an appropriate scope. Say whether it covers the build alone or also copy, imagery, hosting and ongoing support. Ask for optional items to be separated so you can make informed trade-offs.

Explain any genuine deadline and its reason. Include your own approval capacity: a supplier cannot meet a tight launch date if essential service information will arrive after it. Ask for dependencies and milestones rather than a confident date without assumptions.

Define completion and ongoing support

Describe what you expect at handover: tested customer journeys, mobile review, agreed search setup, editor training, account access and recovery arrangements. Use the launch checklist as a starting point.

Ask suppliers to explain ongoing fees, support coverage, response arrangements and how you leave. Clarify rights in the work and any third-party licences. These details make the project easier to operate after the initial excitement of launch.

A brief you can copy into an email

1. Our business and the customers we serve.
2. Why we are commissioning this work.
3. The main visitor tasks and desired next step.
4. Required pages and essential features.
5. Existing content and work we need supplied.
6. Current platform, accounts and integrations.
7. Budget range, deadline and approval owner.
8. Launch checks, training and support expectations.
9. Questions we want the proposal to answer.

Keep unknowns visible. It is reasonable to ask a supplier to help determine the structure or platform; simply make that discovery work part of the scope. Send the same version to each shortlisted supplier and use our supplier questions to compare the responses fairly.