A website brief is not a mood board. It is a buying document that helps agencies understand the business, price the work honestly, and expose delivery risks before the proposal becomes persuasive. The best brief is specific enough to prevent vague scope and short enough that every stakeholder can use it in a discovery call.
This template is for founders, marketing leads, and operations owners preparing agency outreach. It works for service-business redesigns, B2B marketing sites, ecommerce rebuilds, CMS migrations, and content-heavy website updates. Use it before sending an RFP or booking agency calls. Our editorial standards are explained on the about page and in the editorial policy.
One-page context
Start with the company, audience, current website, and reason for the rebuild. Keep this section plain. An agency should be able to repeat the business goal back to you without translating jargon. If the goal is better lead quality, say that. If the goal is easier campaign publishing, say that. If the site needs to protect search traffic while changing CMS, say that early.
A useful context section includes the company model, primary audiences, current conversion paths, top services or products, geographic focus if relevant, and the most painful limits of the current site. It should also name the decision makers and the team that will operate the site after launch. This prevents the agency from designing for a stakeholder group that will not own the website day to day.
Brief template structure
| Section | What to include | Why it matters |
|---|---|---|
| Business goal | Primary outcome, audience, conversion path, success measure | Aligns the redesign with commercial value |
| Current-site problems | Pages that fail, workflows that slow the team, trust gaps | Shows what the new site must fix |
| Pages and content | Launch sitemap, recurring content types, ownership | Prevents late content delays |
| CMS and editing | Who edits what, approval flow, component needs | Controls future operating cost |
| Integrations | Forms, CRM, analytics, consent, email, ecommerce | Avoids hidden technical scope |
| SEO migration | Current URLs, ranking pages, redirects, metadata | Protects existing search value |
| Support | Stabilisation, retainer, urgent fixes, training | Makes post-launch ownership explicit |
Do not treat this table as paperwork. It is the structure that lets every agency respond to the same problem. If one agency prices migration and another assumes it is out of scope, the proposals are not comparable. If one agency includes CMS training and another includes only a walkthrough, the apparent price difference may be misleading.
Pages, content, and workflows
List the pages that must exist at launch. Separate required pages from optional improvements. Required pages might include home, services, product categories, case studies, resources, contact, legal pages, and campaign landing pages. Optional improvements might include advanced filtering, calculators, interactive tools, or future content hubs.
Then list the content your team expects to update regularly. This may include service descriptions, pricing notes, case studies, team bios, blog posts, product pages, resource downloads, event pages, or landing pages. The agency needs this information before recommending a CMS structure. A site that looks simple on launch can become expensive if the recurring content model was never designed.
Name content owners. Who writes copy? Who approves legal claims? Who supplies images? Who migrates old articles? Who loads final content into the CMS? Who signs off metadata? Content work often causes more delay than design work because everyone assumes someone else owns it. Put ownership in the brief.
CMS and ownership
Write down who needs to edit the site after launch and what they must be able to change. A marketing manager may need to publish landing pages. A founder may need to update service descriptions. A content editor may need to add case studies. A developer may retain control of global components, integrations, or complex templates. The brief should describe this operating model clearly.
Ask agencies to explain what editors can do safely, what requires developer support, and what documentation will be delivered. For Webflow or similar visual CMSs, this means components, collections, editor roles, and page limits. For WordPress, it means roles, plugins, staging, updates, backups, and security. For custom or headless builds, it means schemas, preview, deployment, and future engineering ownership.
The ownership section should also name access. Domains, hosting, analytics, search console, tag manager, CRM, form destinations, image libraries, design files, and source repositories all matter. If access is delayed or owned by the wrong person, launch can stall. If access is never transferred, the buyer may remain dependent on the vendor for routine work.
SEO migration and launch risk
Include current high-value URLs, traffic-driving pages, metadata expectations, redirect needs, and any domain or hosting changes. Google's site move guidance, redirect guidance, and SEO starter guide are useful references for the questions buyers should ask.
A practical brief does not need a finished redirect map before agency selection, but it should tell agencies whether migration matters. If current pages rank, if paid campaigns point to existing URLs, if backlinks matter, or if content will be consolidated, migration is real work. It should appear in discovery, pricing, QA, and post-launch monitoring.
Accessibility and compliance also belong in launch risk. The W3C accessibility introduction helps buyers ask about navigation, headings, forms, contrast, keyboard access, and responsive behaviour. If the site captures personal data, the UK ICO GDPR guidance is useful context for consent, privacy, and data-handling conversations.
Questions to send before the discovery call
Ask each agency to respond to the same questions. What assumptions are included in the quote? What discovery work happens before design? What content does the buyer own? Which CMS tasks can internal editors perform? How are redirects handled? How are forms and analytics tested? What training is included? What support happens in the first 30 days after launch? Which work is excluded?
These questions make the call more useful. Instead of spending most of the meeting explaining the business, you can test how the agency thinks. Good agencies will ask clarifying questions and surface tradeoffs. Weak agencies will repeat general claims about strategy, design quality, or conversion without tying them to the operating details in the brief.
Proposal comparison worksheet
| Brief item | Proposal signal | Follow-up question |
|---|---|---|
| Business goal | Agency explains how pages support the goal | Which design decisions depend on this goal? |
| CMS ownership | Handoff plan is specific | Which tasks can editors complete without support? |
| Integrations | CRM, analytics, consent, and forms are named | Who tests each integration before launch? |
| Migration | URL and metadata risks are visible | When is the redirect map reviewed? |
| Content | Copy, migration, and loading responsibilities are named | What happens if content is late? |
| Support | Stabilisation and retainer options are separate | What is included in the first month? |
Score the proposals before discussing taste. This keeps a persuasive presentation from hiding weak operating terms. It also helps teams explain the final decision to stakeholders who were not in every call.
Vendor interview script
Ask: "Walk us through the first two weeks after signature." A strong answer names kickoff, access, stakeholder interviews, analytics, content inventory, sitemap review, technical credentials, decision cadence, and risk logging. A weak answer jumps straight into visual design.
Ask: "Which decisions do you need from us before you can estimate responsibly?" Good agencies will name content ownership, migration, CMS preferences, integrations, approval capacity, and support expectations. If an agency can estimate everything without those details, either the scope is very narrow or assumptions are being hidden.
Ask: "What would make this project a poor fit for your team?" The answer should reveal whether the agency understands its limits. It may not want deep custom application logic, complex ecommerce migration, multilingual SEO, paid media, or advanced compliance work. That honesty helps you buy the right services from the right partners.
Internal reading before sending the brief
Use this template with the web design agency shortlist, website redesign RFP checklist, CMS handoff checklist, SEO migration plan, Webflow vs WordPress comparison, and retainer pricing checklist. The same terms should carry through brief, proposal, handoff, and support.
Final recommendation
Send the same brief to every agency. You will get cleaner proposals, easier comparisons, and fewer surprises when a vendor tries to move quickly without clarifying ownership. The brief does not need to answer every technical question. It needs to make the important unknowns visible so agencies can price, challenge, and plan responsibly.
Before final selection, convert the winning proposal back into the brief. Check that every important requirement has an owner, every assumption has been accepted, and every launch risk has a test or support path. If the proposal cannot be mapped back to the brief, the team is probably buying presentation quality rather than delivery clarity.
Attachments that make the brief stronger
A good brief can be short, but the attachments can carry detail. Attach a current sitemap or rough page inventory. Add analytics exports for high-value pages if you have them. Include a list of current forms and where they send data. Add notes on CRM, email, consent, ecommerce, booking, or payment tools. If the site has valuable organic traffic, include the URLs and pages that should be protected during migration.
Brand and content attachments are also useful. Share brand guidelines, logo files, photography rules, tone of voice notes, and examples of pages you like or dislike. For content, attach a first-pass content inventory that says which pages will be kept, rewritten, merged, deleted, or created. The inventory does not need to be perfect. It simply tells agencies whether they are pricing a design project, a content project, or both.
Access attachments should be handled carefully. Do not send passwords in a brief. Instead, list which systems exist and who can grant access later: domain registrar, hosting, CMS, analytics, tag manager, search console, CRM, email service, form tools, product catalogue, and source files. This helps agencies spot dependencies without exposing credentials too early.
How to use the brief during proposal review
When proposals come back, mark each brief requirement as answered, assumed, excluded, or unclear. This is the fastest way to see whether agencies are quoting the same project. A proposal that looks cheaper may have moved content migration, SEO redirects, analytics setup, or CMS training into assumptions. A proposal that looks more expensive may simply be carrying more of the real work.
Use the brief again in the final interview. Ask the agency to walk through the sections it thinks are most risky. Strong partners will usually point to content ownership, stakeholder approvals, migration, integrations, or post-launch support. Weak partners may focus only on visual preference or timeline optimism. The discussion should make the project more concrete, not more theatrical.
After selecting a partner, turn the brief into a delivery checklist. Keep the sections that matter: business goal, sitemap, content, CMS ownership, integrations, migration, QA, and support. During the project, use that checklist to prevent slow drift. If a new request appears, decide whether it supports the original brief or changes the scope. This keeps the relationship fair and the launch plan controlled.
Decision record to keep internally
Keep a short decision record after the final call. It should name the chosen route, the rejected alternatives, the evidence that mattered most, the risks still open, and the owner for each follow-up. This record does not need to be formal. It exists so that future stakeholders can understand why the team made the choice and what assumptions should be checked if scope changes later. Review this record before approving any change request, renewal, retainer, or launch exception so the original buying logic remains visible.