Should you put an AI chatbot on your business website? An honest UK guide

For most UK small businesses the honest answer is “not yet, and possibly not at all”. An AI chatbot for business website enquiries pays for itself when you get a steady stream of repetitive questions, your answers are already written down somewhere accurate, and a wrong answer would be an annoyance and not a liability. Our rule of thumb: if you take fewer than about fifty enquiries a month, or your answers depend on judgement, a clearer contact page and a better FAQ will do more for less.

We build integrations like these, so this is not a warning against the technology. It is a description of where it fits, what it costs to run, and what has to be in place before a language model talks to your customers under your name.

What a website AI assistant does, and how it differs from the old chatbots

The chat widgets of a few years ago followed scripts. You clicked “Opening hours” or “Track my order” and moved down a decision tree someone had drawn. They never said anything unexpected, and they were useless for anything off the tree.

The current generation puts a large language model behind the chat box. In a sensible set-up the model does not answer from its general training. Your pages, policies, price lists and help articles are indexed, the passages most relevant to each question are retrieved, and the model is instructed to answer from those passages only. Developers call this retrieval-augmented generation. The practical point for an owner is that the assistant can only be as good as the content you give it. If your delivery policy is vague on the website, it will be vague in the chat, or worse, the model will fill the gap with something plausible.

What they do well and what they do badly

The right-hand column matters more than the left. A chatbot that answers eighty questions well and invents the answer to the eighty-first is worse than no chatbot, because the customer cannot tell which answer was invented.

Choosing an AI chatbot for business website enquiries: four build options

Our advice for a first attempt is the second row. Use an off-the-shelf widget for two or three months, read every transcript, and find out what people really ask. Half the value of the exercise is that list of questions. If the widget copes, keep it. If the questions keep needing data it cannot see (“where is my order?”, “is my boiler model covered?”), that is the evidence for a custom build.

What “custom” means in practice

A custom assistant is less exotic than it sounds. It is a small web application with four parts: an index of your approved content, a connection to a model provider’s API, a set of tools the model is allowed to call (look up an order, check a diary slot, create a lead in the CRM), and a chat interface on the site. The work is in the plumbing and the testing, not the AI. It usually sits on top of an existing integration, which is why it pairs naturally with API development and integration and with a CRM you control. Our comparison of custom and off-the-shelf CRMs covers that side.

Realistic running costs

Vendor pricing in this market changes every few months, so treat every figure here as a range to check, not a quote.

• Subscription widgets are the predictable option: a flat monthly fee with a cap on conversations or on the pages they can index.
• Per-resolution pricing looks cheap until volume grows. At 400 resolved conversations a month and, say, 80p each, you are paying £320 a month.
• Model usage on a custom build is billed by the amount of text processed. For a typical support exchange it works out somewhere between a fraction of a penny and a few pence per conversation, depending on the model chosen and how much content is retrieved for each answer. A thousand conversations a month is normally a matter of pounds or low tens of pounds.
• The cost people forget is their own time. Someone has to read transcripts, correct source content and re-test after changes. Allow an hour or two a week at the start.

A worked example for a custom build

Take an illustrative Leeds lettings agency that wants an assistant able to answer questions from its landlord and tenant guides and check the status of a maintenance request in its existing system. We charge custom web development at £60 an hour through hourly hire.

40 hours × £60 = £2,400. A booking of this size earns our 15 % volume discount (the tier that starts at 20 hours), so £2,400 − £360 = £2,040. Add VAT at 20 % (£408) and the build comes to £2,448. Running costs afterwards would be model usage, a small amount of hosting and an hour or two of maintenance a month. A simpler assistant with no system lookup is nearer 20 hours; one that takes payments or changes bookings is considerably more, because every action it can take has to be tested for misuse.

UK GDPR and data protection

A chat box is a free-text field. People type names, addresses, order numbers, health details and complaints about named members of staff into it, and with an AI assistant that text is sent to at least one other company. What follows is our working checklist, not legal advice. For anything sensitive, speak to whoever advises you on data protection.

• Know where the text goes. Usually to the widget vendor and on to a model provider, often in the United States. You remain the controller. The vendor is your processor and the model provider is usually its sub-processor, so you need a data processing agreement with the vendor that names its sub-processors, and a lawful route for the international transfer, such as the UK-US data bridge for certified companies or the ICO’s International Data Transfer Agreement.
• Check the training setting. Business and API terms from the main model providers generally say customer data is not used to train models by default. Confirm it in the contract for the plan you are on, and check how long conversations are retained.
• Tell people. Say plainly in the chat window that they are talking to an automated assistant, name the provider category in your privacy notice, and say how long transcripts are kept. UK GDPR’s transparency principle requires it, and customers expect it.
• Minimise. Ask for the least you need, tell people not to enter card numbers or medical details, and set a retention period. In our view ninety days of transcripts is plenty for most small businesses.
• Do a DPIA. UK GDPR requires a data protection impact assessment where processing is likely to be high risk, and the ICO’s AI guidance says most uses of AI will meet that test. For a simple FAQ assistant it can be short: what data, why, who receives it, what could go wrong, what you have done about it. If the bot will handle health, financial hardship or children’s data, do it in full. If you conclude one is not needed, write down why.
• Keep decisions with people. Since February 2026 UK GDPR, as amended by the Data (Use and Access) Act 2025, allows decisions with legal or similarly significant effects to be made solely by automated means only with safeguards: you must tell the person, let them make representations, and give them a human review. Tighter limits apply where special category data such as health is involved. The safe design has not changed: the assistant can inform and collect details, and a person approves refunds, refusals and anything else that matters.
• Mind the cookies. Many widgets set cookies or use local storage on every page as soon as they load. Under PECR that needs consent unless it is strictly necessary for something the visitor has asked for. Loading the widget only when someone clicks the chat button is the tidy solution, and our guide to UK cookie banners explains the rule.

If you sell to customers in the EU, the EU AI Act has since 2 August 2026 required chatbots to be built so that people are told they are interacting with an AI system, unless that is obvious. The duty falls on the provider of the system, so check that your vendor or developer meets it if EU sales are material.

Accuracy risks and the guardrails that reduce them

Language models produce fluent text whether or not it is true. Two widely reported cases show the range. In February 2024 British Columbia’s Civil Resolution Tribunal, a Canadian small-claims body, held Air Canada liable for negligent misrepresentation after its website chatbot wrongly told a customer he could claim a bereavement fare refund after travelling. It rejected the airline’s argument that the chatbot was a separate legal entity responsible for its own actions. The same year a UK parcel company switched off part of its chatbot after a customer coaxed it into swearing and criticising the firm. Neither is a UK court ruling, but we would assume that a business here is answerable for what its website says, whoever or whatever wrote the words.

The guardrails we build in, roughly in order of importance:

1. Answer only from approved content. If nothing relevant is retrieved, the assistant says it does not know and offers a person.
2. A visible route to a human in every conversation: a handover to live chat in office hours, a callback form outside them.
3. No improvised prices, dates or promises. Figures come from structured data or a system lookup, never from the model’s own wording.
4. Show the source. Each answer links to the page it came from, so the customer can check and you can see which page needs rewriting.
5. Refuse out-of-scope topics. Legal, medical and financial questions get a polite decline and a contact route.
6. Assume people will try to break it. Visitors will paste in instructions telling the bot to ignore its rules. Limit what it can do, rate-limit it, and never give it access to data the person in the chat should not see.
7. A fixed test set. Fifty to a hundred real questions with known good answers, re-run after every change to the content, the prompt or the model.
8. Log and review. Read transcripts weekly for the first two months, then sample monthly.
9. An off switch. One setting that replaces the assistant with a contact form.

This matches the rule we set out in our comparison of AI website builders and web agencies: we do not publish AI output that a person has not reviewed. A live assistant cannot be reviewed line by line, so the review moves to the source content, the test set and the transcripts.

Two things that get overlooked

The widget itself has to be usable. It must work with a keyboard and a screen reader, must not cover the cookie banner or the checkout button on a phone, and must not trap focus. Our guide to website accessibility and UK law sets out the standard. It also should not slow the site. A chat script loaded on every page can add a good deal of JavaScript and harm your Core Web Vitals, so load it after the page is interactive or on click.

How to measure whether it pays

Decide what you will measure before launch and record the “before” figures for a month: enquiry volume by channel, time spent answering, and how many enquiries turn into work.

A quick payback sum, using made-up but plausible numbers: the assistant handles 150 questions a month that would each have taken four minutes of someone’s time. That is 10 hours. At a staff cost of £15 an hour it saves £150 a month, against perhaps £80 for the widget and, once it has settled down, two hours of review a month (£30). The margin is thin. The case gets stronger if out-of-hours conversations turn into bookings you would otherwise have lost, and weaker if the questions could have been removed by putting the answer on the page people were already reading.

That last point deserves a moment. If a third of chats ask about delivery times, the fix is delivery times on the product page.

Who should and should not add one

• Under about fifty enquiries a month: skip it. Put effort into the FAQ, the contact form and a fast reply by email.
• A shop or service with the same ten questions every day and good written policies: trial an off-the-shelf widget for a quarter.
• Account-specific questions (orders, bookings, repairs) at volume: a custom assistant connected to your systems is worth costing.
• Regulated advice, vulnerable customers or high-value bespoke quotes: use the assistant for triage and information only, with a person on every decision, or do not use one.
• Nobody available to read transcripts: wait until there is.

A sensible way to start

1. Export three months of enquiries from email, forms and phone notes, and group them by question.
2. Rewrite the pages that should have answered the top ten. Measure again after a month.
3. If the volume is still there, trial a hosted widget on a few pages, loaded on click, with the privacy notice updated.
4. Review every transcript for eight weeks and keep a list of failures.
5. Decide with numbers: keep, cancel, or brief a custom build.

We are based in London and build integrations and assistants for businesses across the UK through our custom software development service. If you want a second opinion on whether a chatbot would earn its place on your site, describe your enquiry volumes in the project planner and we will give you a straight answer, including “you do not need one”.

Photo: NordWood Themes via Unsplash