Website project brief: what to agree before requesting quotes

Define goals, content, connections and acceptance criteria so website quotations cover genuinely comparable work.

A brief reduces uncertainty

Asking for a website price without defining the job produces estimates that cannot be compared fairly. One supplier assumes finished copy and a simple form; another includes content work, migration and sales-system integration. The price difference may reflect different projects.

A useful brief need not be technical. Explain the business situation, the website's tasks and the main constraints. It should support a solution discussion and expose questions requiring clarification before cost and timing are fixed.

Describe user tasks rather than visual adjectives

Modern and intuitive do not define behaviour. It is more useful to say that customers must compare two services, check the coverage area and submit the details a salesperson needs. That helps determine structure, content and acceptance criteria.

Separate priorities from visual inspiration. A competitor's website may look attractive while serving a different sales model. Explain which feature is useful and why rather than requesting an entire layout without a business rationale.

Information for an initial estimate

Audiences and main website tasks.
Offer, markets and language versions.
Page types and functional requirements.
Available copy, imagery, data and existing access.
Forms, CRM connections and other integrations.
Timing, indicative budget and decision owner.

Assign content responsibilities

Missing copy and images often delay a project more than technical difficulty. Client-supplied content is not a plan unless someone has time and ownership. Establish who gathers facts, writes, checks and approves.

A folder of photographs does not guarantee suitable material for every application. Record its currency, formats and missing shots. This allows production to be planned before design starts waiting for content.

Example: one form label, two different jobs

One business needs an email notification. Another needs routing to a branch, customer confirmation and a CRM record. Both might request a contact form, although implementation and testing differ substantially.

Describe the input, recipient and next action. You do not have to prescribe the technical solution; the supplier needs to understand the process and the scenarios that must work before launch.

Define observable acceptance

Users should find the service, submit a valid enquiry and receive the correct message. Staff should edit agreed content independently. Existing important URLs should be retained or deliberately handled during migration.

Not every detail needs an immediate decision. Mark open questions and decide when they will be resolved. A good brief distinguishes known requirements from assumptions rather than quietly turning uncertainty into commitment.

Before sending the brief

Will every supplier receive the same version?
Are essentials separate from options?
Are content, access and approval owners named?
Is launch-day functionality clear?

The brief starts a collaboration. Connecting business needs with real user tasks makes the resulting estimates more useful.

Implementation plan: five steps

Name the audience and decision

Explain who visits and what action they should take. “A modern website” does not describe the different needs, information and enquiries associated with two distinct customer segments.

Map content and journeys

List page types, languages and migration material, separating templates from pages to populate. Describe service discovery, evidence and contact, including exceptions rather than merely naming modules.

Specify connections and responsibilities

For forms, CRM or bookings, define data scope and an integration owner. Assign writing, photography, translation and approvals; missing material can delay publication after development finishes.

Define acceptance

Test mobile forms, language changes, editing and errors. Include existing addresses and content so acceptance checks functioning journeys rather than only resemblance to a design mock-up.

Set launch boundaries

Separate launch requirements from later ideas, stating budget and timing. Ask about maintenance and changes to avoid confusing a lower price with omitted work.

FAQ

Must the brief be extensive?

Clarity matters more; example journeys and responsibilities can be more useful than a lengthy vision.

Include visual references?

Yes, explaining which navigation, readability or presentation feature matters.