# Can a chatbot really replace live agents? Mostly no

> By Lawrence Dauchy, Founder, DFYe. Published 2026-09-15. 10 min read. Comparisons.
> Source: https://dfye.com/blog/can-a-chatbot-really-replace-live-agents/
> Language: en

The useful question is not whether it replaces your team. It is which half of the queue it can take, and what breaks if you let it try to take the other half.

**TL;DR.** No, not fully, and the products claiming otherwise are selling the easy half as the whole job. A chatbot can take questions that repeat and whose answers are already published: delivery windows, returns policy, stock, order status if it can reach your store. It cannot take judgement, negotiation, or an angry customer. Human live chat sits at 100,000 WordPress installs, which is the market telling you the same thing.

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](https://wordpress.org/plugins/tawkto-live-chat/),
which is human live chat, sits at **100,000 WordPress installs** measured against the
[plugin API](https://api.wordpress.org/plugins/info/1.2/) 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 type | What answering it needs | Can a bot take it |
|---|---|---|
| Do you ship to Norway | A published shipping policy | Yes, if the page exists |
| Where is my order | A live lookup in your store | Yes, with an integration |
| Does this fit a 12-year-old | Judgement about a specific child | No |
| This arrived broken and I am furious | Apology, authority, a decision | No |

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 says | What it might actually mean | How to check |
|---|---|---|
| Deflected | The answer was good and they left satisfied | Repeat contacts from that person within 24 hours |
| Deflected | They gave up and went to a competitor | Session recordings, or the exit page |
| Escalated | The bot failed | Often the bot working correctly |
| Resolved | The ticket was closed | Whether 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](https://www.w3.org/WAI/standards-guidelines/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](https://gdpr-info.eu/art-22-gdpr/) 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](/how-it-works/), the side-by-side against the alternatives is on
[the comparison pages](/compare/), 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](/blog/ai-chatbot-website/) or
[how to choose one](/blog/best-ai-chatbot-website/).

## Quick answers

### 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.

## Sources

- [WordPress.org plugin API, the install figures](https://api.wordpress.org/plugins/info/1.2/)
- [Tawk.to on the WordPress.org plugin directory](https://wordpress.org/plugins/tawkto-live-chat/)
- [Chatway on the WordPress.org plugin directory](https://wordpress.org/plugins/chatway-live-chat/)
- [GDPR Article 22, automated individual decision-making](https://gdpr-info.eu/art-22-gdpr/)
- [W3C: WCAG, the accessibility standard a support channel has to meet](https://www.w3.org/WAI/standards-guidelines/wcag/)

---
*Published by [DFYe](https://dfye.com/). Free to read, index, quote and cite with attribution and a link.*