Website development brief: scope and acceptance template

Write a website brief that makes audiences, journeys, content, integrations, migration and acceptance clear enough for comparable delivery proposals.

Floating website layouts with dark content panels and indigo accents.

A website development brief should let different suppliers estimate the same outcome. A list of pages is not sufficient because content, integrations, editing workflows and migration can change the work substantially. Start with the business objective and the user action that supports it. Describe what success looks like without prescribing every implementation detail, then make assumptions and exclusions visible.

Define audience and journeys

Name the primary audiences, markets and languages. Describe how a visitor arrives, what information they need and what action they should complete. For a service website, that might be understanding an offer and submitting a qualified enquiry. For an account portal, it may involve authentication and access to private records. Include accessibility and supported-device expectations. These decisions help the team choose templates and interactions based on actual use.

Specify content and operating ownership

List page types rather than only individual URLs. For each type, identify fields, reusable components, translations, media and the person responsible for supplying or approving content. Explain how editors publish changes and whether preview or approval is required. Record integrations with CRM, email, analytics, payments or internal systems. State what data crosses each boundary and which system owns it. Do not leave integration behaviour hidden behind a short phrase such as connect the form.

Make delivery acceptance concrete

Provide the initial sitemap, important existing URLs and migration or redirect requirements.
Define representative acceptance journeys, including form validation, failure feedback and successful delivery.
Specify ownership of source code, design assets, hosting, domains and third-party accounts.
Agree launch responsibilities, training, warranty or defect handling, and the ongoing maintenance boundary.

Separate decisions from unresolved questions

Create a short assumption register with owners and decision dates. Mark optional features so suppliers can price them independently. Ask for a staged proposal showing discovery, design, implementation, content population, verification and launch. Compare quotations against these stages and the same acceptance criteria. A useful brief does not eliminate every uncertainty; it makes uncertainty discussable before it becomes a change request. Keep it updated when decisions change, and use the final version as a practical reference during acceptance and handover. Attach representative examples where they remove ambiguity.

Frequently asked questions

How detailed should the brief be?

Detailed enough to align outcomes, scope, ownership and acceptance, while leaving implementation choices open where they are not business constraints.

Should we include a budget?

A realistic range or constraint helps suppliers propose a feasible scope and identify optional work.

Who supplies the content?

Name an owner for writing, images, translations and approval; missing content can affect delivery sequencing.

Do we need to list every page?

Include a sitemap and reusable page types, with exceptions that require different functionality.

What makes supplier quotes comparable?

The same journeys, content assumptions, integrations, migration requirements, acceptance checks and operating responsibilities.

Bring the scope. We will help make it buildable.

Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.

Explore the delivery scope →