WhatsApp chatbot vs human agents: who should answer what

The chatbot-versus-human question is usually asked the wrong way round. It is not a choice between two support models; it is a routing decision inside one. Questions with a single correct answer that never changes go to the bot. Everything else goes to a person — with the conversation attached, so nobody starts again. This post is how to draw that line for a WhatsApp inbox, and what it costs to get it wrong in each direction.

The economics: answering is free, so automate for speed, not cost

On the WhatsApp Business API, replies inside the 24-hour customer service window are free-form messages, and Meta does not charge for them. That is true whether the reply comes from a bot or a person. So unlike email or voice, automating WhatsApp support does not cut a per-message bill — the Meta cost of answering is already zero.

What automation buys instead is time: the answer at 11 pm, the answer in four seconds instead of four hours, the answer during a festival-sale spike when the queue is ten times its usual depth. If your reason for wanting a bot is “messages cost too much”, re-read how per-message pricing actually works — your money goes on broadcasts, not replies. If your reason is “customers wait too long”, automation is the right tool.

What belongs to the bot

The good candidates share one property: the correct answer is the same every time.

• “Where is my order?” — one correct answer, held in your order system.
• “What is your returns policy?” — one correct answer, held in a document.
• “Do you deliver to this PIN code?” — one correct answer, held in a list.
• “What sizes does this come in?” — one correct answer, held in your catalogue.

These are lookups wearing the costume of conversations. An AI agent trained on your own material — your knowledge base, catalogue and order data, not general knowledge — settles them in seconds, at any hour, in the customer’s own thread.

What belongs to a person

The other half shares a different property: the right answer depends on judgement, or on how the customer feels.

• A complaint about a damaged parcel, where the answer might be a refund, a replacement or an apology, depending on the history.
• A bulk-order negotiation.
• Anyone who is already annoyed. A customer who has explained a problem three times to something that cannot help is worse off than one who waited in a queue.

The failure mode of support automation is not the bot answering badly — it is the bot refusing to give up. Set the handoff threshold generously. Erring towards passing things to a person costs a little efficiency and buys a lot of goodwill.

The handoff is the actual product

Most chatbot damage happens at the boundary, so the boundary is what to evaluate when you choose tooling. Three things make a handoff work:

1. The thread travels. The human agent sees the whole conversation — what was asked, what the bot already said — in the shared inbox. The customer never repeats themselves.
2. The handoff is measured. In Baat, every bot shows its handoff rate — the share of conversations that needed a person. A rising rate means the bot’s source material has gaps; a near-zero rate on a generous threshold means the routine half really is covered.
3. The bot can be scoped. It does not have to handle everything or nothing — you can restrict it to out-of-hours cover, to particular question types, or to a first response before a human takes over.

Keep the source material current

An AI agent is only as good as what it reads. The knowledge base it answers from is the actual product here, and it needs the same maintenance as any customer-facing page. When the returns policy changes, the bot’s copy of it must change the same day — otherwise you have automated the giving of wrong answers.

This is also the honest reply to “will the AI make things up?”: a grounded agent answers from your material and hands off when unsure, so the risk is not invention but staleness. Staleness is fixable with a process; invention would not be.

A practical starting split

If you are setting this up for the first time:

1. Pull your last hundred conversations and sort them into “same answer every time” and “needed judgement”. The first pile is the bot’s job description.
2. Write or tidy the knowledge base articles that answer the first pile — Baat’s AI agents answer from linked KB collections, so this step is the setup.
3. Launch with a generous handoff threshold and test before activating.
4. Watch the handoff rate for a fortnight. Add material where it hands off on questions that do have a fixed answer; leave it alone where the handoff was right.

The goal is not a bot that handles everything. It is a queue where every routine question is already answered by the time your team sits down, and every hard one reaches them with context. If you want to see the split running against your own question mix, book a demo.