My mate Dan runs a two-person bike repair shop in Leeds. Last spring he dropped a chat widget onto his site that answers questions about turnaround times, brake pad prices and whether he stocks 700c tyres. It handles around 40 conversations a week and has booked roughly 60 repair jobs he would otherwise have missed. He didn’t hire anyone. He spent a Saturday afternoon on it.
That is the honest short version of what an online AI chatbot does well: it absorbs the repetitive, low-stakes questions and answers them at 11pm on a Sunday. The longer version involves caveats, a couple of genuine risks, and a handful of vendors who will cheerfully charge you £300 a month for something a free tool does better. Here’s what I’ve picked up watching small businesses and mid-sized support teams deploy these things over the last two years.
Scripted bots and AI chatbots aren’t the same species
If your memory of chatbots is a bank website circa 2016 that kept saying “I didn’t understand that, please select an option,” that was a decision tree someone hand-wrote. It broke the second a customer phrased things differently, and someone had to maintain every branch by hand.
Modern online AI chatbots run on large language models. They read intent out of messy human language, keep context across a whole conversation, and generate each reply word by word rather than pulling from a fixed menu. That flexibility is the entire pitch, and it’s also the problem, because a system that can say anything can also confidently say something wrong.
Where they actually pay for themselves
Support deflection is the obvious win. Teams running tightly scoped bots on order status, returns and account questions usually report somewhere between 30% and 50% of inbound chats resolved with no human involved. That number collapses if you point a bot at open-ended complaints, so scope matters more than model choice.
The less obvious applications are often more profitable:
- Order tracking and WISMO traffic (“where is my order”) — the single highest-volume question in most ecommerce inboxes.
- Lead qualification on B2B sites, where a bot asks three questions and books a call only if the budget and timeline fit.
- Internal helpdesk for HR policy, IT resets and expense rules, which quietly saves a few hours per employee per month.
- Onboarding and training, where a bot answers the same twelve questions every new hire asks in week one.
- Appointment booking for clinics, salons and trades, where the value is entirely in after-hours coverage.
If you want to see the order-tracking pattern built end to end, this Voiceflow AI tutorial on building a customer support bot that handles order tracking walks through the logic without assuming you can code.
Three layers sit under every decent bot
The model
This is the reasoning engine. You can run it through an API from OpenAI, Anthropic or Google, or host an open-weight model yourself. Model choice matters less than people think for simple FAQ work, and rather more for anything involving multi-step reasoning or tone.
The retrieval layer
Almost every good deployment pipes your own content into the model at answer time — help centre articles, policy docs, product specs — a pattern called retrieval-augmented generation. Get this wrong and the bot invents plausible nonsense. Chunk your documents sensibly, keep pages short, and test with the sloppy half-sentences real customers type.
The guardrails
Rules about what the bot must never do: quote prices that aren’t in the source material, promise refunds, discuss competitors, or guess. Guardrails also cover escalation, the handoff to a human that should trigger on frustration, legal keywords, or two failed attempts in a row. Teams that skip escalation design end up with a bot that traps angry customers in a loop, which is worse than having no bot at all.
The current direction of travel is toward agents that don’t just answer but act — issuing refunds, updating records, chasing couriers. Meta’s push into AI agents with Muse is one signal of where the big platforms think this goes, and it’s worth watching before you commit to an architecture.
The costs the pricing page leaves out
Vendors quote per-seat or per-resolution fees. The subscription is rarely the expensive part.
Someone has to keep the knowledge base current, and that person is usually whoever already writes your help docs, which means it’s the task that quietly gets dropped in a busy month. Someone has to review transcripts weekly and add the questions the bot fumbled to a test set. Someone has to own the escalation logic as your product changes. Budget a few hours a week, permanently, or the bot degrades to the point where customers learn to click straight past it.
Picking a platform without getting boxed in
Ask these before you sign anything:
- Can I export the full knowledge base and conversation logs, in a usable format?
- Can I swap the underlying model without rebuilding the whole flow?
- What happens when a model version is deprecated — do I get notice and a migration path?
- Does the transcript show me the retrieved sources behind each answer, so I can debug a bad reply?
- How does handoff to a human work, and does the agent see the full chat history?
- Where is data stored, and is anything used to train models?
That fourth point filters out most of the weak products immediately. If you can’t see why the bot said something, you can’t fix it.
Trust, scams and the privacy question
Not every chatbot you meet is working for the company it claims to represent. Conversational AI has made romance and investment scams considerably more convincing, since a scammer can now hold dozens of plausible, personalised conversations at once. The rise of AI-powered dating app scams is a useful reminder that fluency is not the same as honesty, and that a smooth chat experience tells you nothing about who is on the other end.
On the business side, the privacy questions are duller but heavier. Every conversation is a data asset. Chat logs contain names, order numbers, health complaints, and the occasional password someone typed by mistake. Scrutiny of what gets harvested from ordinary online activity is only tightening — Clearview AI’s testing of a tool that would let police unearth your life online shows how much appetite exists for conversational and scraped data once it accumulates somewhere.
Practical steps: redact card numbers before they hit the model, set a retention window measured in weeks rather than years, and never let a vendor use your transcripts for training by default.
Getting one live this week
Pick a single job. Not “improve support,” but “answer questions about delivery times and returns.” Pull 30 real transcripts from your inbox and highlight the questions that repeat. Write the answers down plainly, in the words your customers use — not marketing copy. Load those into a retrieval-based bot and spend an hour trying to break it with rude, confused and contradictory questions. Whatever it gets wrong, fix the source document rather than adding another instruction to the prompt.
Then put it in front of real traffic with a human watching the transcripts for the first fortnight, and count two things: how often it answers correctly with no help, and how often it escalates when it should. Those two numbers decide whether you scale it up, narrow its scope, or switch it off. Most failures I’ve seen came from skipping that measurement, not from picking the wrong vendor.