The short answer
A useful website brief names the customer, the decision they need to make and the next action. Plan distinct service pages, credible evidence and a reliable enquiry route before discussing animation. Decide who owns the domain, source files and future updates so the site remains usable after launch.
Start with the customer’s decision
Write the questions a prospect asks before contacting you: is this service for a company like mine, what does it include, what documents are needed and what happens next? Map those questions to pages. A single page that vaguely lists every service often leaves the most important questions unanswered.
Use the words customers use, then clarify technical terms. Separate information that helps a visitor choose from operational instructions that belong in a private client workflow. Do not claim to offer a service just to target a search phrase.
Turn the brief into a page map
Scroll sideways to see every column.
| Page | Decision it should support |
|---|---|
| Home | What the business does and where to start |
| Service page | Scope, suitability, process and next step |
| About | Who is responsible and what real evidence supports trust |
| Contact | Which route reaches the correct team |
| Useful guide | A real question answered with sources and relevant service links |
| Legal pages | Accurate handling of enquiries, data and site terms |
What makes a contact route reliable?
Decide whether enquiries use a form, email, WhatsApp or more than one channel. For a form, specify where submissions go, who responds and what the visitor sees when delivery fails. For a WhatsApp draft, explain that the visitor must send it. Do not display a success message before a message has actually reached its destination.
Test the route on a phone and give a fallback contact method. Collect only information that the team needs at this stage. Agree who can access enquiries and how the business will manage them; those choices affect implementation and the privacy wording.
Resolve ownership before the build
- Who controls the domain registrar and hosting account?
- What source files and design assets are handed over under the agreement?
- Who can edit content, and how are changes reviewed and published?
- Which third-party services, licences or recurring fees are needed?
- Who owns maintenance, backups and resolving a broken enquiry route?
A practical launch acceptance list
Open every published route directly, including on mobile; follow each service link; check that phone/email/WhatsApp destinations reach the intended team. Review image quality, page titles, search previews and meaningful missing-page behaviour. A home-page screenshot is not evidence that all routes work.
Keep factual copy approved and separate examples from actual client results. Use real team photographs where available. For generated editorial imagery, avoid presenting fictional staff, premises or certificates as proof of the business. The design can look ambitious without making evidence it does not have.
Questions worth answering
Does my first website need a CMS?
Not always. A static site can suit a modest publishing workflow; a CMS is useful when the team needs frequent browser-based editing. Choose around who will maintain it.
When is a custom app more appropriate than a website?
When users must complete a repeated workflow, manage data or operate a service rather than mainly read and enquire. Define the workflow before choosing the technology.
Your next step
Choose the support that fits this decision. Each link takes you to the relevant service page.
This guide is practical preparation, with official sources where relevant. Company-specific requirements need an assessment of your circumstances. How these guides are prepared.
