Write a website brief a provider can quote

Describe the business and the decision

Explain what you sell, who buys it and what makes a customer choose you. Name the action the website should support. Include your current address if there is a site to review and describe the specific problem you want to solve.

Instead of ‘we need a modern site,’ try ‘customers cannot tell which services cover their project, and our team spends time answering the same questions.’ The second description gives a provider a problem they can design around.

List the required scope

• Pages or sections you know you need, with a sentence about each.
• Forms, booking, ecommerce or other functions that must work.
• Existing systems that the site needs to connect to.
• Content that must move from the old site, including important page addresses.
• Who supplies writing, images, product data and approvals.
• Who needs to edit the site after launch and what they will change.

Mark items as essential, optional or undecided. You do not need to choose the technical solution in advance. Describe the behaviour you need and ask the provider to explain an appropriate approach.

State the constraints honestly

Share your budget range if you have one, including whether it covers content and ongoing services. If you do not know, ask for a base scope and separately priced options. This makes trade-offs easier to understand.

Give the desired launch date and the reason for it. Mention approval steps, seasonal availability and any external team involved. A deadline tied to an event is different from a preference, and the provider needs to know which it is.

Explain what you like about references

Pick two or three sites and explain the specific thing you like: a clear service comparison, readable project pages or an easy booking process. A reference is a discussion aid, not a request to copy someone else's work.

Also name anything you want to avoid. For example, your staff may need simple editing, or your customers may need a fast page while using mobile data. Practical reasons are more useful than a long list of visual adjectives.

Define the handover and the finish

Ask for a launch checklist, account access, editing guidance and a description of ongoing support. Define who signs off and how feedback will be collected. Include a small set of acceptance checks, such as successful enquiry delivery and the ability to edit a service page.

Send the same brief to every provider you are comparing. Keep their questions and your answers together, then circulate changes that affect scope. That creates a fairer comparison and a clearer starting point for the agreement.