Describe the customer and the next step
Start by explaining who the website is for and what they should do. A hotel taking availability requests has a different workflow from a retailer accepting payment. “We need a modern website” describes a preference, but does not define the job.
Write a one-paragraph brief in plain language. Include your business, the main customer, the action they should take and what currently prevents that action. This gives the team something concrete to discuss.
Choose the essential pages
List the information a customer needs before enquiring or buying. Include service details, supporting work, useful contact information and any content specific to your business. Group related information instead of adding a separate page for every small topic.
Mark the pages that are essential at launch. Keep future ideas in a separate list so the first proposal can address a clear scope.
Decide who supplies the content
Identify who writes the copy, approves it and provides images. Include the time needed to gather product details or service information. If copywriting or photography is required, include it explicitly in the brief rather than discovering the gap during development.
Map the integrations
List the tools the website must connect to and explain the workflow, not just the tool name. For a booking request, describe where it is stored, who responds and how availability is confirmed. For a payment, explain what happens after success or failure.
Access, subscriptions and third-party approvals can affect the delivery plan. The proposal should identify these dependencies.
Share budget and launch constraints
A useful budget range helps the team recommend a realistic first release. If the date is fixed, explain why and identify which requirements can move to a later phase. Ask for scope options when the available budget does not cover the full wish list.
Our pricing guide provides indicative ranges and exclusions. Your written proposal should define the actual deliverables and price.
Agree how you will review the work
Choose one person to coordinate feedback and agree when design and development reviews happen. Define acceptance around tasks: a customer can submit an enquiry, an editor can update a service page, or staff can find the required request details.
Plan ownership and handover
Clarify who controls the domain, hosting and connected accounts. Ask what source files, documentation and training are included. Define the support period and how future changes are requested.
A useful brief ends with known questions, not guessed answers. Send the team your current website, your priorities and the decisions you still need help making. Start a project conversation when you are ready to turn the brief into a scoped plan.