A useful website brief explains what the business needs to change, who the website serves and how the result will be checked. It gives suppliers enough context to estimate the same project, and gives your team a shared basis for decisions.
An example journey, shaped around your requirements.
Give the project a shared starting point.
Describe the business job before the page count.
Start with the action the website should help a customer take: request a quotation, compare a service, book a consultation or buy a product. Record the problem with the current journey and the evidence behind it. A request for “ten pages” does not explain why those pages matter.
For a hypothetical B2B supplier, the brief might say that procurement visitors need product specifications, delivery regions and a way to send a detailed enquiry. Those needs lead to a catalogue, specification downloads and a routed enquiry form. Treat this as a planning example, not a claim about a client result.
Separate your audiences and their questions.
List the two or three audience groups that have different decisions to make. For each, record what they already know, what they need to trust and what would stop them contacting you. Include both mobile visitors and people who need accessible interaction.
If you serve India and international buyers, specify actual service regions, languages, currency needs and who handles enquiries. An international audience does not automatically require separate country websites. Create different content only where the offering, process or information changes.
Inventory the content and the systems.
Create a page list with an owner for each piece of content. Identify existing URLs, useful articles, project images, product data and documents that must be retained. Record which assets you own and which still need permission or creation.
Then list the connections: CMS, CRM, payment provider, analytics, email, WhatsApp and any business API. State what each connection must do, who supplies access and what should happen when it fails. “CRM integration” is too broad to estimate until the fields, events and ownership are known.
Define acceptance in observable terms.
Replace words such as “premium”, “fast” and “SEO friendly” with reviewable criteria. Examples include a working keyboard navigation path, approved responsive layouts, successful form validation and delivery, editable service pages, a correct sitemap and redirects for agreed legacy URLs.
Google’s starter guide covers useful content, understandable structure and search discovery. These are build requirements you can inspect; they do not guarantee rankings. Accessibility should also be planned throughout the project, as W3C’s guidance explains, rather than added as a final visual check.
Make assumptions and exclusions visible.
Record the target launch date, the review team and how quickly they can approve content. State whether the estimate includes copywriting, original photography, data migration, ongoing maintenance and third-party subscriptions. Keep the budget range separate from the supplier’s estimate.
Ask each supplier to identify its assumptions, dependencies and change process. Compare the same deliverables and acceptance criteria across proposals. A cheaper quote may cover less work; a higher quote may include activities your team can supply. The brief makes these differences easier to discuss.
The minimum useful brief.
Use this table to check whether the project can be estimated without major hidden assumptions.
Area
What to include
Evidence of readiness
Common gap
Outcome
Customer action and business objective
A specific task and an evaluation method
Generic wishes such as “more growth”
Content
Pages, assets and owners
A page inventory with missing inputs marked
Assuming all copy and images are ready
Connections
Systems, data and responsibilities
Named integrations and account owners
A list of tools without behaviour
Acceptance
What must work before launch
Reviewable criteria and sign-off roles
Undefined terms such as “perfect SEO”
Take the working template.
Copy this editable Markdown template into your document or share it with your team.
Make it as long as the decisions require. A small business site may need a few structured pages plus an asset inventory; a portal or store needs more detail about data and workflows. Clarity matters more than length.
Should I decide the technology first?
Record constraints such as an existing CMS, internal skills or a required integration. Let the customer tasks and editing needs guide the platform choice, then ask suppliers to explain their recommendation.
Can I use this brief with another agency?
Yes. The downloadable template is a practical starting point you can adapt for your own project and share with prospective suppliers.
