AI customer service: designing the handover, not the chatbot
Most companies building an AI support agent solve the wrong problem. Which questions automate, when the bot must hand over, and how to measure the return.
Most AI customer service projects stall in the same place: they start as “let’s build a chatbot” and end as “let’s switch the bot off.”
The cause isn’t the technology. It’s starting from the wrong question — “Can AI talk to our customers?” The right question is: “What share of incoming requests can be closed correctly without a human ever looking at them?”
The first question produces a demo. The second produces a measurable saving.
Sort the requests first
There is exactly one thing to do before you start: open the last three months of inbound messages and classify them by intent. The distribution usually looks like this:
- 40-60% repeat information questions. “Where is my order,” “what are your hours,” “price list,” “can I move my appointment.” The answer is written down somewhere; it just needs finding.
- 20-30% transactional requests. Booking, cancelling, changing an address, starting a return. These need a record written in a system, not an answer.
- 10-20% genuine exceptions. Complaints, negotiations, edge cases, angry customers. These need a human and will continue to.
The first group is what automation is actually for, and in most companies it is half the volume. Trying to automate the third group is the decision that sinks the project.
The architecture that works
1. A knowledge base, not the model’s memory.
Don’t expect the model to “know” things. Put your prices, policies and procedures in one source, have the system retrieve the answer from it, and have it cite what it used. This is retrieval-augmented generation, and it matters for one reason: when the price list changes you update a document, you don’t retrain a model.
A system that answers without a source will, sooner or later, promise a customer a campaign that doesn’t exist. That isn’t a theoretical risk; it’s a routine incident.
2. Handover as the main path, not the failure path.
The critical design decision is when the bot withdraws. Three rules are enough —
- If the customer asks the same thing twice, hand over.
- If nothing matched in the knowledge base, don’t improvise; hand over.
- If the customer asks for a human, don’t argue; hand over.
And the whole conversation has to travel with the handover. A system that makes the customer repeat everything they just typed is worse than having no system.
3. Narrow write access.
Read broadly, write narrowly. Let it create appointments but not cancel them; start a return but not approve a refund. Every irreversible action goes through a human — at least for the first few months.
WhatsApp: the channel that matters in many markets
In Türkiye and much of the region, customers don’t email. They message on WhatsApp. That changes the setup in two ways.
The good part: low friction, high response rates, and the customer is already inside the app.
The hard part: you have to work through the WhatsApp Business API. Wiring a bot into the ordinary phone app breaks the terms and ends with the number banned. On the API side there is a 24-hour rule: you can reply freely within 24 hours of the customer’s message, and after that only with pre-approved template messages. Flows like appointment reminders have to be designed around that rule.
We covered the sales side of this channel for clinics in WhatsApp for clinics.
How to measure the return
“Customer satisfaction improved” is not a measurement. Before you build anything, record these four numbers:
| Metric | Why |
|---|---|
| Monthly inbound requests | The denominator everything else is measured against |
| Average first response time | The line automation improves fastest |
| Human minutes per request | Where the actual saving shows up |
| Share closed without handover | The real success metric for automation |
The fourth is the key one. The target is not 100% — a healthy deployment settles into a 35-55% containment rate in its first quarter. Pushing above that means dumping the third-group exceptions onto the bot, and satisfaction falls.
Be honest on the cost side too: model usage, WhatsApp conversation fees, and maintenance. Knowledge base upkeep is real work — deployments that don’t budget a few hours a month start giving wrong answers within six months.
Where to start
With one flow. Pick the single most repeated question type, automate only that, measure for two weeks. If it holds, expand.
Projects that begin with “let’s move all of customer service to AI” share one fate: three months in, nothing works end to end. We set out the general framing in where to start with AI automation.
If you want to map your own request distribution and see which flow is worth automating, our AI and automation service starts with exactly that measurement.
