Designing chatbot handover: when a bot should pass the conversation to a person

At SSL Wireless I led the development of iBot, an omni-channel conversational AI chatbot for Messenger, WhatsApp, Telegram and web chat, with conversations kept in sync across channels in real time and live handover to human agents. Clients embedded and configured it through a web SDK and REST APIs, and the same engine later ran Chatshop's conversational commerce, which I delivered as project lead.

The question I would put at the centre of any chatbot design is not how much the bot can handle. It is how well the bot knows the limits of what it should handle, and what happens to the customer at that boundary. This post covers the pieces that decide it: a conversation model that works across channels, confidence that leads to different actions, explicit triggers for handover, and a handover that carries its context with it.

One conversation, many channels

Every messaging platform has its own formats, limits and rules, and the bot should not need to know any of them. Channel adapters turn each inbound message into one internal shape, and turn the bot's replies back into whatever the channel supports.

flowchart LR
  W[WhatsApp] --> AD[Channel adapters]
  M[Messenger] --> AD
  T[Telegram] --> AD
  WC[Web chat] --> AD
  AD --> CV[One conversation per customer]:::accent
  CV --> BOT[Bot]
  CV --> AG[Agent]

type InboundMessage = {
  conversationId: string;
  customerId: string; // one customer, whichever channel they write from
  channel: "whatsapp" | "messenger" | "telegram" | "web";
  receivedAt: string;
  content:
    | { type: "text"; text: string }
    | { type: "button"; payload: string }
    | { type: "media"; url: string; mimeType: string };
};

The adapters also carry each channel's rules. On the WhatsApp Business Platform, a business can send free-form messages only within 24 hours of the customer's last message, and after that only pre-approved templates. Messenger has a similar 24-hour window. A Telegram bot cannot message someone who has not started a conversation with it. These rules shape the handover as much as the bot: an agent who picks up a conversation late may no longer be allowed to reply freely.

Keying conversations to the customer rather than the channel is what makes real-time sync possible. A customer who starts on web chat and carries on in WhatsApp is still in one conversation, and so is the agent who takes it over.

Understand, then decide how sure to be

Each message is classified into an intent (what the customer wants) with the details needed to act on it: an order number, a product, a size. The classifier also returns a confidence, and confidence should change what the bot does, not just whether it replies:

flowchart TD
  M[Message] --> C[Intent and details]
  C --> H{Confidence}
  H -->|high, details complete| ACT[Act and reply]:::accent
  H -->|high, detail missing| ASK[Ask for the detail]
  H -->|medium| CF[Confirm before acting]
  H -->|low| RE[Ask to rephrase]

Thresholds are tuned per intent. A wrong guess about opening hours costs little; a wrong guess about a cancellation costs a lot, so intents that change something deserve a higher bar.

Act through the same systems as the support team

A bot that can only answer questions sends customers to a form. A useful one calls the APIs the support team already uses: it looks up an order, checks stock, books a slot. I treat those APIs as tools with explicit permissions. Reading data is allowed freely; anything that changes state, such as a cancellation, a refund or a new delivery address, needs the customer's confirmation first, and some actions should not be available to the bot at all.

When to hand over

Handover rules work best when they are explicit, reviewable and few. These are the triggers I would start with:

A handover that carries its context

The worst handover makes the customer start again. The agent should join the same conversation, on the same channel, with what the bot learned in front of them:

• the transcript so far
• the detected intent and the details collected
• what the bot has already done, such as looking up an order, and what it found
• why the handover happened

The customer should be told what is happening and roughly how long it will take. Outside support hours, the honest option is to say so, collect what the team will need, and open a ticket, rather than leave the customer in a queue nobody is watching.

Handover also needs a clear owner at every moment. A small state machine stops the bot and an agent from replying at the same time, one of the most confusing things a customer can see:

stateDiagram-v2
  [*] --> Bot
  Bot --> WaitingForAgent: handover trigger
  WaitingForAgent --> WithAgent: an agent joins
  WaitingForAgent --> Ticket: outside support hours
  WithAgent --> Bot: resolved, customer carries on
  WithAgent --> [*]: conversation closed

Measuring it honestly

The figure chatbot projects like to report is containment: the share of conversations that never reached a person. On its own it rewards a bot that makes handover hard. I would pair it with figures that describe the customer's experience:

• Resolution, not just containment: whether the problem was solved, judged by repeat contacts about the same issue
• Handover rate by intent, to show where the bot is out of its depth
• Time from handover to an agent's first reply
• Satisfaction after handover, compared with satisfaction when the bot resolves things alone

A good bot takes the routine work off the support team and hands them the conversations that need a person, already half understood. That balance is what is worth designing for.