Start with one useful customer action
Write down what a visitor should be able to do after reading your website: understand a service, check whether it fits their needs, prepare an enquiry or find a practical answer. Choose a primary action for each important page. A list of design preferences alone does not explain what the site must achieve. Add the questions customers ask before they contact you, and describe the information they need to make that decision.
Describe your services and audience precisely
For each service, provide its name, the problem it addresses, the people it helps, what the work includes and what the customer receives. State any limits or prerequisites. Include your actual service area and available languages only when confirmed. If different audiences need different information, explain those differences in the brief instead of asking one page to speak to everyone. This gives the project a clear basis for page planning.
Inventory the material you can actually publish
Gather the official logo, approved business details, service descriptions and existing website content. For photographs, testimonials or project results, record who owns the material and whether you have permission to publish it. Keep unverified examples out of the public brief. Mark missing information clearly and assign someone to supply or approve it. A concise, accurate description is more useful than a polished claim that nobody can substantiate.
Map the enquiry journey before choosing tools
List the information you need to evaluate a request, who should receive it and how the visitor will know whether it arrived. Separate required fields from optional context. A visible form does not establish that delivery works. Ask the project team to identify any disconnected service and to test the real delivery path before launch. Plan what happens when validation fails or delivery is unavailable, and make the instructions understandable without technical knowledge.
Plan languages, access and ownership
Decide which pages need English and French versions, who reviews each version and how updates will stay aligned. Describe any known keyboard, readability or mobile usability problems on the existing site. Identify who will own the domain, hosting account and content after handover. Ask for a practical explanation of routine updates and any external service costs. Record these responsibilities in the agreed scope so important decisions do not depend on assumptions.
Agree a reviewable scope and acceptance checks
Finish the brief with a page list, deliverables, priorities, review responsibilities and any genuine timing constraints. Ask what will be tested, how issues will be recorded and what must be completed before public launch. Treat search visibility as work on your content and technical foundation, rather than a promise of rankings or AI recommendations. The brief should make it possible to compare proposals on the work provided and to decide what can wait for a later phase.