What Should Be in Your Website Brief? Template Inside

Most people approach a web agency with a sentence and a hope. They say they need a new website, that the current one looks dated, and that they would like a quote. Then they are surprised when the quote arrives as a wide range, or as a confident number that turns out to have been wrong. The missing ingredient is almost always the same: there was no brief, or the brief that existed described a feeling rather than a project.

So what should a website brief include? At its core it should cover five things. It should state your goals, tied to the one business metric the site exists to move. It should describe your audience and the job they are hiring the website to do for them. It should set out the content scope and, just as importantly, who is writing it. It should list your technical requirements and name every integration the site must connect to. And it should define your success metrics and how each will be measured after launch. A brief that does those five things well is roughly five pages long, takes an afternoon to write, and tends to produce quotes that are both lower and more accurate. The rest of this article walks each section, explains why a vague brief costs you money, and then hands you the template so you can fill it in tonight.

What a website brief actually is

A website brief is the document that turns a vague intention into a quotable project. It is not a contract and it is not a spec written by an engineer. It is a plain-language statement of what you want the site to do, who it is for, what it must contain, what it must connect to, and how you will judge whether it worked. It exists to give an agency enough certainty to price the work accurately and to design it deliberately rather than by guesswork.

It does not need to be polished, and it does not need mood boards or a colour palette, though you can attach those if you have them. It needs to be specific where it matters and honest about what you do not yet know. Treat the rest of this article as a guided tour of the five sections, with the awkward question each one usually gets wrong called out so you can answer it properly the first time.

Section one: goals and the one metric the site must move

The first section asks the simplest and most-dodged question in any web project: what is the website for? The weak answer is a list of adjectives. The site should look modern, feel professional, be clean and easy to use. None of those is a goal. They are tastes, and tastes cannot be quoted or measured, which is why projects briefed on adjectives drift and disappoint.

The strong answer names the single business metric the site exists to move. Not five metrics. One primary metric, and at most one or two secondary ones beneath it. A professional services firm might say the site must increase booked discovery calls per month. An ecommerce business might say it must lift online orders, or average order value. A software company might say trial signups. Whatever it is, write down the current baseline number and the target you want to reach, even if the target is a rough ambition rather than a forecast. Doing this turns a matter of taste into a matter of engineering, and it lets the agency design the site backward from the number. Every page and every call to action can then be checked against a real question: does this help move the metric, or not? An agency that knows your one metric will give you a sharper site and a sharper quote, because it knows what it is being hired to achieve.

Section two: audience and the job they are hiring the site to do

The second section describes who the website is for. The weak version is a demographic sketch: small and mid-sized businesses, decision-makers aged thirty-five to fifty-five, based in the South East. That tells the agency almost nothing it can build with. Age and postcode do not dictate a page structure.

The strong version describes the audience by the job they are trying to get done. People do not visit a website to admire it; they arrive with a task and they want to complete it and leave. A facilities manager comparing three suppliers before a procurement meeting is hiring your site to confirm you are credible and to find a clear spec quickly. A couple choosing a wedding venue is hiring your site to see real photographs and check whether their date is free. Describe that job, in a sentence or two, for each main audience you have. The job-to-be-done tells the agency what the homepage must do in its first screen, which content matters most, and what the primary call to action should be. It is far more useful than a persona, because it describes intent rather than identity, and intent is what a website is built around.

Section three: content scope and the question of who writes it

The third section sets out what the site will contain: how many pages, what kinds, and whether anything is being added beyond the obvious. List the pages plainly, including any functional ones such as a booking flow, a member area, or a product catalogue.

Then answer the question that derails more web projects than any other: who is writing the words, and who is sourcing the images? Roughly half of stalled website projects stall on content, not on design or code, because nobody decided who owned it. Go through your page list and mark each page as new copy to be written, existing copy to be migrated, or existing copy to be revised, and against each, name the owner. If you expect the agency to write the copy, say so explicitly, because copywriting is a separate, separately priced service and an agency that assumes you are writing will quote for an empty shell with placeholder text. If you are writing it yourself, be honest about when, and give a realistic internal deadline, because a beautifully built site with no words in it cannot launch. Do the same for photography and video. Stating content ownership in the brief is the cheapest insurance you will ever buy against a project that goes quiet two months in.

Section four: technical requirements and naming your integrations

The fourth section covers the plumbing: the platform, the hosting, and every third-party tool the website must talk to. Most briefs skip this or fudge it with a phrase like "the usual integrations", and that vagueness is expensive, because integrations are where build estimates are most often wrong.

Name everything by its actual product name. If the site must push enquiries into a CRM, say which one: HubSpot, Pipedrive, Salesforce, or whatever you run. If it takes payments, name the gateway: Stripe, GoCardless, PayPal. Name the booking or scheduling tool, the email marketing platform, the analytics stack, anything the site must connect to. A booking integration with one system can be an afternoon; with another it can be a fortnight of custom work, and the agency cannot price the difference if you do not say which one. Then state your constraints. Is there existing hosting that must be kept, or are you open to a recommendation? Is there a brand guideline the site must follow? Do you have an accessibility standard to meet, such as WCAG 2.2 AA? Are there security or compliance obligations specific to your sector? Every named tool and stated constraint removes a guess, and every guess removed makes the quote tighter.

Section five: success metrics and how each one is measured

The fifth section closes the loop opened by the first. Section one named the goal; this section defines how everyone will know, after launch, whether the site achieved it. Without it, success quietly becomes a matter of opinion, and opinions about a website are never unanimous.

For each goal metric, write down two things: the tool that measures it, and how often you will look. Booked discovery calls might be measured in your CRM and reviewed monthly. Enquiry conversion might be tracked in GA4 as a defined event and reviewed each quarter. Page performance might be measured through Core Web Vitals in Google Search Console. The specific tools matter less than the discipline of naming them. A measurement plan makes the project accountable, because there is an agreed scoreboard rather than a vague sense of whether things feel better, and it gives you and the agency a shared definition of done for when launch day arrives and someone asks whether the site has worked.

Why a vague brief gets you a padded quote

It is worth being blunt about the mechanism, because it explains why this whole exercise is in your financial interest and not just the agency's. A quote is a bet on uncertainty. When an agency reads your brief, it is trying to work out how much work the project actually contains. Where the brief is clear, it can price the work directly. Where the brief is vague, it cannot, and it has only two honest options.

The first is to pad the number. If the brief does not say who writes the copy, the agency either prices copywriting in to be safe, which inflates the quote, or it assumes the worst-case scope on every ambiguous point and adds a contingency on top. The second is to quote low and recover the difference later through change orders, so the attractive number on the cover becomes a series of surprise invoices once you are committed and the deposit is paid. Neither outcome is good for you, and both are caused by the same thing: ambiguity in the brief. Every unanswered question is a risk line, and risk lines carry a price whether you see them or not. A precise brief removes the unknowns, which removes the contingency, which is why the identical project briefed well is quoted lower, and more accurately, than the same project briefed badly. A vague brief does not save you the effort of being specific. It just moves the cost of that vagueness onto your invoice.

The template

Here is the brief itself. Copy it, paste it into a document, and fill in the bracketed parts. It is deliberately short: five sections, a few pages, no jargon. If a section is genuinely unknown, write that it is unknown rather than guessing, because an honest gap is easier for an agency to handle than a confident wrong answer.

# Website Brief: [Company name]
Prepared by: [Name, role]   Date: [Date]   Contact: [Email / phone]

## 1. Goals
- What is this website for, in business terms?
  [One or two sentences.]
- The ONE primary metric this site must move:
  [e.g. booked discovery calls per month]
  Current baseline: [number]   Target: [number]
- Secondary metrics (optional, max two):
  [e.g. newsletter signups, average order value]
- What is wrong with the current site, if there is one?
  [Plain language.]

## 2. Audience
- Primary audience: [who they are]
  The job they hire this site to do: [their task, in one sentence]
- Secondary audience: [who they are]
  The job they hire this site to do: [their task, in one sentence]
- Primary call to action we want them to take: [e.g. book a call]

## 3. Content scope
- Pages required (mark each: NEW copy / MIGRATE / REVISE, plus the owner):
  [Homepage / NEW / agency writes]
  [Services / NEW / client writes, ready by DATE]
  [About / MIGRATE / client]
  [Case studies / NEW / client writes, ready by DATE]
  [Blog / MIGRATE / client]
  [Contact / NEW / agency]
- Who writes copy overall: [agency / client / mixed, be specific]
- Photography and video: [exists / to be sourced / agency to arrange]

## 4. Technical requirements
- Preferred platform: [e.g. WordPress, or "open to recommendation"]
- Hosting: [keep existing provider / open to recommendation]
- Integrations required (name each product):
  CRM: [e.g. HubSpot]
  Payments: [e.g. Stripe, or N/A]
  Booking/scheduling: [e.g. Calendly, or N/A]
  Email marketing: [e.g. Mailchimp]
  Analytics: [e.g. GA4]
  Other: [chat, reviews, etc.]
- Constraints: [brand guidelines? accessibility standard e.g. WCAG 2.2 AA?
  security or compliance obligations? existing design system?]

## 5. Success metrics
- For each goal metric: how it is measured and how often it is reviewed.
  [Booked calls / measured in CRM / reviewed monthly]
  [Enquiry conversion / GA4 event / reviewed quarterly]
  [Page speed / Core Web Vitals in Search Console / reviewed quarterly]
- What "done and successful" looks like, in one sentence:
  [Plain language.]

## Practicalities
- Budget range (a range is fine, and honest): [£X to £Y]
- Desired launch date or deadline driver: [date, and why]
- Decision-maker and sign-off process: [who approves what]

That is the whole thing. If you are responding to a more formal procurement process, the same five sections work as the backbone of a website RFP template; you simply add a section on submission format, deadline, and how proposals will be scored. The substance an agency needs is identical.

A brief is not bureaucracy. It is the cheapest tool you have for getting an accurate price and a website that does its job, and writing one is genuinely an afternoon's work. Filling in these five sections also tends to clarify your own thinking, because a surprising number of website decisions get easier once you have written down the single metric that matters and the job your audience is trying to do.

That is the standard we work to at WitsCode. Send us a brief built on this template and you will get a precise, itemised quote rather than a padded range, because you will have answered the questions that otherwise force an agency to guess. And if a section is still thin, we will tell you honestly where it needs more before we price anything, because a clear brief protects you as much as it helps us. If you have a website project in mind, fill in the template above, send it over, and let us quote the actual job rather than a cautious estimate of it.