How to prepare a business website brief

1. Define the main job of the website

Write one sentence describing the outcome you want: for example, helping prospective customers understand a service and make a relevant enquiry. This is an illustrative example, not a Moje client result. Separate that outcome from proposed features such as a video, calculator or customer login.

Describe the current problem using evidence you already have. That might be repeated questions from customers, an enquiry journey that is difficult on a phone, or information your team cannot update. Avoid setting a sales target that depends on traffic, pricing and follow-up without acknowledging those dependencies.

2. Describe the audience and their questions

Name the people who will use the site, why they visit and what they need before taking action. A first-time buyer may need a plain explanation of the service, while a returning customer may be looking for support. Decide which audience takes priority.

List the questions the website should answer: what you offer, who it is suitable for, how an engagement works, what information a customer should prepare and what happens after an enquiry. These questions provide a more useful starting point for pages than copying a competitor’s navigation.

3. Inventory content and proof

List the pages you expect to need and the person responsible for each page’s text. Identify existing brand files, approved photographs and materials that can be reused. Separate usable content from content that still needs to be written.

For testimonials, logos and case studies, record both the evidence and permission to publish it. A design concept should be labelled as illustrative. Do not assume a client’s name, screenshot or result can be published because the project exists. Content approval is part of the timetable.

4. Specify the enquiry and integration journeys

Describe what a visitor should do and what your team should receive. For a contact form, identify the minimum information needed, who handles the enquiry and how delivery failures should be handled. Avoid collecting confidential project data in an initial public form.

List any booking, payment, customer-management or other integrations. Include the system name, the task to connect and who can arrange authorised access. A developer needs to check interfaces, permissions and operating constraints before confirming that an integration is feasible. Do not put passwords or API keys in the brief.

5. Agree ownership, access and maintenance

Record who owns the domain, hosting account, source files and content. Explain which team members need to make routine changes and what they should be able to change. An editable website needs an agreed workflow, not just an editor.

Discuss backups, updates, monitoring and support after launch. Ask who is responsible, what support covers and how urgent problems are reported. Make handover and authorised access part of the scope so responsibilities remain clear when the project ends.

6. Make launch requirements testable

State the required launch date and explain why it matters. Identify any fixed event, dependencies and approval windows. If budget is constrained, say which outcome matters most and which features can wait. A priority list makes scope decisions easier than calling everything essential.

Agree acceptance checks before development finishes. Examples include usable navigation on a phone, readable content with scripting unavailable, complete enquiry delivery tests, accessible keyboard operation and redirects for important replaced URLs. The exact checks depend on the project. Treat search visibility as ongoing work; launching a site does not guarantee a position in Google.

A brief you can copy into your notes

Use the checklist below to prepare your first conversation. Short, honest answers are more useful than a long document with guessed requirements.

• Business and main website objective
• Priority audience and questions to answer
• Current website and problems to solve
• Proposed pages and content owner for each
• Approved project evidence and asset permissions
• Main visitor action and internal follow-up process
• Required integrations and known constraints
• Domain, hosting, editing and maintenance responsibilities
• Budget constraints, deadline and approval process
• Acceptance checks and outstanding questions