Website project planning
How to Brief a New Service-Business Website
A practical project brief helps a designer understand your customers, real services, content, enquiry route and decisions before the build starts.
Short answer
Brief the business outcome before the design
A service business website brief explains who the business serves, what those customers need to decide, which services and areas are real, and what action the site should make easy. It also names who owns the content, approvals and technical accounts. That gives a designer a clear job to solve without prescribing every screen in advance.
If you are still deciding whether to rebuild, read our redesign versus improvement guide. The template below assumes a new site or a substantial rebuild has a clear business reason.
Customer
Who is trying to choose a provider, and what information would help them act confidently?
Scope
Which services, locations, pages and functions are essential at launch?
Ownership
Who supplies facts and assets, approves copy, owns accounts and accepts the finished site?
Copyable project template
A one-page website brief to complete
Copy these headings into a document. Give honest working answers; “not yet decided” is better than a false specification.
1. Business and decision owner
Describe the business in one paragraph. Name the person who can approve scope, content and final launch. List stakeholders whose approval is required.
2. Customers and their decision
Who is the priority customer? What problem brings them to the site? Which questions or objections must be answered before a call, quote or booking?
3. Services and genuine coverage
List the actual services, their boundaries and the places the business can serve. Mark the highest-priority offers. Identify any regulated or specialist wording that needs approval.
4. Primary customer action
Choose the next step: call, brief, quote request, booking or another action. Say what information the team needs to respond and how the request will be handled.
5. Pages, content and proof
List required pages and existing URLs to keep. Name the owner for copy, photographs, project examples, testimonials and permissions. State what evidence is unavailable.
6. Functions and connections
List forms, booking, CRM, email, analytics, accessibility and language needs. Separate what must work at launch from ideas for later.
7. Constraints and ownership
Record domain, hosting, email, platform and account access owners; brand requirements; approximate budget; dates; and any migration constraints.
8. Acceptance and maintenance
Define what must be tested before sign-off: mobile enquiry journey, content approval, redirects where needed, key page visibility and a handover owner.
This is a starting brief. A supplier may need further discovery before pricing or committing to a timeline. Keep business facts and approval responsibilities explicit.
Better requirements
Replace vague requests with decisions a team can test
| Vague brief | Useful brief | What it clarifies |
|---|---|---|
| “Make it modern.” | “A customer on a phone should understand our main service and see how to request a quote on the first screen.” | Audience, message and next action. |
| “We serve everywhere.” | “List the locations we actually cover and tell visitors when travel or availability differs.” | Honest operating area. |
| “Add our projects.” | “Use the three projects cleared for publication; we will supply approved facts and image permissions.” | Evidence ownership and approval. |
| “It needs SEO.” | “Preserve useful current URLs, give each core service a clear page owner and test the contact route after launch.” | Concrete search and customer requirements. |
These are illustrative instructions, not a claim that every business needs the same page set or platform. They give a designer enough room to propose a solution and a business owner something meaningful to approve.
Content ownership
Assign the facts before writing begins
For each page, decide who supplies the service scope, who checks accuracy, who writes or edits it and who gives final approval. A website team cannot invent client results or decide which operating areas a business actually covers. Good photographs need rights and context, not just attractive composition.
For an individual service page, use our SEO content brief template to turn the wider website brief into specific writing instructions.
If you want help turning the wider brief into a working site, our AI-ready website design service explains how page structure, approved content and the enquiry route are brought together.
Keep a simple content register: page, purpose, source of facts, media permission, responsible reviewer and status. If an item is missing, identify its owner rather than silently filling it with generic text.
Scope control
Separate launch needs from future ideas
Choose the functions required to make the first customer journey work. A complex booking system, multilingual content or CRM integration may be worthwhile, but each needs inputs, testing and ongoing ownership. Mark it as essential, later or undecided.
Do the same with pages. A useful service overview and honest core service pages are often clearer than dozens of lightly varied local pages. Map each page to a real customer question and a next action.
If replacing an existing site
Protect the pages and journeys that already work
A redesign brief should include the current website, its important URLs, forms, analytics setup, search data and known customer journeys. Say whether a domain or URL change is proposed and who will test redirects. Preserve content and proof that remain accurate. Agree how launch errors will be found and corrected.
Our website redesign checklist covers the launch controls in more detail. This brief establishes who owns those controls and why they matter.
Suggested acceptance checks
- The main service and relevant area are clear on a phone.
- The primary call or enquiry action works end to end.
- Essential pages and approved claims are present.
- Important old URLs have a documented destination where needed.
- Domain, hosting, analytics and content access are handed to an agreed owner.
Agree the final checks with the supplier and business before work starts. They are project planning prompts, not automatic contractual guarantees.
Website brief FAQs
Must every page be written before I ask for a proposal?
No, but identify who will supply and approve each page’s facts. A supplier needs to understand how much content work is in scope and what evidence exists.
Should I specify the website platform?
State any real platform or account constraint. If there is none, describe the functions, ownership and maintenance needs so a suitable approach can be proposed.
How should I describe the budget?
A range, ceiling or staged budget can help a provider recommend a proportionate scope. Explain what is included and who approves additions rather than asking for unlimited features without a decision rule.
What matters when replacing a site that already gets visits?
Document valuable pages, links, enquiry routes and current measurement before changing the structure. Plan redirects and post-launch checks where URLs move.
Source and related guidance
The Helios website brief guide is one useful general reference for scope and responsibilities. This template focuses on decisions specific to service businesses. For a real website build example, see the LitMex project case study.
Take the next step
Turn a useful brief into a useful website
CitedFirst can help organise the pages, evidence and enquiry route around the way your customers choose a service.