A website brief gets useful quotes when it describes what the site must help people do, what already exists and who will supply each piece of work. You do not need technical jargon or a finished sitemap. You do need clear audiences, priority tasks, content and integration responsibilities, and a definition of what counts as finished. Send the same brief to every supplier and you can compare proposals on scope rather than on presentation.
What should a website brief include?
A good brief can be just a few pages long. It covers the business context, the people the site serves, the work involved and how you will judge the result. Use this outline as a starting point.
| Section | What to include |
|---|---|
| Business context | What you sell, where, and why the site is changing now |
| Audiences and tasks | Who visits, what they need to decide, the action you want |
| Priority pages | A provisional page list, each page with a job |
| Content | What exists, what needs rewriting, who writes and approves |
| Integrations | Forms, booking, CRM, payments and the process behind each |
| Technical and ownership | Domain, hosting, accounts, existing URLs to migrate |
| Acceptance and timing | What “finished” means, the deadline, the decision maker |
| Budget approach | A range or the factors that matter, if you can share them |
If you are unsure what budget range is realistic, our website cost guide explains the factors that move the price.
How do you describe users and their tasks?
A page list tells an agency how much content you expect, but not what the site needs to accomplish. Start with the people who will use it and the decisions they need to make. A prospective customer may need to compare services and request an estimate. An editor may need to update projects without a developer. A sales manager may need enough enquiry context to route each request.
Describe each important task with a starting point and a successful outcome. “A modern website” leaves scope open; “help office managers request a relocation quote with dates and both locations” gives designers a concrete job. Then give each priority page a job too. This stops a visually attractive site being called complete when the real task still needs a manual workaround.
What hidden work should the brief expose?
Many differences between quotes come from work that one supplier assumed and another did not. List languages, copywriting, photography, existing pages to migrate, forms, booking tools and other integrations. Mark what already exists, what needs review and what must be created, and state who supplies and approves each item. A launch date that assumes finished content is very different from one that includes interviews and production.
For integrations, describe the business process rather than just naming the software. Explain what information should move, which system owns the record and what should happen if the connection fails. A booking integration may involve availability, confirmation, cancellation and staff notification, which is far more work than linking to an external booking page.
If you are replacing an existing site, say so and list the pages that currently bring visits or enquiries. Migration deserves its own line in the quote; our website redesign SEO checklist shows what that work involves, and Google’s guidance on site moves with URL changes explains why redirects matter.
How do you define when the work is finished?
Ask suppliers to quote against agreed deliverables: templates, page population, mobile behaviour, accessibility checks, redirects, analytics and training. If accessibility matters to your customers or sector, name the standard you expect, such as the W3C’s Web Content Accessibility Guidelines, rather than simply writing “accessible”. Specify how you want enquiries measured too; tracking forms, calls and qualified leads is easier to build in from the start than to add later.
Write an acceptance scenario for each essential function:
- An editor can create a project, add approved images, publish it in the required language and correct a mistake.
- A prospective customer can choose a service, submit a valid enquiry and receive the promised confirmation.
- Your team can find the resulting enquiry and respond to it.
Separate essential launch requirements from improvements that can follow. Ask the supplier to state assumptions wherever a requirement is uncertain, and to say whether discovery work is needed before a fixed price.
Who owns decisions, accounts and support?
Name the decision maker and the person who approves copy and designs, with realistic review deadlines. Delayed decisions can move the launch even when development is on schedule. Give a target date and explain whether it is fixed by an event or flexible.
Include ownership and handover. Ask which accounts, assets and documentation you will receive, who handles domain and hosting renewals, and how urgent problems are reported after launch. Ask how revisions and new requirements are priced. Ongoing care is a separate decision; our guide to website maintenance explains what a small business usually needs.
Finally, compare proposals against the same list rather than choosing the most attractive presentation.
An example to apply
Illustrative scenario, not a client case study.
“Three languages” can mean translated navigation only, fully translated content or independently maintained versions for different markets. State which you need and who supplies each translation. This single clarification can change content effort, page population, testing and the eventual handover far more than a colour preference, and it affects search setup as well, as our guide to multilingual website SEO explains.
Discuss your project
Send Devimus your audience, priority actions, existing site and deadline. We will reply with a proposal that writes down the assumptions, responsibilities and what is included.
Explore the relevant service · Request a free estimate