Define the customer journey before choosing pages, features or a price.
Start with the outcome
Who needs to find you, what do they need to understand, and what should happen next? Connect the website brief to enquiries, sales, service or a useful customer workflow.
Begin with a real visitor and a concrete task. For a service business, that might be understanding whether a service covers their location, checking what information a consultation requires, and sending a useful enquiry. Write that journey in plain language before turning it into a list of pages.
Bring the questions your sales team answers repeatedly. Product limitations, service areas, delivery responsibilities and the next step often matter more than an elaborate opening animation. Decide which information must be visible before a visitor contacts you, and who in your business can confirm that information is accurate.
A useful discovery output is a short statement: this audience needs to complete this task, and we will recognise success through this evidence. Keep that statement available when deciding whether a proposed feature belongs in the first release.
Make the scope specific
List the content, integrations, languages, accessibility needs and launch responsibilities. Separate the first release from later improvements so the proposal describes a deliverable, not a wish list.
Make a content inventory: existing URLs, service descriptions, documents, photography, forms and downloadable resources. Mark each item as keep, rewrite, combine or retire. Identify an owner for every piece that needs approval. Missing content is a delivery dependency, not a detail to resolve after the design is finished.
Describe integrations through their behaviour. Instead of writing “connect our CRM”, explain which form creates a record, what fields are required, who receives the enquiry and what happens if the CRM is unavailable. That gives the design and implementation teams something specific to estimate and test.
Separate launch requirements from later ideas. Include acceptance checks for navigation, forms, mobile layouts, content editing and broken-link handling. Agree who supplies access and test data, and which decisions require your approval. These boundaries make a proposal easier to compare and a change request easier to understand.
Build an improvement path
Agree how enquiries and important actions will be measured. Launch is the beginning of a review cycle: observe, prioritise and improve.
Choose a small set of meaningful actions to observe after launch: a completed enquiry, an appointment request, a product-document download or a qualified conversation. A busy page is not automatically a useful page. Review what visitors attempted and where they needed help, alongside the quality of enquiries reaching your team.
Plan a review with the people who maintain the content and respond to leads. Ask what has become outdated, which questions keep coming up and where manual work remains. Use those findings to select the next improvement instead of continually adding features without checking their effect.
Keep a practical handover record covering content ownership, administrative access, recurring services, support contacts and recovery responsibilities. A website project should leave the organisation able to operate its new site, not dependent on remembering decisions scattered through messages.