A service website can receive messages without receiving useful enquiries. The difference is often decided before the first page is designed: does the brief tell the team what a good enquiry is, what the visitor needs to understand, and who will respond when the form is sent?
This guide helps business owners and marketing or sales leads turn those answers into a one-page website brief. It is for organisations that want relevant enquiries from a service website. It does not promise more enquiries, a particular search position, or a conversion result.
1. Name the service, audience and service area
Write one sentence: “We provide [service] for [audience] in [country, region or service area].” Be precise enough for a visitor to recognise whether the offer applies to them. “Professional services for everyone” gives a designer little to build around. “Payroll support for growing employers in our named service area” points to a clearer audience and next step.
For English-language pages, the brief should state the countries or areas the business actually serves. For Chwezi’s English-speaking audience, centre examples on East African businesses, then adapt for wider English-speaking Africa, the UK or global buyers only where the offer supports them. Do not assume that readers share one device, connection, payment method or buying process. Ask which customer tasks need to work on a phone, what content the team can maintain, and which conditions vary by market.
For a French-language page, name the francophone country or countries the offer supports. Where local rules or the available service change the advice, confirm those facts before writing the page. Translation alone cannot resolve a difference in offer or legal context.
2. Start from a question someone has really asked
Pick one recent, representative customer question from a sales call, service email or enquiry log. Remove names and identifying details before using it. The question is a useful test for the page: can a visitor find a clear answer, understand the service boundary and see a sensible next step?
Keep the wording close to the customer’s concern. A visitor deciding whether your team serves their location needs a different answer from someone comparing two service options. If the question is still uncertain, leave it as an open item in the brief instead of inventing a customer persona.
3. Define the minimum information that helps your team respond
Write down what makes an enquiry useful, then separate required details from helpful extras. A service area, service type or requested work may be enough to route an initial message. Timing or context may help the team decide who responds. The right fields depend on the service and the decision staff must make.
Do not ask for personal information simply because a form can collect it. Ask what each field lets the team do. If an answer will not change routing, eligibility, preparation or follow-up, leave it out or make it optional. The visitor should also be able to understand why a question is there.
For an accessibility review, involve people with disabilities early enough for what they learn to affect the design. W3C’s WAI guidance explains how user involvement can inform a web project; it does not certify that a particular form conforms to an accessibility standard.
4. Write the confirmation and name the first-response owner
A form submission is a handoff. Decide who first sees it: the owner, a sales lead, a service coordinator or a shared inbox with a named rota. If nobody owns that step, record it as an unresolved project question. The website should not imply that someone will call or reply within a set time unless the business has agreed to meet it.
Draft the confirmation message while writing the brief. It should tell the visitor that the request was received and explain what happens next in terms the team can keep. If the confirmation says “we will call”, make sure the form asks for a number and that a person is assigned to call. A request that reaches an unmonitored inbox is not a completed customer journey.
5. Choose a measure and record its baseline
Choose a measure that the business can actually collect. For example, the team may count enquiries that match its service and area, then note which source brought each one. First decide what “qualified” means for this offer and who applies that definition. Otherwise two staff members may count different things under the same label.
Record the current number, its source and the period it covers before setting a target. If the business has not tracked enquiries consistently, write “not measured yet”. That is a useful starting point. A new website brief cannot supply a trustworthy baseline that the business has never recorded.
Google’s guidance on people-first content is an editorial resource, not a promise of rankings or leads. Treat the site’s visitor question as a content decision first; measure search or enquiry outcomes separately and over time.
6. Put the decisions on one page
A short brief can give the design team useful direction without pretending every detail is settled. Keep the known facts visible and mark open questions with an owner.
Service and audience
What the business provides and who it serves.
Country or service area
Where the offer applies; note any market-specific condition to verify.
Customer question
One real question, anonymised if it came from an enquiry.
Useful fields
The minimum information needed to route and respond.
Response owner
Who sees the request first and what the confirmation can promise.
Measure and baseline
The source, the definition of a qualified enquiry and the period measured.
Use the brief to discuss the website journey, required content, form behaviour, proof and constraints. Page count, visual references and technology choices come after the team agrees what the visitor needs to decide and what the business can support.
What this brief can—and cannot—do
A clear brief helps a business and its designer discuss the same customer task and the same follow-up process. It gives a proposal a better starting point for scope. It cannot guarantee that the finished site will attract a particular number of enquiries, that every enquiry will fit the service, or that a visitor will choose one provider over another.
Chwezi Core Systems’ public service page describes its website design and development offer. The project proposal should confirm the exact scope, evidence, deliverables and response commitments for each engagement. Google’s documentation on language and regional versions explains technical signals for localised pages; it does not establish that every offer is available in every country.
Put your brief to work
Request a website quote
Bring one recent customer question. We’ll use your answers to understand the service, audience and enquiry handoff before discussing a suitable website scope and quote.
- Four short steps, with progress shown as you go
- Technical details are not required
- “Not decided yet” is a useful answer
Brief received
A receipt will be sent to the email address you entered.
Sources & the researchers worth crediting
- Chwezi Core Systems — Website Designers in Uganda. The public page describes the offer; it is a marketing source, not independent verification of a feature or outcome.
- W3C Web Accessibility Initiative — Involving Users in Web Projects for Better, Easier Accessibility. Process guidance on including people with disabilities; this article does not claim that a particular site conforms.
- Google Search Central — Creating Helpful, Reliable, People-First Content. Editorial guidance, not a ranking, traffic or lead guarantee.
- Google Search Central — Localized Versions of Your Pages. Technical guidance for language and regional page variants; it does not prove which countries a business serves.
The worksheet and enquiry journey above are editorial synthesis. Examples are illustrative, not client cases. Market-specific offer and legal details must be confirmed in the project proposal.