How to plan a small business website: the brief that saves you money

Start with the job your website must do and the customers it serves. Then put what you know about pages, content and budget into a short brief. A first meeting can work with gaps, as long as they're visible. Close each gap before you approve the build.

Short on time? Skip to the brief template below. Fill in what you know and mark the rest as open.

Start with a usable brief

A website brief doesn't need to be perfect. It needs to be usable. A designer should be able to see the problem and the gaps.

The minimum useful pack covers:

• the business goal you're working towards

• what customers need to know before they act

• the pages you expect to need

• where your content stands today

• budget, timing and other constraints

• the questions you can't answer yet

The brief itself can stay short. Put the page inventory and asset list in appendices.

A brief, a proposal and an agreed scope are three different documents:

A template like the one below helps you write the brief. It doesn't replace contract terms.

Clear scope helps you avoid rework caused by:

• decisions nobody made in time

• content that arrives after design has started

• a page list that keeps changing

• assumptions nobody wrote down

You don't need hosting or a website builder yet. Work out what the site has to do first. This guide is one part of our small business website guide. That guide covers the whole build.

Choose the goal and success measures

Name one main business outcome first. Then name the visitor action that leads to it, and how you'll know it's working. Business.gov.au's website guide makes the same point: decide what the site should achieve first.

For a trade business, that might be quote requests from the right suburbs. A consultant might want booked discovery calls. An online store wants completed orders. A professional services firm might want enquiries about specific matters.

A business can serve several audiences or goals. Each page still needs a clear priority. Visitors can still take different paths through the site.

A phone button click is an interaction. It isn't proof of a completed call, a qualified lead or a sale.

Then set up a short measures table. A new site may have no baseline yet. Write "to be established" rather than guessing a number:

Add a review period and an owner for each measure.

Here's an example from one finished batch of enquiries. Thirty enquiries came in. The owner qualified twelve. Three of those became customers:

• 12 of 30 enquiries were qualified, so 40% were qualified

• 3 of the 12 qualified enquiries became customers, a 25% close rate

• 3 of all 30 enquiries became customers, a 10% close rate

Each uses a different base. Show it every time. Without a visitor count, none of these is a traffic conversion rate.

Check the business can handle the enquiries the site is meant to bring. The goal should fit your capacity, service area and margins. If you compare results before and after launch, note any changes in traffic mix, offers and season. Do that before you credit the design. For an existing site with few enquiries, start with why a website gets too few enquiries.

Understand customers and their questions

Customers arrive with questions. The site's job is to answer them in the order they come up.

Start with the usual ones:

• Do you cover my area?

• How quickly can you help?

• What should a first time buyer know?

• Roughly what will it cost?

• Why should I trust you?

• What might stop me going ahead?

Add access needs, the device people use and their language where those matter to your audience.

This is an example service enquiry, not measured behaviour. Next, note where each question came from. Good sources include permitted sales notes, support queries, short interviews and existing search data. Keep personal customer details out of it. Here's an example evidence log:

Turn each question into a requirement. Say callers keep asking whether an electrician covers their suburb. The site then needs a clear, truthful service area answer that's easy to find. A page for every suburb isn't automatically the answer.

Mark untested assumptions so they get checked. Competitor sites and search volume can suggest topics. Neither proves your customer's task is solved. A few conversations with real customers can show problems quickly. Just don't present them as a representative study.

A common mistake is copying a competitor's FAQ and calling it customer research.

If you're a sole trader, keep it light. A note of the question, where it came from and what you decided is enough. You don't need detailed personas before a first meeting.

Prioritise services and page needs

List every offer, then group them. Rank the groups by demand, value to the business and your capacity to deliver. Note which ones raise distinct questions of their own. Also ask which offers you shouldn't promote yet.

A separate service page needs a useful purpose, enough distinct information and a clear route to action. Search demand is one input. Closely related variants may belong together when separate pages would repeat the same answer.

Search demand alone doesn't justify a page. For the detail, see planning useful service pages.

Then sort every need into launch, later or excluded. Here's how the example electrical business used in this guide sorted its needs:

Add a decision owner for each row. An ongoing SEO campaign sits outside the launch budget too. None of the excluded items is automatically required for a small site.

Count pages and templates separately. Eight pages built from three layouts is a different job from eight one off designs. Products, filters and account areas change the scope too.

If scope is uncertain, state an allowance or a discovery task. Avoid open ended promises like "all pages needed".

Choose the platform after the requirements. Match it to the functions you need, who'll edit the site and how easily you could leave. When you're ready, compare website platforms using our platform guide.

Plan a simple sitemap

A planning sitemap shows your pages and how they sit together. An XML sitemap is something else: a file that tells search engines about your pages. A wireframe is different again, showing the layout of one page.

Business.gov.au also suggests a sitemap that groups related pages. Here are starting points for six common business types:

These are starting points, not page targets. Policy and transaction pages depend on the business. They're still needed when they sit outside the main menu.

Treat clinics and salons separately when their legal or privacy needs differ. Check sector advertising rules before using health testimonials or before and after photos. For worked examples, see websites for trade businesses and websites for professional firms.

The example business launches with eight pages:

The count includes Home and Privacy. The tree shows how pages relate. It doesn't have to match the URLs. Everything marked later or excluded in the scope table stays out at launch.

Then give each page a job:

Add existing and proposed URLs when you're redesigning. Link pages so customers can reach their next question easily. The wider method lives in planning website structure.

Prepare content and proof

Design needs real content to work with. Start with the raw facts:

• your correct business name and contact details

• opening hours and the areas you really serve

• what each service includes and leaves out

• how the job runs, and what affects the price

• common questions and their answers

• staff details you're happy to publish

Then gather the assets you already have:

• existing copy and project descriptions

• original photos of your work and team

• logos, brand colours and font files

• reviews you have permission to use

Record the rights and approval status of each one. A stock photo or a badge you can't back up doesn't prove anything about your business. The ACCC's review guidance says fake or misleading reviews are illegal. For collecting them properly, see using and requesting reviews properly.

Three roles matter here. The owner supplies and checks the facts. The writer turns them into copy. The approver signs it off. That may be the owner again.

Set dates for anything that blocks design or development. Final copy doesn't need to exist before a first meeting. Representative content does need to exist before layouts are signed off.

Include the small text too, like error messages and confirmation screens. Downloadable documents count as well. For the example business, the content tracker looks like this:

Add due dates when you build your own. The example leaves out licence numbers, customer names and claims history on purpose.

Content can change the layout. If a final service description runs much longer than the mock up, agree whether the design needs adjusting. Don't treat it as a minor text swap.

A common mistake is approving layouts with placeholder text, then pouring in copy twice as long.

For the writing itself, see writing clear website copy. The homepage gets its own treatment in planning homepage copy.

Research competitors and choose a direction

Look at three to five competitor sites. That's a practical starting point, not a research standard.

Compare how clearly they explain offers, answer questions and show proof. Check how easy the main task is too. A quick look can't tell you their conversion rate, revenue or accessibility. Verify any claim before you borrow the idea.

The split is a practical guide, not a legal test for copying. Annotate each reference: what works, for whom and why. "Their menu is easy to use on a phone" is something a designer can act on. "Make it modern" isn't. Record dislikes the same way.

Describe the tone and imagery you want, plus any essential brand rules. Don't copy a competitor's wording or distinctive design. That includes their images and code. Check that font and image licences cover how you'll actually use them before anything goes live.

Accessible colour, readable text and keyboard use belong in the requirements. Attractive screenshots can't show whether the real journey works.

Set budget, timing and project stages

Budget for the whole project, not just the build. Market price ranges live in what a website costs. Here, it's your own numbers.

State the currency and whether amounts include GST. Separate one off charges from recurring ones. List what's included and what isn't.

Cover every part that applies:

• discovery and design work

• the build itself, including page templates

• copy, photography and other imagery

• moving content across from an old site

• integrations, plus time for testing

• training and support after launch

Count your own time separately from cash costs. Check every subscription, from the domain to plugins, so bundled items aren't counted twice.

Here's an example first year budget. It isn't an Elev8d quote or a market benchmark:

The planned spend adds up to $6,100: build, content and the first year's recurring services. With the $900 reserve, the funding envelope is $7,000. All figures are in Australian dollars and exclude GST.

The reserve is spent only if something needs it. The whole $7,000 isn't a committed cost. Later years need their own budget for recurring costs and improvements. The first year's content cost doesn't automatically come back every year.

Plan the stages around what each one depends on:

The timeline shows order and dependencies. It isn't a promised completion date. Record your input dates, when reviewers are free and what must finish before the next stage starts.

If the deadline is fixed, ask which scope can move and which requirements can't. Customer safety, working transactions and material legal requirements don't get dropped for a campaign date. Keep an explicit launch decision and a way to roll back.

For a rough starting range, try the website cost estimator. It gives a planning range, not a quote.

Plan access, SEO and technical requirements

Write down who controls each account the site depends on, including hosting, email and analytics. DNS is the set of records that points your domain at your site and email.

Here, agency means whoever you've assigned, like your developer or host. The CMS is the content management system where pages get edited. A CRM tracks enquiries and customers. The map shows what to agree, not Elev8d's terms.

Your designer doesn't automatically need admin access to everything. Send individual invitations with only the permissions needed. Use multi factor authentication (MFA) wherever a service offers it, including for your own logins. The brief records who controls access, never the passwords.

For a com.au domain, check the registrant is your business. That's whoever holds the domain licence. Under auDA's rules, someone can register one for you with written permission, using your details. The details given decide who holds the licence. A developer's account isn't proof your business controls the name.

A common mistake is letting the developer register the domain in their own name.

Search and existing pages

For a new site, plan how people will find it and which offers deserve pages. Launching a site doesn't create demand on its own. For an existing site, list useful URLs and content before removing or changing anything.

If URLs change, map each old page to its closest new one and redirect it. Google's site move guidance explains the mapping and checks. Don't send every old page to the homepage, and don't expect zero search impact. The full process sits in protecting search visibility during a rebuild.

Devices, speed and accessibility

Agree the basics up front:

• the devices and browsers you'll support

• outside tools the site can't work without

• editing tasks your staff need to do themselves

Set performance test conditions and an owner, rather than chasing a perfect score.

Accessibility belongs in the requirements and the testing, as well as the design. Name an agreed standard and scope, such as level AA of WCAG 2.2, the W3C's accessibility guidelines. Include customer tasks and any embedded booking flow. W3C says no tool alone can determine whether a site meets accessibility standards. A plugin or automated pass isn't compliance.

W3C's planning guidance lists steps like assigning responsibilities, setting a budget and evaluating early and regularly. Bring in a qualified reviewer. Plan how issues get fixed too.

Integrations and ownership

Keep a simple register of every integration. Here's the example business:

Also note who supplies each one, what data it sends and what the subscription costs. Confirm a connection is supported before assuming a custom integration fits a basic build.

Agree who handles updates, backups and restores after launch. Record which software and content rights transfer to you. Some platforms and plugins stay paid subscriptions. You can own your content and still need an ongoing licence.

Plan and test the enquiry path

Map the full route an enquiry takes:

• the main action on each page

• only the fields needed at this stage

• a clear confirmation message

• where the enquiry goes once it's sent

• who responds, and how quickly

• how you'll judge whether it's a good lead

Add a fallback for when the form fails, like a phone number shown on the page.

Ask only for what you need

W3C's forms tutorial says to ask only for what's required to complete the task. It adds that excessive questions make people more likely to abandon a form. Use clear labels, instructions and error messages.

Not every form needs both phone and email as required fields. Don't collect sensitive details just in case. Judge the form on the quality of enquiries, as well as how many finish it. Designing a useful enquiry form goes deeper.

Check your privacy duties

A form doesn't automatically mean the Privacy Act applies. The OAIC's small business guidance says businesses with turnover of $3 million or less generally aren't covered. Some are covered regardless, like health service providers and businesses that trade in personal information.

If you're covered, plan a collection notice as well as a privacy policy. APP 5 is the Australian Privacy Principle on collection notices. The notice goes at or before collection, or as soon as practicable after. Other laws, sector rules and platform terms may apply too. See Australian privacy requirements for who's covered, and website privacy information for the wording.

Don't quietly turn a quote request into a marketing subscription. Record how you'll use the data, who receives it and how long you'll keep it. Decide your consent approach too.

Test before launch

Test the real setup end to end before launch:

A button click alone doesn't prove delivery. Protect personal data and avoid live transactions during tests. Agree the launch tests in writing:

Add an approver for each test. The website launch checklist helps with the final stage.

Measure the result

Track a confirmed successful action with a defined event. Test for duplicates. Match counts against your own records. A success screen can show even when the email fails. Event totals aren't lead counts.

Google Analytics rules ban sending data that could identify a person. Keep names, emails and form messages out of it. Setup help is in Google Analytics 4 for small business.

Keep launch acceptance separate from commercial results. You can't fairly require a set number of sales before go live. You can require a working, tested journey and a plan to measure outcomes.

A common mistake is approving a form because the thank you page appeared.

Simple website brief template

Here's the full brief to copy. Use short, factual answers. Mark each unknown and name who'll resolve it. Keep requests separate from agreed inclusions.

Never put passwords, customer records or confidential contracts in it. Attach your page inventory and content tracker.

Copy the brief template into your own document to fill it in. Keep the worked example below separate. Its made up answers don't belong in your brief.

Worked example brief

Here's the same brief filled in for an example electrical services business. It isn't a client, a quote or a measured result.

Three services get their own pages because this example assumes each has distinct needs and enough real content. That isn't a rule for every electrician.

The owner approves every claim and the service area. The writer works only from approved facts. Testimonials stay out until permission and accuracy are checked. The owner's preparation time is separate and isn't priced.

The first year's recurring services cost $600. The next renewal gets its own review.

A change after layout approval

Now the owner wants two extra service pages. That's two hours of copy and three hours of build and testing, at an assumed $120 an hour. If it's approved and paid from the reserve, the numbers move like this, excluding GST:

The effect on timing needs its own agreement, because billable hours don't set the schedule.

None of this means the $600 was wasted. A valuable new service can justify a change. The process just makes its scope, cost and timing visible.

Prepare the meeting and manage changes

Before the first meeting, check you've got these covered:

Questions worth asking at the meeting:

• What's assumed in this quote?

• What do we need to supply?

• Which functions need investigation?

• How many revision rounds are included?

• Who approves each stage?

• What proves the work is complete?

• What support and licences continue after launch?

• What happens if either side changes the scope?

Name one person who can make decisions, plus any specialist reviewers. Consolidate feedback into one list. Record the version and date, and agree how fast each side responds. Silence isn't approval.

Not every correction is a chargeable change. If the agreed scope already covers it, fixing it is a defect fix rather than new work.

A discovery conversation can go ahead with unknowns. Hold the build commitment until each big assumption has an agreed answer, allowance or limit.

A high checklist score doesn't mean yes while a critical integration is still unresolved. Watch for these before you sign:

• content that nobody has agreed to own

• a page list with no limit

• design references copied rather than explained

• dependencies on other systems that nobody mentioned

• missing access to key accounts

• no plan for testing before you accept the work

Once the brief is ready, use choosing a web designer to compare suppliers against it.

What we recommend at Elev8d

Frequently asked questions

Next steps

Pick the step that fits where you are.

Written by Ajay K.Co-founder, Elev8d

Ajay is the co-founder of Elev8d and writes most of what you will read here. Psychology grad turned marketer, which is a fancy way of saying he cares about why people click, not just where things rank. Every guide is written in plain English for Australian businesses, tested on real campaigns before it earns a spot on this site.