Websites and digital systems, forged around how your business works.

Most people asking for “a website” are describing two different things at once. One is the part visitors look at. The other is the part that decides whether an enquiry turns into work you can act on, or a message you rediscover a week later.

The two are usually quoted as one job, which is where the confusion starts. This explains the difference in plain terms, and — more usefully — how to tell which one your business actually needs, including the cases where a plain website is the right answer and spending more would be a waste.

What a normal business website does

A conventional business website presents information. It says who you are, what you sell, who you serve, and how to make contact. It might carry a portfolio, a service list, prices or a map. Done well, it is genuinely valuable: it makes you findable by people who do not already have your number, it answers the questions you would otherwise answer by phone, and it gives a referral somewhere credible to land.

For a straightforward informational website, the working journey may end at the contact form. The site sends an email, and the remaining steps — reading it, qualifying the request, replying and following up — are handled manually. That is not necessarily a weakness; for businesses with a simple process and manageable enquiry volume, it may be entirely sufficient.

Plenty of ordinary websites go further than this, of course: a shop has a checkout, a clinic may have booking, a membership site has accounts. The distinction drawn here is about how much of the work after contact the site carries, not about a hard line between two product types.

What a digital business system adds

A digital business system continues past the point where the website stops. Instead of handing you a message, it structures the request, records it, tells the right person, and keeps the thread alive until something is resolved.

Concretely, that means the work of receiving an enquiry stops being manual. The information you need arrives with the request rather than being extracted over three messages. The record lives somewhere you can search rather than in one person’s inbox. The follow-up happens because the system does it, not because someone remembered.

The important part is that this is not a different website. It is usually the same website with a working layer underneath.

The visible layer and the working layer

This is the distinction that matters most, and it is the one that gets lost in quotes.

The visible layer

Everything the visitor experiences: design, structure, copy, images, navigation, speed, how it behaves on a phone. This is what people mean by “the website”, and it is where almost all of the budget conversation happens.

The working layer

Everything that happens once the visitor acts. Where the enquiry goes, what shape it arrives in, who is notified, what is stored, what is sent back automatically, and what the customer can see afterwards.

Two sites can look identical and behave completely differently below the surface. The visible layer is what earns attention; the working layer is what turns attention into work you can bill.

What the working layer actually handles

These are the components, in rough order of how often they earn their place.

Structured enquiries. A form that asks the questions you would otherwise ask by hand — scope, location, timing, budget range, whatever qualifies a job in your trade. A structured form can also discourage incomplete requests, but it should ask only for information genuinely needed at that stage. An unnecessarily long form can create friction for suitable customers.

Quotation requests. A longer flow that captures enough to determine the next step. Where an exact price genuinely requires an inspection or a conversation, the flow says so rather than implying an instant number.

Document and photo upload. For work that cannot be priced without seeing something — a site plan, a drawing, a photograph of the space, an existing specification. The request and the evidence arrive together instead of three messages apart.

Bookings. Appointments, consultations, tables, slots. Availability is shown, the booking is recorded, and both sides get a confirmation.

Payments. Deposits, fixed-price products, or full payment up front. This is where a website stops being a brochure and starts settling money.

Automated email. An immediate acknowledgement so nobody wonders whether their message arrived, and scheduled messages afterwards — a reminder when a quote has gone unanswered, a check-in after a proposal. Worth saying plainly: none of this is guaranteed by installing it. Automated messages depend on correct configuration, successful email delivery, and someone noticing when delivery stops.

Reminders and follow-ups. The part most small businesses lose work on, not through indifference but because it is manual and easy to forget.

Client portals. A signed-in area where a client sees the current stage, what has been approved, what is waiting on them, and the files exchanged. Worth building for work that runs over weeks with several review points. Rarely worth it for short jobs.

The two compared

The last row is the one people underestimate. A system is not finished when it launches, because the business it describes keeps changing.

When a simple website is enough

A plain, well-built website is the right answer more often than agencies admit. It is usually sufficient when:

• You handle a small number of enquiries and none of them go missing
• Your work is quoted in conversation, not from a specification
• One person handles everything and holds the picture in their head
• Customers reach you on a channel that already works, and you are happy with it
• Your main problem is being found, not being organised

If that describes you, the money is better spent on how the site looks, what it says, and whether it can be found — not on automation you will not use.

When a business actually needs a system

The signals are practical rather than technical. A system becomes worth considering when:

• The same information is retyped into a quote or a calendar more than once
• Enquiries are answered late, or occasionally not at all
• Two people answer the same channel and neither is sure who replied
• You cannot answer “what is open right now?” without scrolling a chat thread
• Quoting requires a round of questions before you can even start
• Clients ask for progress updates often enough that it interrupts the work
• Something has to be true before you can invoice, and nobody records it

Notice that none of these are website problems. They are workflow problems that a website happens to be well placed to solve.

Plugin or custom build

This is where money is most often wasted, in both directions.

When an existing plugin is enough

In my experience most of this ground is already covered by the WordPress and WooCommerce ecosystem. It is worth being precise about what that means: WordPress and WooCommerce do not provide all of this by themselves. Core WooCommerce handles products, cart, checkout and orders; bookings, subscriptions, advanced forms, CRM and email automation come from third-party plugins and paid extensions, many of them commercial products with their own licences. WooCommerce publishes its extensions documentation if you want to see where the boundary sits.

If your process resembles how an existing plugin already expects to work, use the plugin. It is generally less expensive than building the same functionality from scratch, and its vendor is responsible for maintaining the core product. Premium licences, configuration, compatibility checks and ongoing support may still carry costs.

The honest test: can you describe your process in the plugin’s own vocabulary without fighting it? If yes, take the plugin.

When custom development is justified

Custom work earns its cost when the process is genuinely specific to your business and bending a plugin to fit would create something fragile. Typically:

• The qualifying questions are unusual, and the quote depends on how they are answered
• Several tools each hold one part of the picture and none holds all of it
• The workflow crosses a boundary — a quote becomes a job becomes an invoice
• You are paying for four plugins to achieve one outcome, and they disagree
• A plugin does 80% of it, and the missing 20% is the part that matters

A reasonable middle path is common: standard plugins for the ordinary parts, custom code only for the step that is actually yours.

What a system requires after launch

A working system introduces responsibilities that a simple informational website may not have. Forms must continue delivering correctly, integrations can fail, payment and booking rules change, plugins require compatibility checks, and stored customer information must be protected.

Before adding automation, decide:

• Who checks that submissions and notifications are still working
• Who can access customer records and uploaded files
• How backups and software updates are handled
• What happens when an automated step fails
• Which decisions still require human review
• How unnecessary personal information is avoided or deleted

Automation should remove repetitive work, not remove accountability. A system that nobody monitors can make a failed process harder to notice.

A practical example

Take a service business that quotes on site — a surveyor, a trades business, a cleaning company.

As a website: the site describes the services and coverage area and offers a contact form. Someone submits “I need a quote for my property.” You reply asking for the address, the size, the access, and when they need it. They reply to two of the four. You email again. Three days pass. You visit, quote, send a PDF, and eventually wonder whether to chase.

As a system: the same site asks those four questions in the request itself, with a photo upload where seeing the space changes the price. The request lands as a record with a status. The customer receives a confirmation saying what happens next. If the quote goes unanswered for a set number of days, a reminder is sent without you doing anything — provided the automation is configured correctly and delivery is being monitored. You can see, at a glance, which requests are open.

The design work is the same. The difference is in the working layer — and the potential saving is not merely one email; a well-designed request can reduce much of the back-and-forth required before the business can assess or quote the work.

A short self-assessment

Answer honestly. Each “yes” is a point.

1. Do you retype the same information into more than one place each week?
2. Has an enquiry been answered late, or missed, in the last month?
3. Do you need more than one exchange before you can quote?
4. Would you struggle to list every open request from memory right now?
5. Do clients ask for progress updates while you are working?
6. Does more than one person answer enquiries?
7. Do you chase unanswered quotes manually, or not at all?
8. Do you ask customers for documents or photos after they first contact you?

0–2 · A straightforward website may be sufficient. Prioritise clear content, credibility and discoverability, while checking that the current manual process remains manageable.

3–5 · Targeted workflow improvements may help. Start with the repeated step creating the most delay or re-entry, often enquiry structure or acknowledgement.

6–8 · Review the workflow before commissioning a redesign. Several answers indicate that organisation after contact may deserve as much attention as the visible website.

This is an indicative self-assessment, not a diagnostic. It reflects how the work feels to you today.

Where to go next

If the assessment pointed at your workflow rather than your website, that is the conversation worth having — and it starts with how the business runs now, not with pages or colours.

If you would rather review your existing site first, the Website Audit & Action Dashboard is a 60-check review system with impact weighting, category scoring and a linked action plan. Other checklists and tools are on the Resources page.

Why many website reviews change nothing

Many informal website reviews end the same way: a list of observations in a document, a few screenshots, and a conversation that runs out of time. Nothing is weighted, nobody owns anything, and a month later the same issues are still there.

The problem is rarely the observations. It is that a list of complaints is not a plan. An audit is more likely to lead to change when each finding has a severity, an owner and a next action attached to it — and when the trivial items are visibly separated from the ones that affect whether visitors can understand the offer or complete the website’s core task.

This is a method you can begin yourself without paid specialist software. Some checks use free services such as Google Search Console, while complex technical or accessibility findings may still require specialist investigation.

Before you start: define what the site is for

Decide the question before you start looking, or you will drift into redesigning things you simply dislike.

Write one sentence: what is this website supposed to achieve? Then write a second: what is the primary action — or small set of clearly prioritised actions — a suitable visitor should take? Everything you review afterwards is measured against those two sentences rather than against your taste.

Set aside focused time for the review. The duration will depend on the site’s size and complexity. Open a blank document or spreadsheet and prepare three columns: what you observed, where you observed it, and how serious it is. Work through the areas below in order — they run roughly from “what the business is” to “how the site behaves”, which provides a practical order for conducting the review.

Seven areas worth checking

A useful website audit is not a search for everything that could theoretically be improved. It is a structured review of whether the website explains the business, helps visitors complete the intended action and supports what happens afterwards.

Record the evidence you find, assign each meaningful problem an appropriate priority and turn every important finding into a specific action. The objective is not to produce the longest possible list; it is to distinguish cosmetic preferences from issues that affect clarity, usability, trust or business operations.

Business and goals

Start by defining what the website is expected to accomplish. A service-business website may need to generate qualified enquiries, explain services, support quotation requests or reduce repetitive questions. An online shop has a different objective: helping suitable customers evaluate products and complete a purchase.

Check whether the homepage identifies the business, its intended customer and the primary next step. Then examine whether each important page supports that objective. A visually attractive page can still be ineffective when its purpose is unclear.

Record:

• The website’s primary business objective
• The intended audience
• The principal visitor action
• Pages that do not support that objective
• Information the business needs but the website does not collect

Next action: if the objective and the primary action cannot be stated in one sentence each, settle that before continuing. Every later finding depends on it.

User experience and navigation

Review the website as a first-time visitor rather than as its owner. Important services, contact methods and purchasing information should be identifiable without understanding the company’s internal terminology.

Test the main journeys on desktop and a real phone. Confirm that navigation labels are understandable, buttons lead where expected, forms can be completed comfortably and visitors are not left at a dead end after submitting or purchasing.

Record:

• Unclear navigation labels
• Important pages that are difficult to reach
• Inconsistent buttons or calls to action
• Unintended horizontal scrolling
• Forms or controls that are difficult to use on mobile
• Pages with no clear next step

Next action: complete one full journey end to end on a phone — find a service, read it, submit an enquiry. Record each point of hesitation as a potential finding, then check whether the cause is unclear content, navigation or an unfamiliar but valid interaction.

Content and messaging

Check whether the content answers the questions a potential customer needs before acting. The opening section should explain what the business provides and who it serves. Service pages should clarify scope, process, relevant limitations and what the customer should do next.

Remove generic statements that could belong to any competitor. Replace them with verifiable specifics such as the actual working process, service coverage, appropriate credentials, real examples and clearly explained terms. Do not invent proof or outcomes simply to make the website sound stronger.

Record:

• Vague or interchangeable claims
• Missing service information
• Unexplained terminology
• Unsupported claims
• Outdated information
• Missing calls to action
• Questions customers repeatedly ask that the website does not answer

Next action: take the five questions you answer most often by phone or message. If the site does not answer them, that is your content backlog, in priority order.

Conversion and trust

This area asks whether a visitor who is already interested has enough confidence, and enough of a path, to act.

Conversion is not only the button. It is whether the form asks for what you actually need, whether the visitor is told what happens next, and whether there is an alternative route for people who will not use a form. Trust is whether the claims on the page are supported by something a stranger can verify — real work, named references, relevant credentials, clear terms.

How to check it: submit your own enquiry form and read what arrives. Is it enough to respond properly, or would you have to ask more questions first? Then read the page as someone who has never heard of the business: what here would persuade a sceptical person?

Record:

• Forms that collect too little to act on
• Absence of a second contact route
• No explanation of what happens after contact
• Claims with no supporting evidence
• Missing or unclear pricing expectations
• Stock imagery used in place of real work

Next action: if the form fails to collect essential information or submissions are not reaching the business, correct that before lower-priority presentation issues. If the form already works properly, act on the highest-evidence finding instead.

SEO and discoverability

The question here is narrow: can the right people find this site, and does each page make its subject obvious to both readers and search engines?

Check that every important page has its own title and description rather than the business name repeated across all of them. Check that headings describe content rather than being used for visual size. Check that images carry appropriate alternative text, with empty alt attributes for decorative images. Confirm the site is actually indexed using Google Search Console.

Record:

• Pages sharing a duplicated title or description
• Headings used decoratively rather than structurally
• Images with missing or unhelpful alternative text
• Pages you expect to be indexed that are not
• Content that does not use the terms customers actually use

Next action: verify the site in Search Console if you have not already. Search Console provides direct evidence about Google indexing and reported search performance. Page titles, headings, content and internal links can still be reviewed without it, but indexing conclusions should not be based only on a manual search.

A caution worth stating plainly: no audit, including this one, can promise a ranking outcome. What it can do is remove the obstacles that stop a page being understood or indexed at all.

Performance and mobile

Performance has a defined, published standard, which makes this one of the few areas where you can measure yourself against stated thresholds rather than opinion.

Core Web Vitals measure loading, responsiveness and visual stability, and Google Search Central publishes the targets: Largest Contentful Paint within the first 2.5 seconds of the page starting to load, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift below 0.1. Google states that it highly recommends site owners achieve good Core Web Vitals both for success in Search and for general user experience.

To assess whether a page group meets the recommended targets for most users, web.dev advises evaluating the 75th percentile of page loads, segmented between mobile and desktop. Lab tests and field data answer different questions, so one simulated PageSpeed test should not be treated as the complete result.

Separately from the numbers, check the practical experience: open the site on a normal mobile connection and judge whether the main content becomes usable without a prolonged blank screen. That is an observation, not a measurement, and network conditions vary — treat one slow load as a prompt to investigate rather than as proof.

Record:

• Core Web Vitals status per page group, from Search Console
• Individual images far larger than the space they are displayed in
• Pages that shift visibly while loading
• Anything that blocks reading or tapping on a phone

Next action: look at the largest image on your slowest page. Oversized images are a frequent performance candidate and are often straightforward to investigate, but they are not automatically the cause of a slow page.

Accessibility and compliance

Accessibility is about whether people can use the site at all — including people using a keyboard, a screen reader, magnification or high contrast.

The recognised standard is the Web Content Accessibility Guidelines, published by the W3C Web Accessibility Initiative. WCAG 2.2 contains 13 guidelines organised under four principles — perceivable, operable, understandable and robust — with testable success criteria at three levels. WCAG defines conformance levels A, AA and AAA. Which level is required or appropriate depends on the applicable policy, contract, standard or legal context.

Several checks need no expertise. Navigate the site using only the Tab key and confirm you can reach and operate every control, with a visible focus indicator. Check that text has sufficient contrast against its background. Confirm informative images have appropriate alternative text and decorative images use an empty alt attribute so assistive technology can ignore them. Confirm that no information is conveyed by colour alone.

Record:

• Controls that cannot be reached or operated by keyboard
• Missing or invisible focus indicators
• Low-contrast text
• Images without alternative text
• Meaning carried only by colour
• Form fields without associated labels

Next action: run the keyboard test. It is a quick initial check that can reveal keyboard-access problems, but it is not a complete accessibility evaluation.

Be careful with the language here. Passing these checks does not make a site compliant with any law, and this article is not legal advice. Where accessibility carries a legal obligation for you, that needs qualified advice rather than a self-assessment.

How to prioritise and manage the findings

Scoring what you find

Now separate what matters from what you merely noticed. Four levels are enough.

Two rules make this work.

A visual preference is not automatically an audit finding. “I don’t like the green” is a preference. “The button does not look like a button, and two people I asked missed it” is a finding. The test is whether you can state the consequence for a visitor. If you cannot, record it separately as a wish-list item and keep it out of the audit.

Severity is about consequence, not effort. A five-minute fix can be critical; a week of work can be low priority. Judging by effort is how important things end up postponed indefinitely.

Turning findings into an action plan

A finding becomes work when it acquires four things: a specific action, an owner, a date, and a way to tell when it is done.

Rewrite each finding as an instruction rather than an observation. “Homepage is confusing” is not actionable. “Replace the homepage headline so it names the service and the customer, and reduce the page to one primary button” is.

Then group them. An audit may produce clusters — several findings that are really one underlying problem wearing different clothes. Fixing the cluster once is cheaper than fixing six symptoms separately.

Order the work by priority, not by which page you happened to look at first. Address critical failures first. Schedule the remaining work according to consequence, dependencies, available resources and the risk of delay. Record lower-priority items so they are not confused with unresolved critical work.

Assigning owners and dates

An action without a named owner is easier to overlook or leave unresolved.

Owners are not always you. Some items belong to whoever writes the content, some to whoever manages the site, some to a developer. Where a task needs someone you have not appointed, that is itself a finding — record it as a gap rather than an action.

Give each item a date rather than a priority label alone. A date forces a decision about sequence; a label lets everything remain “high” forever.

Record what “done” means for each item, in one line. Without it, work drifts — particularly content work, which can be revised indefinitely.

Re-checking the website

An audit is a snapshot. Repeating the review can add value by showing what changed, what remained unresolved and whether completed fixes continued working.

Choose a review cadence that reflects how frequently the website changes. An actively developed or frequently updated site may need more regular checks than a stable informational site.

Do not start a fresh document each time. Reopen the same one, mark what was completed, and re-run only the checks connected to what changed. A finding that reappears after being fixed is telling you something about the process, not just the page.

Two things make the second audit more useful than the first: you have a previous state to compare against, and you can see which fixes held.

When a simple correction is enough

Much of what an audit turns up is genuinely straightforward: rewriting a headline, adding alt text, compressing an image, adding a missing description, fixing a form field. If a change is isolated, reversible and within your competence, it may be suitable to handle internally after taking an appropriate backup. Changes involving payments, personal data, security, accessibility architecture or unfamiliar code may require specialist review even when they appear small.

Bring in professional help when the audit points at something structural rather than cosmetic:

• Enquiries or orders are being lost and you cannot determine where
• Pages are not indexed and Search Console does not explain why
• Performance is poor across the whole site rather than on one page
• Accessibility problems are built into the theme or template
• The same problem returns after being fixed
• The finding concerns workflow — what happens after contact — rather than the page

If findings repeatedly concern follow-ups, quotations, documents or record-keeping, investigate the workflow as well as the visible website. A visual redesign alone is unlikely to resolve a process that remains manual or unclear.

Where to go next

Many of the checks above can be completed manually or with free tools. The time required depends on the number of pages, the site’s complexity and what the review uncovers. A basic manual review does not automatically weight findings, calculate category scores or maintain a linked action plan; those steps must be created and managed separately.

That is the difference with the Website Audit & Action Dashboard: a 60-check version of this review with impact weighting, category scoring and an action plan that links each task back to the finding it came from. The checks are the same kind; the workbook applies a consistent documented scoring method and maintains a linked action plan. Other checklists and tools are on the Resources page.

If the audit pointed at your workflow rather than your website — enquiries, quotations, documents, follow-ups — that is a different conversation, and it starts with how the business runs today rather than with pages.

Sources: Core Web Vitals thresholds and recommendation, Google Search Central; 75th-percentile guidance and the distinction between lab and field measurement, web.dev; WCAG 2.2 structure and conformance levels, W3C Web Accessibility Initiative.