A better website starts with a clearer brief.

Describe the change you need

Start with the business situation. An outdated visual identity, a difficult booking journey and a growing catalogue are different problems. Explain what happens today and what you want customers or staff to be able to do instead.

For example: “People call to ask which service they need because our pages do not explain the differences.” That is more useful than “We want a modern website.” It gives the team something to investigate and a reason for changing the information structure.

• The main problem, with a real example if possible.
• The primary audience and the task they need to complete.
• The action that matters: an enquiry, booking, purchase or operational task.

Map what already exists

List the current website, important service or product pages and any content that must be retained. Include brand assets, photography and approved client examples. Flag material that needs writing or updating, rather than assuming it will arrive during the build.

For an existing site, identify pages that bring enquiries or are linked from other websites. If you have Search Console or analytics access, mention it. The agency can then plan a review instead of making assumptions about what can safely change.

• Current website and the pages you consider essential.
• Available logos, images, copy and permissions to use them.
• The person responsible for checking business facts and approving content.

Describe the work behind each button

“Book now” can mean an enquiry form, a link to another platform or a live integration. Name the booking, payment, stock, CRM or dispatch systems involved. Explain what information should move between them and who handles it afterwards.

Also say who needs to edit the website. A marketing team publishing articles has different needs from a retailer updating hundreds of products. Ask the agency to explain the proposed editing workflow and the handover it includes.

• System names and the contacts who manage them.
• How an enquiry or order reaches the right person.
• Editing tasks, access roles and any existing technical constraints.

Make the practical constraints visible

Share a realistic budget range and distinguish the initial project from ongoing subscriptions or support. If there is a launch date, explain why it matters. An event date may be fixed; a preferred date may have room for a phased release.

Identify the people who approve the design, content and final build. Agree how feedback will be collected, particularly when several stakeholders are involved. A single consolidated review is usually easier to act on than conflicting messages from different people.

Ask for a proposal you can compare

A useful proposal describes the deliverables, assumptions and responsibilities. Look for a page or template list, design and development scope, content ownership, testing and launch support. Ask what happens when a requirement changes.

You should also understand who owns accounts, which third-party charges remain and what support looks like after handover. These details help compare proposals on the work being delivered, rather than on a headline price alone.

• Scope, exclusions, milestones and acceptance checks.
• Ownership of content, accounts and operating access.
• Launch responsibilities and the approach to follow-up fixes.