Chatbot plus a human agent. How to divide the work and not lose the customer at the handover

The argument about whether you need a bot is usually held in the wrong place. People do not hate bots for being automated. They hate the moment when someone explains a problem four times, gets nothing useful back and cannot reach a human being. Below is the rule for splitting questions, 4 triggers for handing a conversation to a person, a responsibility table and the situations where a bot will never pay for itself.

Key takeaways:

• Give a question to the bot when it has one correct answer that is known in advance

• The button that calls a human belongs in the very first message, and it gets used less often as a result, not more

• A handover only counts as successful when the agent can see the backstory and the customer does not have to repeat themselves

• A night-time bot pays back faster than a daytime one, because at night the alternative is not an agent but silence

• The share of automatically closed conversations grows even with a bad script, which makes it a dangerous metric on its own

• A script written from imagination stalls at recognising 40% of enquiries

The rule for splitting questions between bot and human

There is one rule that works. If a question has a single correct answer known in advance, give it to the bot. If the answer depends on the situation, the mood or the sum of money involved, a human keeps it.

Testing it is simple. Take your last 200 enquiries and sort them by that criterion. Usually 40 to 60% land in the first group, and that is the volume you can lift off your agents.

Responsibility table

We assembled this from reviewing typical enquiry flows in retail and services.

A second rule filters out questions where mistakes are expensive

Even a question with a single answer goes to a human when a wrong answer is costly. Warranty repair timelines, refund conditions, usage recommendations.

Automation is acceptable here as information with a pointer to a specialist, never as the final word.

The bot qualifies, it does not sell

Trying to walk someone through a sales script automatically produces a worse result than a short conversation with a person.

The sensible boundary sits at the moment the customer states a need. From there the conversation goes to a human, and by then the bot has already gathered the context.

The handover point

One working term. The handover point is the moment the bot stops processing and the conversation passes to a person together with everything it has collected. The quality of the whole setup is decided not by the bot script but by how this point is built.

Four triggers that oblige the bot to hand over

The customer asked directly. The bot failed to understand twice in a row. The message carries signs of frustration. The subject involves money or a complaint.

Twice, not three times and not five. Every further failed attempt reduces the chance the customer waits for a human at all.

The button that calls an agent should appear in the very first message. Practice shows the opposite of what companies fear — when the exit is visible, people use it less, because the feeling of being trapped disappears.

The agent inherits the backstory or the setup does not work

This is the line between a working and a broken setup. If the agent opens with “tell me what happened”, all the time saved evaporates and the customer gets angry.

The right arrangement is that the bot conversation is written into the same customer card as everything that follows. The agent opens the card, reads 6 lines and continues from the middle.

That is why connecting the bot to your CRM matters more than which bot you pick. A messenger number connected to the system keeps one continuous thread regardless of who was answering at any given moment.

The reverse handover needs its own rule

The scenario everyone forgets. The agent resolved the issue, the conversation closed, and two days later the customer writes again about something else.

A sensible rule looks like this. If the previous enquiry was a complaint, the next one goes straight to a person. In every other case the bot works as usual.

Expert note

The most persistent implementation mistake is writing the script around how the company imagines its customers’ questions rather than how those questions actually get asked. People write “when is it coming” rather than “please confirm the delivery status of my order”. The only reliable way to build a script that works is to export 300 real conversations and lift the wording from them verbatim, typos, abbreviations and all. Companies that take this step reach over 80% recognised enquiries with the first version. Companies that write the script from imagination stall at 40% and then spend six months patching it from complaints.

Nights, weekends and peak periods

A night-time bot pays back faster than a daytime one

During the day the alternative to the bot is a human agent, and the customer compares automation with a person to the bot’s disadvantage. At night the alternative is silence until morning, and there any sensible answer wins.

Start with the night script. It delivers immediately, does not compete with your agents and does not spoil the experience for demanding customers.

It does not have to answer on the merits. Three functions are enough — accept the enquiry, record it in the CRM, name a specific time for the reply in the morning.

Prepare for peak load a month ahead, not during the season

In season the flow of enquiries multiplies and the bot acts as a buffer. It absorbs the reference questions that stop agents from getting to the people ready to buy.

A script switched on at the height of the season is guaranteed to contain errors nobody has time to fix. Launch it early.

Over holidays the bot replaces the notice on the door

A separate case. A message with the working dates, enquiries accepted into a queue and a clear plan for working through them afterwards.

The customer does not need a dialogue here, they need certainty. One precise message beats a complex script.

The exception for round-the-clock obligations

A night-time autoresponder does not belong where an enquiry may be genuinely urgent — emergency services, medical questions, security, technical support with contractual response times. In those fields a bot is acceptable only as a router to the person on duty, never as a way to defer the answer until morning.

Judging script quality

Four metrics that only work together

The share of enquiries closed without a human. In isolation this number means nothing, read it alongside the next one.

The share of customers who came back with the same question. That is what shows whether the issue was solved or the customer gave up.

Time to handover. Anything above 3 minutes means an overloaded script.

Satisfaction after conversations involving a handover compared with conversations that never touched the bot. A negative gap points at the handover point rather than at the bot itself.

Automation share grows even with a bad script

The number climbs in two very different situations. When the bot genuinely resolves questions, and when customers stop waiting and leave.

You can only tell them apart through repeat enquiries and revenue. If automation share rose while orders fell, you did not automate support, you automated the refusal to talk to you.

Review the script monthly

Read the conversations where the bot failed to understand. Every one of them is either a new phrasing or a new branch.

Over six months a script typically doubles in size while unrecognised enquiries drop to low single-digit percentages. Without review the opposite happens — customers’ language shifts and the bot stays where it was.

When you do not need a bot

Savings on staff never arrive at low volume

The familiar claim is that a bot takes load off support. The counter-argument is that the script has to be written, tested and then edited every month, and that work does not disappear after launch.

The boundary follows from this. Below roughly 30 enquiries a day a full script does not pay off, because maintaining it costs about as much as handling the messages by hand. In practice, start with a night-time autoresponder that records the enquiry, then look at how many messages arrive outside working hours.

A uniformly complex product does not fit a script

If 80% of enquiries require a calculation, a fitting or a consultation, there is nothing to automate. A bot in that niche will only handle identification, and its value comes down to saving 30 seconds.

Investing in reply templates for agents and in faster inbound routing makes more sense here.

What we have not measured

The threshold of 30 enquiries a day is a rough guide, not a measured figure. It moves with the cost of an employee hour and with the share of repeating questions, so run the numbers on your own data.

We also do not cover scripts built on generative models, where the answer is produced on the fly. Their behaviour on non-standard enquiries needs separate testing, and carrying the rules from this article over to them would be premature.

FAQ:

Question: Do we have to tell the customer they are talking to a bot

Answer: Yes, and it is in the company’s interest. A customer who works it out halfway through feels deceived. One sentence at the start settles the question and barely affects their willingness to engage

Question: Can the bot run on the same number our agents use

Answer: Yes, and that is the standard setup. The customer sees one company contact while the conversation passes between automation and people internally. Splitting numbers only makes sense at very high volumes of repetitive enquiries

Question: What do we do if the bot gave a customer wrong information

Answer: Correct it as a human, not as the bot, and on the same day. An apology from an agent with the right answer closes the situation. Separately, find the branch of the script that produced the error

Question: Does a company handling fewer than 30 enquiries a day need a bot

Answer: A full script will not pay off, but a night-time autoresponder that logs the enquiry certainly will. Start there

Question: How does a bot affect messenger restrictions

Answer: A bot that replies works inside conversations the customer started, so it creates no risk. Caution is needed where automation initiates contact with people who have never written to you