State the business problem and priority journeys
Explain why the current website needs work: poor enquiries, difficult publishing, fragile integrations, inaccessible journeys or an unsuitable platform. Identify the audiences and actions that matter most. An example such as “a buyer should find the right specification and request a quote” is more useful than “the site should be modern”.
Record what must be retained as well as what should change. Include working URLs, useful content, established integrations and operational routines.
Inventory content, systems and ownership
List the current pages, documents, images and languages. State who will write, approve and supply each part of the replacement. Identify forms, booking engines, CRM, payments, search, analytics and email delivery. Include the people who operate these systems in the brief. Suppliers cannot responsibly include an integration they are not told exists.
Download the website brief template and adapt it to your project. Remove irrelevant sections rather than leaving contradictory requirements.
Define quality in testable terms
| Area | Example acceptance question |
|---|---|
| Enquiries | Does a valid form reach the correct team and show confirmation? |
| SEO migration | Do agreed old URLs reach relevant approved destinations? |
| Accessibility | Can key journeys be completed using a keyboard? |
| Content management | Can authorised staff perform the agreed editing tasks? |
| Measurement | Is each completed business action counted correctly? |
Agree the required accessibility standard and review method. A target should not be presented as certification without appropriate assessment.
Ask suppliers to explain their assumptions
Request a scope, deliverables, dependencies, exclusions, milestones and an acceptance process. Ask who does the work and which parts depend on another provider. Understand what happens when content arrives late or a requirement changes. A proposal that makes these boundaries explicit is easier to manage than one offering unlimited flexibility without a clear delivery mechanism.
Ask to see relevant work and the supplier’s contribution to it. A screenshot alone does not establish who designed, developed or maintained the system.
Make ownership and support part of selection
Clarify domain and hosting accounts, source code, licences, backups, analytics access and data export. Agree what documentation and training are included. Discuss support hours and response commitments only where they are actually offered, and distinguish correcting a defect from adding a new feature. Confirm the route for another supplier to take over later.
These practical questions matter even for a small website. They become more important when the site runs bookings, customer accounts or payments.
Compare proposals through a decision record
Score proposals against the requirements that matter, not the length of the presentation. Record where suppliers have proposed a different approach and whether it improves the outcome. Resolve substantial ambiguities before signing. Keep the accepted brief and subsequent changes available during delivery so acceptance is based on an agreed scope rather than memory. We recommend reviewing the brief with the people who will use, maintain and approve the finished website.
Common questions
Do we need to choose the technology in the brief?
Specify genuine constraints and existing systems. Let suppliers explain suitable options where the platform is not already decided.
Should the cheapest proposal win?
Only if it meets the required scope and responsibilities at an acceptable risk. Compare the complete delivery and operating position, not price alone.