Define the outcome
Write down the organisation, intended audience and main action you want the website to support. Choose one primary outcome and the evidence you will use to judge progress. For example: “Help potential patients understand our consultation options and request an appointment.” This is a proposed goal, not a promised result.
Download the editable website brief (Markdown). It opens in a text editor and does not require an account. Leave private credentials and patient information out of the document.
Describe the current situation
- Current domain, website platform and people with account ownership.
- What visitors find confusing and any recurring enquiry questions.
- Important existing pages, campaigns and incoming links.
- Search Console, analytics and enquiry records available for a baseline.
- Known access, speed, accessibility or submission problems.
If you have no website, say so. If you have no measurement yet, mark it as unknown. A missing baseline is a task to address, not a reason to invent a number.
Agree the content and page scope
List the pages needed for a complete visitor journey. Give each page a purpose, an owner and the materials required. Separate launch essentials from later improvements. Page count alone does not describe complexity: five pages with a specialist integration can involve more work than a larger brochure site.
For every factual claim, note its source and reviewer. Confirm image permissions, client approval for case studies and responsibility for keeping content current.
Charity decisions to make early
- Which appeals and donation choices belong at launch?
- Which provider handles one-off and recurring payments, receipts and donor records?
- Who confirms registration statements, governance details and any Gift Aid wording?
- What platform fees apply, and who owns the provider account?
- Who supplies approved project information and explains how funds are used?
- What happens after a donation succeeds or fails?
See our World Aid Network delivery case study for a published website example, and our charity website service for scope and starting prices.
Private practice decisions to make early
- Which clinicians, treatments and practice locations need pages?
- Who checks credentials and reviews clinical statements?
- Will visitors request a callback, use a booking provider or contact the practice directly?
- Which details can a general enquiry form collect, and which belong in the practice’s approved system?
- Who handles routine updates to availability, locations, fees and referral requirements?
- Which patient information and accessibility requirements must the project meet?
Explore our consultant and surgeon website service to see how these decisions affect scope.
Separate the build budget from ongoing costs
Record your build budget, acceptable ongoing cost and any fixed deadline. Ask proposals to separate content, design, development, integrations, migration and training. List domain renewal, hosting, care, payment fees and third-party subscriptions individually where they apply.
Use our published prices as a starting point. A written proposal should confirm the scope, tax treatment, payment schedule, initial term and any exclusions.
Name the owners and reviewers
Agree who owns the domain, source files, website platform, payment or booking account and analytics. Identify the person who consolidates feedback, the specialist who approves regulated content and who maintains the website after handover. Confirm what is included in support and how urgent issues are reported.
Define acceptance before launch
- Review content, spelling, prices, credentials and contact details.
- Test the main journey on a phone and with a keyboard.
- Submit a controlled enquiry and confirm receipt, error handling and retries.
- Test the payment or booking journey using the provider’s approved test process.
- Check old-to-new URL mappings, canonical URLs and sitemap inclusion.
- Record the baseline, launch date and known limitations.
- Complete account handover and agree the first review.
The brief is ready when your organisation and the delivery team can explain the scope in the same terms. Keep it alongside the final proposal so later requests can be assessed clearly.