A good corporate website brief explains what the website should do, whom it is for and how it will be used after launch. You do not need to know which technology to choose. The provider needs to understand the business and the boundaries of the task.
You can start with a short document and refine it through discussion. Open questions belong in it too, as long as they are clearly marked.
1. Describe the work the website needs to do
“We want a modern website” describes a preference, but does not give enough direction. It is more useful to explain what visitors should be able to do: understand a particular service, assess whether it suits them and submit an enquiry with the necessary information.
Add some context: what the company offers, who buys it, how enquiries arrive now and where the difficulties are. If you already have a website, describe what you want to keep and what is not working well.
2. Identify the audience and the next step
Think about what people know before visiting the website. A new customer may need an explanation of the service. An existing customer may be looking for a technical document or a contact in a particular department.
For each important audience, record:
- what they are looking for;
- which questions need answers;
- what action you expect them to take;
- who in the company handles that action afterwards.
If a form sends enquiries, specify who receives them. The website is only part of that process.
3. Separate pages from functionality
A list such as “Home, About, Services, Contact” helps define the structure. It does not fully describe the work. Add what each page should contain and any particular requirements.
Describe functionality separately. Examples include a form with service selection, downloadable files, catalogue search, two languages or a connection to another system. For an integration, name the system, specify which data is transferred and say whether documentation is available.
Separate requirements into “needed for launch” and “can come later”. This allows a sensible proposal in phases. The entire future project does not need to fit into the first version.
4. Clarify content and visual materials
List what you already have: logo, colours, copy, photographs, documents and project examples. Then specify who prepares what is missing and who approves it.
When sharing reference websites, explain exactly what you like. “We like how they explain their services” is more useful than a link without context. Separate visual preferences from content and navigation needs.
Also clarify who will edit the website after launch. If an employee needs to add projects independently, that belongs in the brief rather than becoming a detail on the final day.
5. Set realistic constraints
Provide a budget range if you have one, and explain whether it covers content, design, development and initial data entry. Ask separately about recurring costs and maintenance.
If there is a deadline, explain why it matters. Launching before a particular event differs from a tentative preference for next month. Record when your team can provide materials and feedback.
6. Describe how the work will be accepted
Acceptance criteria should be testable. For example:
- the agreed pages contain approved content;
- the form sends an enquiry to the correct recipient and displays confirmation;
- the main actions can be completed on a phone and a computer;
- the responsible employee can make the agreed edits;
- access, file handover and post-launch care have been agreed.
When replacing an existing website, also discuss content and URL migration. This allows the proposal to cover the transition, rather than leave it as an unexpected additional task.
A short example you can adapt
The following is an example, rather than a description of a real client:
We are a professional services company. The website should explain our three main services and receive enquiries. For launch, we need service pages, selected projects and contact details. We have a logo and photographs, but the copy needs to be prepared. One team member will approve materials and add new projects after launch. The budget and deadline are still to be agreed. We want the proposal to separate website work from ongoing maintenance.
Add your own processes, materials and constraints. You do not need to fill every unknown with an assumption.
How to compare proposals
Send the same version of the brief to each provider. Check what each proposal includes, its assumptions and what falls outside the scope. Different scopes cannot be compared by the final price alone.
For a corporate website, the brief is the foundation for that conversation. Its useful outcome is a shared understanding of the task and a clear next step, rather than a document with as many pages as possible.
