No, a chatbot cannot really replace live agents, and the products implying otherwise are selling the easy half of the job as the whole of it. What it can take is the set of questions that repeat and whose answers are already published on your site. In a typical shop that is most of the volume and almost none of the difficulty. The market says the same thing plainly: Tawk.to, which is human live chat, sits at 100,000 WordPress installs measured against the plugin API on 8 September 2026, and people are still installing it.

So the useful question is not replacement. It is which half of the queue moves, and what breaks if you push the other half through as well.

What can a chatbot actually take?

Questions whose answer is a fact you have already written down, and questions whose answer is a lookup it can perform. That is the whole set.

Question typeWhat answering it needsCan a bot take it
Do you ship to NorwayA published shipping policyYes, if the page exists
Where is my orderA live lookup in your storeYes, with an integration
Does this fit a 12-year-oldJudgement about a specific childNo
This arrived broken and I am furiousApology, authority, a decisionNo

The first two rows are the ones worth automating and they are usually the bulk of the queue. The second two are why you still need people, and notice that neither of them is hard because of the technology. They are hard because they require somebody to decide something and to mean it.

Row one carries a condition that gets skipped: if the page exists. A retrieval system reads what you published. If your delivery policy lives in a person’s head or in an email footer, there is nothing to find, and no amount of model quality fixes that. Writing the page is the work, and it improves your site whether or not you automate anything.

What does it always hand back?

Anything requiring judgement, anything requiring authority, and anything where the customer’s actual need is to be heard.

Judgement is the obvious one. “Will this jacket be warm enough for Scotland in November” is not a retrieval problem; it is a person weighing an unstated set of conditions. A retrieval system can tell you the fill weight. It cannot tell you whether that is enough for this trip, and the confident-sounding ones that try are doing the thing that gives the category its reputation.

Authority is the one people underestimate. Exceptions, goodwill gestures and one-off decisions are the moments that make a customer stay, and they require somebody empowered to break the policy. A bot that could break the policy would not be a bot; it would be an unsupervised employee.

And some contacts are not questions at all. Somebody writing to say a birthday present arrived smashed wants a person to acknowledge it. Answering that with a correct summary of the returns procedure is technically accurate and reads as contempt.

Does deflection rate mean anything?

Less than it is used for, because of how it is counted. A conversation is usually marked deflected when the visitor stops talking, and people stop talking for two opposite reasons.

What the number saysWhat it might actually meanHow to check
DeflectedThe answer was good and they left satisfiedRepeat contacts from that person within 24 hours
DeflectedThey gave up and went to a competitorSession recordings, or the exit page
EscalatedThe bot failedOften the bot working correctly
ResolvedThe ticket was closedWhether the same question came back next week

Pair any deflection figure with a second number that measures the outcome rather than the ending. Repeat contacts within a day is the cheapest one to get and the hardest to argue with. A high deflection rate alongside a high repeat rate is not automation working; it is a queue being moved from one place to another.

The escalation row deserves defending. An escalation is not a failure. A bot that recognises the limit of what it can support and hands over cleanly is doing the most valuable thing in the product, and teams that treat escalation as a metric to minimise end up tuning their bot to be more confident rather than more correct.

What breaks when you remove the humans?

Three things, in a fairly predictable order.

First, exceptions stop happening. Nobody notices immediately, because exceptions are invisible in aggregate; they show up months later as a slow decline in the customers who used to come back. The person who would have been given a replacement without quibbling now gets the policy quoted at them.

Second, you stop hearing the thing customers keep saying. A support queue is your best source of product feedback, and a team reading it develops an instinct that no dashboard reproduces. Automate the reading and the instinct goes with it, unless somebody is deliberately reviewing transcripts. The cheapest defence is a standing half hour a week in which one person reads twenty conversations chosen at random, not the escalated ones. The escalated ones are already visible; the random sample is where you find the answers that were confidently wrong and nobody challenged.

Third, accessibility narrows. If chat becomes the only route in, everybody who cannot use it comfortably is now further from you, and a support channel has the same obligations as the rest of your site under WCAG. Removing an email address because the bot covers most cases is a decision with a cost that does not appear in the deflection number.

There is a legal edge to this as well. Letting a bot make a decision about a person rather than look one up, an automatic refusal or an automatic cancellation, moves you toward Article 22 territory, where solely automated decisions with significant effects carry extra obligations. The practical version: let the bot prepare the case, let a person press the button.

How should the handoff actually work?

This is the part that decides whether customers tolerate the arrangement, and it gets about a tenth of the attention that model quality gets.

Three designs are common. Bot only, with a contact form behind it, which is cheapest and the one people complain about. Bot first with a visible route to a person, which is what most shops should run. And human first with a bot covering the hours nobody works, which suits teams whose questions genuinely need judgement but who do not want to lose the overnight visitor.

Whichever you pick, three details do the work.

The conversation travels with the handoff. A customer who has explained their problem to a bot and is then asked to explain it again to a person has had the worst experience this category offers, and it is entirely avoidable. The transcript should arrive with the ticket, and the person should be able to see what the bot tried.

The route to a person is visible from the first message. Not after three failed attempts, not hidden in a menu. Burying it raises your deflection number and lowers the thing the number is a proxy for, which is people getting what they came for. Somebody who can see the exit usually does not take it.

Out of hours, say so. A bot that promises somebody will be right with you at two in the morning, when nobody starts until nine, has spent your credibility on a sentence nobody needed. Saying that the office opens at nine, and here is what I can tell you now, costs nothing and is believed.

The last detail is unglamorous and decides more than the rest: somebody has to be watching the queue the handoff lands in. A handoff into an inbox nobody reads is worse than no handoff, because the customer was told help was coming.

When should you keep live agents instead?

Whenever the answer to a question is worth more than the cost of writing it, which is more often than the pitch decks suggest.

If your order values are high and your volume is low, automation is solving the wrong problem. Twenty considered questions a week from people about to spend four figures is not a queue to deflect; it is the most valuable conversation your business has, and a person should be having it.

If your product genuinely requires advice, the same applies with more force. Sizing, fit, compatibility and suitability are judgement calls, and a shop that competes on knowing its catalogue should not automate away the part customers are actually paying for.

And if you sell into a regulated space, keep the human in the loop for anything with a consequence. Not because the model cannot phrase the answer, but because somebody has to be accountable for it and a vendor’s terms will not accept that on your behalf.

Set against those, the ordinary case holds up well. A shop whose delivery, returns and sizing information is already written down, fielding the same four questions at two in the morning, is not replacing a team. It is stopping somebody rewriting the same paragraph for the hundredth time. How that mechanism works is on how it works, the side-by-side against the alternatives is on the comparison pages, and if you are still working out which kind of product you are looking at, start with what an AI chatbot for a website actually is or how to choose one.

Answers to the usual questions

Can a chatbot really replace live agents?

Not fully, and anybody selling that is selling the easy half as the whole job. A chatbot takes questions that repeat and whose answers are already published somewhere on your site, which is usually most of the volume and almost none of the difficulty. Judgement, negotiation, apology and anything involving an exception still need a person. The realistic goal is a smaller queue, not no queue.

What percentage of support questions can a chatbot handle?

Nobody can give you an honest number for your shop, and a vendor quoting one is quoting their best customer. It depends entirely on how much of your policy is written down and reachable. A shop with clear delivery, returns and sizing pages will see a large share answered; a shop where that knowledge lives in one person’s head will see almost none, because retrieval can only find what exists.

Will customers be annoyed by a chatbot?

They are annoyed by three specific things, and all three are choices you make rather than properties of the technology: a window that opens by itself and covers the page, a bot with no visible way to reach a person, and confident answers that turn out to be wrong. Fix those and most of the complaint disappears. The people who hate chatbots mostly hate badly configured ones.

Is deflection rate a good measure?

On its own it is one of the more misleading numbers in support software, because a conversation counts as deflected when the visitor stops talking, and people stop talking for two opposite reasons. Pair it with something that measures the outcome: repeat contacts from the same person within a day, or the share of conversations that reached a human after the bot tried and failed.

What should a chatbot do when it cannot answer?

Say so and hand the question over, with the conversation attached so the person does not start from nothing. That is the single most important behaviour in the product and the one most worth testing before you buy. A bot that answers everything is not more capable than one that declines, it is less honest, and the cost of that lands on your customer rather than on the vendor.

Can a chatbot handle refunds and cancellations?

It can look them up and explain the policy. Letting it execute them is a different decision, and a more serious one: a refund is an action with a financial consequence and, in Europe, a decision about a person that may attract extra obligations if it is fully automated. Most teams are better served by a bot that prepares the case and a person who presses the button.