Chatbot handover to a person: triggers, context and operating process

Human handover is not an emergency exit for poor conversations. It is a planned part of service design. A bot needs to recognise when it cannot or must not continue, select the right destination and transfer useful context. Otherwise the customer repeats the entire issue after several automated steps.

Define handover triggers

Common triggers include:

• an explicit request for a person;
• repeated failure to understand;
• missing or conflicting sources;
• sensitive, legal or binding decisions;
• deteriorating conversation;
• failed authentication;
• integration or technical failure;
• a request outside supported language, region or service time.

Not every negative experience can be detected reliably. Combine clear rules, user choice and carefully evaluated signals.

Collect only necessary information

The bot should gather only what improves routing and resolution. Explain why information is required. Avoid requesting sensitive data before identity, purpose and permitted processing are clear.

A handover package may contain:

• topic and recognised intent;
• concise summary;
• details already confirmed;
• actions taken and result;
• source used;
• error or escalation reason;
• preferred channel and language;
• conversation identifier.

The full transcript is not always necessary. A structured summary can reduce search effort and unnecessary data transfer.

Make routing and availability transparent

Define which team owns each request and what happens outside service hours. Do not promise an immediate connection when only a callback or ticket is available.

Communicate the destination, next step, available channel, supported expectation, option to correct contact details and behaviour if the session ends.

Preserve user control while waiting

Confirm that transfer has started. Show a ticket or conversation number where available. Prevent duplicate transfers caused by repeated clicks. If the user leaves, explain whether the request has been saved.

Give the human usable context

The receiving person needs a concise record, not only a long transcript. Separate user statements from system assumptions. Show completed actions. A person must be able to correct a wrong bot statement without that statement continuing as accepted truth.

Govern return and closure

Not every case ends with the person. Define whether a resolved stage can return to automation and which statuses represent completion. The user should receive a clear confirmation.

Test difficult cases

Cover:

1. explicit transfer request;
2. repeated unknown wording;
3. sensitive request;
4. destination-system failure;
5. request outside service hours;
6. incorrect routing;
7. abandonment and return;
8. duplicate transfer;
9. missing consent or authentication;
10. correction of a wrong bot answer.

Choose operating metrics carefully

Monitor handover rate by intent, reasons, misrouting, wait time, abandonment, repeat contact and resolution. A low transfer rate is not automatically good; the bot may be trapping users. A high rate can expose narrow scope or weak knowledge.

Acceptance gate

Handover is ready when triggers are documented, users can request a person, routing and service times are correct, necessary context transfers safely, failure cases are tested and a team owns operations.

A good bot does not try to keep every conversation. It transfers at the right time, explains what will happen and enables the next person to continue.