Start with the business problem
Write down why the project matters now. Has the business moved into a new market? Are enquiries coming from the wrong customers? Does the website describe services you no longer provide? A specific problem gives the project a useful starting point.
For example, a hypothetical Sunshine Coast consultancy might want fewer unsuitable enquiries and more conversations with organisations that need an ongoing service. That calls for different content and qualification questions from a business trying to increase online bookings.
Describe your customers and their decisions
List your main customer groups, the situations that bring them to you and the questions they ask before committing. Include objections your team hears in real conversations. Price, suitability, availability, process and evidence of relevant experience often need answering before someone is ready to enquire.
For each audience, name one useful next step: request a quote, book an appointment, compare services or call your team. This helps keep navigation, page content and calls to action connected.
Gather the content and proof
Make an inventory of what already exists and what needs creating. Include service descriptions, staff information, photographs, product data, downloads and frequently asked questions. Identify who owns each item and when they can supply it.
Separate approved evidence from material that needs checking. Customer quotes, project screenshots, logos, qualifications and performance claims should be accurate, current and cleared for the intended use. A short, well-supported example is more useful than an impressive claim nobody can verify.
Make functionality concrete
Describe what each feature needs to do, who will use it and which system it must connect to. Instead of writing “CRM integration”, explain which form fields should be transferred, where they should go and what should happen if the transfer fails. Never include passwords in a project brief.
- Forms: required fields, recipients, spam controls and confirmation messages.
- Bookings: availability, cancellation rules and existing booking software.
- Commerce: products, payment methods, delivery options and inventory.
- Editing: who updates the site and which information changes most often.
Set the project boundaries
Share a realistic budget range, any immovable dates and the reason behind them. List what must be ready at launch and what can wait. Include the person responsible for final approval, who supplies consolidated feedback and any internal review requirements.
For a replacement site, note which existing pages, downloads and search traffic need protecting. Ask for a URL and redirect plan rather than assuming everything can be replaced without consequences.
Agree how success will be checked
Choose measures tied to the original problem. These might include qualified enquiries, completed bookings, useful phone calls or less time spent answering repetitive questions. Record the starting position where data is available and agree who will review results after launch.
A brief does not have to be long. Clear decisions, known gaps and named responsibilities are more valuable than pages of design adjectives. Use the questions above as a working checklist, then discuss the unknowns before scope and pricing are finalised.