How to write a website brief that leads to a useful proposal

If you ask several suppliers for “a modern website,” you may receive prices for very different projects. A brief gives them enough context to understand the business problem, identify what is still unclear, and recommend a way forward. You can prepare that context before knowing every page, feature, or design decision.

Keep the brief focused and specific enough to guide a conversation. It should explain what must change, who the website is for, what visitors should do, and which practical constraints shape the project. The supplier can then challenge assumptions, recommend an appropriate scope, and price comparable work.

Begin with the business situation

Describe the organization in plain language. Explain what you sell, where you operate, who buys from you, and how customers currently find or contact you. Then state why the project is happening now.

Perhaps the existing website looks unreliable on mobile. Maybe the business has changed its services, opened a second location, or relies too heavily on social media. A new organization may need a credible first presence before a launch. These details help a supplier understand what the website needs to improve before discussing visual preferences.

Include the current website, if one exists, and any channels that matter: Google Business Profile, Instagram, booking platforms, directories, or offline referrals. Mention what already works. A redesign should not remove a useful contact path or a page that consistently attracts qualified visitors merely because it looks old.

Define one primary outcome

Most business websites can support several actions, but one should lead the hierarchy. It might be a phone call, reservation, appointment request, visit, donation, quotation request, or project enquiry.

Write the outcome as an observable action: “help restaurant guests reserve a table” is clearer than “increase engagement.” Add secondary actions only when they genuinely matter, such as viewing a menu, checking opening hours, or downloading a document.

Avoid promising a numerical result without evidence. A website influences demand, trust, and conversion, but pricing, reputation, capacity, sales follow-up, and traffic quality also affect the final result. The brief should define what the website can reasonably improve and how the team will recognize progress.

Describe the priority audiences

List the two or three groups whose needs most affect structure and content, rather than describing the audience as “everyone.” For each group, explain what they need, what they already know, what may make them hesitate, and which action they should take.

A clinic may serve patients, parents, and referring professionals. A restaurant may need to help local guests, tourists, and event organizers. A professional service may speak to owner-led businesses and larger organizations with different procurement expectations.

Include details that could change the design: device use, language, urgency, accessibility needs, geographic area, and decision criteria. An invented persona’s hobbies are less useful unless they explain something relevant about using the service.

Inventory content before choosing page count

List the information that must be published: services, team, locations, prices, menus, case studies, FAQs, accreditations, policies, contact details, or resources. Mark what already exists, what needs updating, and what must be created.

Do not assume the supplier can discover accurate facts from scattered messages. Name an internal person who can confirm claims and approve final text. If photography, translation, legal review, or specialist writing is required, state whether it is available or should be included in the proposal.

This inventory helps determine page structure. Five focused pages may be enough for a small service business. Another organization may need fewer public pages but complex resources or multiple location templates. Page count should follow content and user tasks, not an arbitrary package alone.

Separate essential functionality from ideas

Describe what visitors must be able to do. Examples include sending an enquiry, calling with one tap, requesting an appointment, filtering locations, reading in two languages, or accessing a downloadable guide.

Then separate essential launch requirements from possible later additions. A standard contact form is different from a booking system that checks staff availability, takes payment, sends reminders, and synchronizes calendars. A managed article section is different from a full editorial platform with roles, previews, and approval workflows.

Mention integrations by name when known, including CRM, newsletter, analytics, maps, payment, or scheduling providers. Note whether accounts already exist. This prevents a simple-sounding feature from hiding subscription costs, data migration, or operational work.

State practical constraints openly

Give a realistic budget range or ceiling. It helps a partner recommend the right level of custom work and avoid proposing a system the organisation cannot sustain.

Include a target date and the reason behind it. A fixed event, opening, or campaign is different from a preference to finish quickly. Identify who makes decisions, how many stakeholders will review work, and how quickly feedback can usually be returned.

Also mention technical or organizational constraints: an existing domain, required hosting region, internal IT policies, legacy content, accessibility expectations, or a platform that must remain. Surprises discovered during development cause more delay than honest constraints listed at the beginning.

Clarify ownership and responsibilities

The brief should ask who will own the domain, hosting, source code, design files, analytics, and third-party accounts after launch. Business-critical accounts should normally be registered to an address controlled by the organization, with the supplier receiving appropriate access.

Define who supplies text, images, translations, privacy information, and approvals. Ask what maintenance includes, how issues are reported, which updates are covered, and how new functionality is estimated. “Support included” is too vague without a duration and boundary.

Agreeing these responsibilities early helps both sides plan the handover and the work that continues after launch.

Invite recommendations alongside estimates

End with the decisions you want the proposal to answer. Ask for the recommended scope, assumptions, exclusions, timeline, payment stages, project process, and examples of relevant work. Ask suppliers to identify risks or alternatives rather than silently pricing every request.

Read the totals alongside the work and responsibilities each proposal includes. One may include content structure, responsive quality assurance, analytics, search foundations, launch support, and maintenance. Another may cover only a visual template and leave essential work to the client.

Leave room for the supplier to question the scope and suggest a simpler approach. With the business context, audience, content, actions, constraints, and ownership written down, those recommendations can address your actual needs. You will also be able to see where two proposals differ and ask useful questions before choosing.