How to write a website brief for your business

A useful website brief explains who your business serves, what visitors need to do and what the project must include. Add the content you already have, the decisions still outstanding, your budget range and any genuine deadline. You can start in a shared document; you do not need technical terminology or a finished design.

For South African small and medium-sized businesses, the details that make a brief useful are often practical: which areas you serve, whether customers need a quote or an online checkout, who answers enquiries and who can approve the work. This guide helps you turn those details into something a designer can scope.

Start with the customer and the next step

Describe your main customer in plain language. Include what they are looking for, where they are based and what they usually ask before buying. If you serve several audiences, identify which one the first version should prioritise.

Then choose the main action the website should support. Requesting a quotation, booking an appointment and buying a product are different journeys. Explain what happens after the visitor takes that action, including who receives the request and what information they need.

Avoid targets you cannot support, such as a promised number of enquiries. State the intended improvement instead: helping customers identify the right service and send the details your team needs.

Separate launch requirements from later ideas

List the pages you expect, with a sentence explaining each page’s job. A service page might explain who the service is for, what is included and how to enquire. If you are unsure which pages matter, use our guide to what a small-business website should include as a starting point.

Describe features as tasks. “Customers need to request an appointment, which we confirm manually” is clearer than “add a booking system”. If customers must choose a live time slot, pay a deposit or receive automated reminders, say so explicitly.

• Needed for launch: the pages and actions required for the first usable version.
• Optional: useful additions that can be quoted separately.
• Later: ideas that should inform planning but are outside the first build.

For an online store, note your product range, variants, delivery areas and how orders will be handled. For a multilingual site, name the languages and who will supply and approve translations. These details affect the work even when the visual design looks simple.

Assign content and approval responsibilities

Gather your logo, brand colours, service descriptions, business details and original photographs. Mark each item as ready, needing revision or still to be created. Agree who will write the copy and whether photography or other content work needs a separate quote.

For each planned page, name one person who will supply the information and one person who can approve it. These may be the same person. Consolidate feedback before sending it to the designer so conflicting requests can be resolved inside the business.

Include trading hours, public contact details and accurate service areas. If customers cannot visit your premises, explain that rather than implying a walk-in location. Supply testimonials, logos and project photographs only when you have permission to use them; do not fill gaps with invented endorsements.

Choose a few reference websites and explain what you like about each: a clear menu, readable product information or a simple enquiry flow. References should communicate preferences, not ask the designer to copy another business’s branding or content.

Record existing accounts and website constraints

If you already have a website, include its address and identify who manages the domain, hosting and website platform. List connected services such as business email, forms, booking tools and payment providers. You are making an inventory at this stage; do not put passwords or recovery codes into the brief.

Explain anything that must keep working during the project. For example, business email may use the same domain even if the website moves. Note important existing page addresses and customer links so the designer can plan how to preserve them or redirect them when necessary.

Agree how access will be provided through the relevant service’s invitation or permission settings where available. Also record which business account should own each service and who will receive renewal notices after handover.

Make the budget and deadline useful

Give a budget range in rand and distinguish the website build from ongoing costs. Ask the quote to identify domains, hosting, platform subscriptions and any other third-party charges separately, and to state how VAT is treated. This is a request for clarity, not an assumption that every supplier charges the same way.

Describe why your preferred launch date matters. A date tied to a confirmed event is different from a general preference. Include when your content will be ready and when your team can review drafts, then ask the designer to confirm a feasible schedule.

If the scope exceeds the budget, ask which requirements can move to a later phase. Compare quotes against the same brief, including revision rounds, content responsibilities and handover. Our website cost guide explains the main factors to compare.

Copy this outline into your brief

Use these prompts as working notes. Write “to discuss” where a decision needs advice rather than guessing a technical answer.

• Business and audience: What we offer, who we serve and the areas we cover.
• Primary action: What a visitor should do and how our team handles the next step.
• Launch scope: Required pages and features, plus separate optional and later lists.
• Content: What is ready, what is missing and who supplies and approves each item.
• Design direction: Brand assets, reference links and the reasons behind our preferences.
• Existing setup: Current website, account owners and services that must keep working.
• Budget and timing: Build budget, recurring-cost expectations, target date and dependencies.
• Acceptance and handover: Launch checks, final approver and responsibility for future updates.

Agree what ready to launch means

Ask the designer to turn the agreed brief into a written scope. Before approving launch, check the core visitor journey on a phone and desktop, review business details, follow important links and confirm that a test enquiry reaches the intended recipient. A visible success message alone does not confirm delivery.

Agree what you will receive at handover: relevant account access, instructions for agreed updates and a clear arrangement for ongoing changes. If specialist legal or policy content is needed, assign responsibility for supplying and reviewing it rather than assuming the design project includes that advice.

The brief does not have to settle every question. Its job is to make the known requirements and open decisions visible so both sides can agree what is being built.