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.
1. What business task should the website support?
Start with why the company needs a new website and what you want visitors to do.
For example:
- request a quote;
- book a consultation;
- choose and buy a product;
- review the terms of working together;
- share information with a purchasing department;
- find the right contact or document.
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.
2. Who will use the website?
Describe your main visitors and the questions they bring.
For a service business, clarify:
- who selects the provider and who approves the purchase;
- how well the customer understands the service;
- what information they compare;
- what prevents them from getting in touch;
- which languages and markets matter.
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.
3. Which pages and content are included?
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:
- unique page types;
- pages built from a shared template;
- the initial amount of content to be added;
- content your team will add independently after launch.
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.
4. Which functions must work?
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:
- what data the visitor enters;
- where it is sent;
- what happens after a successful action;
- how errors are handled;
- who receives a notification;
- which accounts and access permissions already exist.
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.
5. Who prepares the content?
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:
- writing or editing copy;
- selecting and processing images;
- translation and adaptation;
- populating the catalogue;
- migrating content from the old website.
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.
6. What are the design and editing requirements?
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:
- text and images;
- prices and terms;
- services and products;
- articles and case studies;
- language versions.
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.
7. What are the budget, deadline and scope of the first version?
State your available budget or a range. This helps the provider suggest a realistic first version.
Divide requirements into three groups:
- essential for launch;
- desirable if the budget and schedule allow;
- suitable for a later phase.
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.
8. Who makes decisions, and how is completion checked?
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:
- where decisions are recorded;
- how feedback is submitted;
- how much time is allowed for responses;
- how new requests are estimated;
- what criteria are used to accept each stage.
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.”
A short website brief template
Copy this list and complete it before discussing the project:
- Business and offer: what you sell and to whom.
- Website purpose: the primary action you want visitors to take.
- Audience and markets: who decides and which languages are needed.
- Visitor sources: search, advertising, referrals and other channels.
- Pages: the list, purpose and initial amount of content.
- Functions: form, booking, payment and integration workflows.
- Content: what is ready, what is missing and who prepares it.
- Design: brand assets, examples and constraints.
- Editing: what your team must be able to update independently.
- Budget and launch: a range, preferred date and essential first-version scope.
- Approval: the owner, participants and feedback process.
- Acceptance and handover: completion criteria, access, source files and training.
- Open questions: what the provider needs to investigate or propose.
What should follow the brief discussion?
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.