A useful website brief explains who the site is for, what it must help them do, what belongs in the project and who will supply and approve the inputs. Leave unknowns visible so they can be discussed before a quote becomes a commitment.
This template is for a service business commissioning its first website. You can use it with any delivery partner. You do not need to decide the platform, write finished copy or know every answer before starting a conversation.
If an existing site already has useful pages, links or enquiries, also use the rebuild preservation pack. Those existing assets need a separate record.
Start with six answers
Copy these prompts into an email or your own notes. They are enough to start a useful discussion.
- Buyer: Who needs the service, and what usually prompts them to look for help?
- Decision: What should they understand or do after visiting the website?
- Scope: Which services and practical functions must be available at the first release?
- Inputs: Which business facts, images and examples can you supply, and what is missing?
- Responsibility: Who can answer questions and approve the facts, copy and permission to publish?
- Constraints: What budget, deadline, editing needs or unanswered questions should a provider know about?
“To discuss” is a useful answer when it has an owner and a next action. A blank silently treated as agreed is harder to resolve later.
Download the website brief pack
Use the blank brief for the project decisions and the page plan for the inputs behind each proposed page. The worked pair shows how those records fit together.
| File | What it helps you record |
|---|---|
| Blank website brief, Markdown | Buyer needs, scope, responsibilities, functions, ownership and questions still to settle. Includes instructions and a page-plan field guide. |
| Blank page plan, CSV | Each page’s job, release decision, needed inputs, contributor, writer and approver. |
| Worked website brief, Markdown | A fictional service business preparing for a scope discussion with specific decisions still open. |
| Worked page plan, CSV | Seven fictional page decisions, including work deferred and a blog excluded from the first release. |
These are static text files. Open Markdown in a text editor or copy it into a document. Import CSV as UTF-8 and treat the columns as text. The files contain no formulas, scan nothing and send no entries to us. Keep completed briefs and private evidence in your own workspace; do not enter passwords or customer personal data.
Give each page a buying question
“We need a professional website” does not tell a writer what a buyer needs to learn. “An operations lead needs to understand what our onboarding support includes before asking for help” gives the page a job.
Separate known needs from assumptions. Past sales questions and conversations with intended buyers can help; a first website has no historical website data to consult. GOV.UK’s user-needs guidance offers a useful research principle here: investigate what users actually need rather than treating the team’s assumptions as evidence.
For each candidate page, choose Launch, Later or Exclude, and give a reason. “Later” needs a condition for reconsideration. “Exclude” should remain visible so nobody assumes it was included in the quote.
Our fictional example keeps a distinct onboarding service page, defers ongoing support until its boundaries are agreed, and excludes a blog because no publishing responsibility has been assigned. Those are decisions for that exercise. They are not a universal sitemap.
Google’s SEO starter guide recommends logical organization and helpful content. It does not prescribe a page count for your business. Once a service earns its own page, use the service page brief to prepare that page’s detailed content.
Separate supplying facts from writing and approving
A business expert may supply notes, a delivery partner may write the copy, and another person may approve it. Record all three responsibilities. A folder of documents is not an agreement about who turns them into publishable pages.
For each page, list the facts and assets needed, who supplies them, who writes, who approves and what blocks progress. Keep scope separate from readiness: a page can belong in the first release while still needing inputs.
Record proof permissions explicitly. In the example, permission to publish a previous project is unresolved. Its logo and results stay out of scope for publication unless permission and accuracy are confirmed. An illustrative process sample may help explain the service, but it must be labelled as an illustration, without implying a customer result. The proof selection guide explains that distinction.
Describe the enquiry and editing tasks
“Contact form” is only the beginning. Record what the buyer sends, where it goes, who replies and what they see afterwards. Include any external booking or payment step so it can be discussed and checked.
Agree to test both the visitor’s experience and actual receipt of a test enquiry. GA4’s enhanced measurement describes form interaction events; treating an event as proof that someone received and handled the enquiry would go beyond that evidence. GA4 form measurement documentation.
For editing, name the task: changing a team biography, adding a service or updating a document. Ask the provider what is included, who gets access, what training is needed and how ongoing changes are handled. A request for a website does not settle its editing model.
Agree ownership and checks before the build
List the domain, hosting, website platform and measurement accounts. Record the intended account holder, administrator, recovery route, renewal owner and handover expectations. Keep credentials elsewhere. ICANN’s registrant guidance makes accurate registration details and renewal responsibilities relevant to domain control. Content rights, code, licenses and transfer terms need their own agreement with the provider.
Ask how accessibility will be included in the scope and reviewed during delivery. W3C’s planning guidance covers goals, responsibilities and resources; its evaluation guidance explains why a tool alone cannot determine accessibility. Naming a target in the brief does not certify that the finished site meets it.
Agree review expectations for content, mobile use, keyboard use, enquiry delivery, editing access and handover. Record a requested launch date together with its dependencies. If content approval, an integration decision or access is missing, make the schedule consequence visible before promising a date.
Finish with the questions still open
The fictional worked brief ends ready for a scope discussion, with editing, permissions, data handling and commercial terms still unresolved. It does not claim the build is approved or the website is ready to launch.
Give each open question an owner, next action and decision point. Then ask the delivery partner to confirm inclusions, exclusions, assumptions, dependencies and acceptance checks in the proposal. A useful brief makes that conversation more specific; it does not replace the agreement.
For our build scope and responsibilities, see New Website. If you would like to discuss the starting point, bring your rough notes to a Clarity Call. Completing the pack is optional.