A request such as “we need a modern ten-page website” starts the conversation, but leaves many questions unanswered when estimating the work. Those pages may have different structures, content and functions. A form might send an email or create an enquiry in a CRM. The content may be ready, or it may exist only as notes.
A website brief describes the task clearly enough for a provider to suggest a suitable solution and explain the cost. For the client, it provides a basis for comparing proposals and checking the finished work.
Clear answers to the main questions are enough for an initial discussion. You do not need to know the technical solution to every task in advance: list unresolved questions separately.
Start with why the company needs a new website and what you want visitors to do.
For example:
If there are several goals, prioritise them. A website designed to generate new enquiries may need different content from one supporting complex B2B sales.
Also specify where visitors will come from: search, advertising, social media, referrals or direct contact. This helps establish what someone already knows before arriving and what the page needs to explain.
“Increase sales” needs a more specific definition. A brief is more useful when it describes a journey the website can influence: for example, helping a visitor choose a service and submit a sufficiently detailed enquiry.
Describe your main visitors and the questions they bring.
For a service business, clarify:
Go beyond age and location. A person's role and task are often more relevant to the website structure.
For example, a manager may need an explanation of the project's business value, while a specialist needs specifications, compatibility information and an implementation process. If both participate in the decision, the website should help each find what they need.
List the pages and the purpose of each. “Services” might mean a single overview page or a section with separate pages for ten services.
Distinguish between:
For example, “we need an article template and five finished posts uploaded” is more precise than “we need a blog”.
For each important page, specify the visitor's main question and next step. This makes it easier to assess the structure and avoid developing sections whose purpose has not been defined.
If you are choosing between an existing foundation and a custom structure, first review the differences between a template website and custom design.
Describe each function as a complete user journey.
Instead of “connect the CRM”, write:
The visitor selects a service and enters their name, work email and comment. Submission creates an enquiry in the CRM with the selected service and the page URL. The responsible employee receives a notification.
This is an illustrative example. The actual fields, processing rules and connection method depend on the project.
For forms, bookings, payments and other integrations, clarify:
Name the services and subscription plans you use. Check whether the required connection is feasible before the final estimate, particularly when it depends on an external system.
List what is already available: copy, photographs, a logo, prices, case studies, product information, translations and documents.
Every missing item needs an owner and a delivery date. Agree separately whether the provider's work includes:
For a multilingual project, clarify whether the offers, contacts and page lists are the same in every version. Translating text and developing a separate version for another market can involve different amounts of work.
Prepare your brand assets and a few website examples. Explain what you like about each: navigation, composition, presentation of services, photography or the way a form works.
“Make it like our competitor's website” leaves too much room for interpretation.
Also specify what employees will update independently after launch:
This affects the platform choice and how the website is built. If you already use Tilda, WordPress or Webflow, say so and explain which capabilities you want to retain.
State your available budget or a range. This helps the provider suggest a realistic first version.
Divide requirements into three groups:
If the launch date depends on a trade show, advertising campaign or seasonal opening, explain the connection. Agree what must be ready by that date: a published website, payments, all translations or only the main service area.
Our article on website development timelines and common delays explains how to turn these conditions into a schedule.
Appoint someone to collect feedback and confirm decisions on behalf of the business. Identify the people involved in approval: management, marketing, sales and a technical specialist.
Agree in advance:
Completion criteria should be verifiable. For example: “The form sends data to the agreed CRM, the employee can see every required field, and the visitor receives confirmation.”
Copy this list and complete it before discussing the project:
The discussion should produce an agreed scope, the assumptions behind the estimate and a list of questions still to resolve.
Ask the provider to identify exclusions separately: additional pages, translations, paid services, non-standard integrations and ongoing support. If something has not yet been investigated, the proposal should explain how it affects the estimate.
To learn about our approach, explore our multi-page website development service and commercial proposal. The scope of your project is agreed from your brief.
A good brief helps everyone agree on the result before development begins. Clear workflows, content responsibilities and scope make proposals easier to compare and changes easier to manage.