What is the practical answer?
You don’t need to arrive with wireframes or a technical specification. A useful brief explains your business, the people you serve and what your current website makes difficult.
Start with the customer’s next step
What should someone be able to do after visiting the website? Book a service, request a quote, buy a product or understand whether you are the right fit? Choose the journeys that matter most.
Bring a few examples of questions your customers ask. The wording in those conversations is often more useful than a list of abstract brand adjectives.
Show what is working and what isn’t
Share your existing website and point to specific pages. Perhaps the services are hard to compare, the booking link disappears on a phone or the photos no longer reflect the business.
Keep a short list of things you want to preserve too: useful content, familiar page addresses, your logo and any integrations your team relies on.
Put content and connections in the brief
List the pages, services, photography and written material you already have. Agree who is responsible for missing content and who can approve it.
- Booking providers, payment services and contact forms
- Customer accounts, CRM connections and email tools
- Domain, hosting and access to the existing website
- Who reviews the work and how feedback is collected
Agree the handover before the build
Ask what you will receive: source access, content editing guidance, hosting details and a record of third-party costs. Discuss updates and support separately from the initial build.
A useful proposal makes the boundaries visible. Page count, functionality, revisions and responsibilities should be clear enough that both sides can recognize a finished project.