How to Prepare a Small Business Website Brief

A website brief records what your business needs the website to do, what work is included and how you will decide whether it is ready. For a New Zealand small-business owner, it is a practical way to make supplier conversations more specific before choosing a design or accepting a quote.

You do not need a technical specification to start. You need clear answers about customers, pages, content, essential features, budget and responsibilities. A useful brief can also explain what you have not decided yet, so suppliers can identify assumptions instead of silently making them.

This article provides a reusable brief and a completed fictional example. It supports our Small Business Websites in New Zealand guide. Omniva Digital publishes this resource and provides website services; you can use the template with any provider.

Describe the most important action a suitable customer should be able to complete. “A property manager can check our cleaning services, see our operating area and request a site assessment” gives the project a clearer purpose than “build a professional five-page website”.

Then describe the problem with the current situation. Perhaps your business has no useful page to share after a referral, customers cannot understand the differences between services, or staff repeatedly ask for missing enquiry information. Check whether an improvement to the existing site could address the problem before assuming a rebuild is necessary.

Separate launch requirements from ideas for later. An initial enquiry form may be essential; a customer portal may depend on a workflow that is not ready. Ask what happens if a feature is omitted from the first version. If the website can still support its main task, the feature may belong in a later phase.

Record constraints too: who can approve content, which dates are fixed, whether staff can maintain the site and whether an existing booking or sales system must remain in use. These details affect a realistic proposal.

Copy the following prompts into your own document. Answer in plain language and mark uncertain items as questions for the supplier. Keep the working brief private until you have checked that it contains only information the recipient needs.

1. Business and audience: what do you sell or provide, who is the website for, and which enquiries or purchases are suitable?
2. Purpose: what should the main customer action be? What problem should the project solve?
3. Scope: is this a first website, focused improvement or replacement? What is essential for launch, and what can wait?
4. Pages: which questions must be answered, and which pages are likely to contain the answers?
5. Content: who will supply, write, check and upload text, photographs, products and project examples?
6. Features: what must forms, bookings, payments or other connections actually do? Which systems are involved?
7. Budget: what is available for the build, and which ongoing costs must be included? State currency and the GST basis used for comparison.
8. Timing and approvals: which dates depend on content, feedback or another system? Who makes final decisions?
9. Ownership and care: who controls the domain and accounts, makes updates, pays renewals and handles problems?
10. Acceptance: what tasks must pass before launch, what is handed over, and how will useful results be reviewed?

Add the existing website address and links to examples you find useful. Explain the particular feature you like, such as an understandable service comparison or a readable mobile enquiry flow. A collection of screenshots without reasons leaves the provider guessing.

A page list describes structure; a content inventory describes the material needed to fill it. Keep both. For each proposed page, record its purpose, main customer question, required evidence, next action and content owner. This exposes missing work before the design is waiting for it.

For example, a services page might need approved descriptions and exclusions. A project page might require permissioned photographs and an explanation of your role. A contact page needs accurate details and an agreed response process. Do not assume a designer will write all of this unless the proposal says so.

For a feature, describe the result rather than just naming a tool. “A customer chooses an available appointment and receives an accurate confirmation” is a requirement. “Add a booking widget” leaves availability rules, cancellations and staff responsibilities unresolved.

Identify connections that may need separate accounts, subscriptions or permissions. Note who will configure them and who will test the complete journey. Provide access through appropriate invitations when needed; do not put passwords or recovery codes in the brief.

If a form collects personal information, include the intended purpose and privacy requirements in the scope. The NZ Privacy Commissioner's collection guidance explains collecting necessary information and telling people how it will be used.

A budget helps the provider suggest an achievable scope. Separate the project allowance from domain registration, hosting, email, software, ongoing care and later content changes. State whether the amounts being compared include or exclude GST. Do not add a cost twice when a subscription already includes it.

Ask for the proposal to identify inclusions and assumptions. “Up to five pages” does not explain who writes them, how much product entry is included or how many feedback rounds are expected. A scope can be short while still naming those responsibilities.

Nominate one person to consolidate feedback and a final approver. Conflicting messages from several staff can create rework, especially when they arrive after a decision has been approved. Keep a record of agreed changes and their effect on cost and timing.

Discuss what happens when a new requirement appears. The supplier should explain whether it fits the agreed scope or needs a separate estimate before starting it. Avoid leaving that decision until the final invoice.

Use our NZ small-business website cost guide for wider pricing context, then obtain a proposal for your actual requirements. A general guide cannot establish the price of your particular project.

The example below is invented to show the level of detail that helps a supplier respond. It is not an Omniva client, quote or forecast. Replace every business-specific statement before using it.

• Business: a small office-cleaning team serving its agreed operating area in New Zealand. It wants recurring commercial work and does not offer residential cleaning.
• Customer: a property or office manager comparing routine cleaning arrangements.
• Primary action: request a discussion and, where appropriate, a site assessment. The website will not give an instant binding price.
• Launch pages: home, services, about, approved work examples, contact and privacy information. Services will describe genuine inclusions and exclusions.
• Content: the owner supplies accurate service details and approved photographs. The proposal must state who writes, edits and uploads the copy.
• Enquiry: collect a name, reply method, general location, service required and a brief description. A nominated staff member reviews requests during the business's stated hours.
• Later phase: a customer portal is excluded from launch while the business decides how recurring customer requests will be managed.
• Commercial discussion: obtain an itemised build quote and a separate schedule of recurring services, ownership, renewals and support.

This brief gives the supplier decisions to work with without prescribing colours or a particular platform. It also makes exclusions visible: no instant pricing, no residential-service copy and no portal in the initial scope.

A useful response would explain the proposed pages and enquiry flow, identify any missing information and state the assumptions behind the quote. It should not quietly add services, testimonials or outcome claims that the owner has not supplied.

Define acceptance in terms of tasks you can observe. Examples include reading important pages on a phone, opening the menu with a keyboard, updating a service description and sending a test enquiry that reaches its agreed destination. A screenshot of a success message alone does not confirm delivery.

Include checks for content accuracy, image permissions, contact links and any existing URLs that need an appropriate destination after a replacement. Ask the supplier to identify who will check search access, page titles, canonical URLs and the sitemap. These are technical checks, not a guarantee of indexing or rankings.

At handover, request an account inventory without secret values, editing instructions, renewal dates, maintenance scope and the support contact. For a .nz domain, the Domain Name Commission's guidance explains why the correct registrant and current registration details matter.

Agree what happens if a problem appears after launch and which work is charged separately. Updating software, changing copy and building another feature are different tasks. Naming the responsible person or role helps keep the website usable after the initial project ends.

Send the same brief to the providers you are seriously considering. Compare how they address the customer task, content workload, essential features, exclusions, support and handover. Ask about differences rather than judging proposals only by a headline price or page count.

If a provider recommends a different approach, ask which requirement it addresses and what trade-off it introduces. A smaller first phase can be sensible when important content or operating decisions are still missing. The brief should support that discussion and record the final agreement.

Before accepting, check that the written scope reflects the decisions you made together. Keep a dated copy and note who can approve later changes. If you want to discuss a build or improvement with Omniva, request a website quote and include your brief. For the wider planning process, return to the small-business website pillar guide.