Direct answer
Clause 5.2.2 of GB/T 47746—2026 lists seven routes for switching from intelligent to live service: switch method, keywords, menu, key press, voice, automatic transfer in specific scenarios, and emotion sensing. Designing a flow is not a matter of picking one of them — it is a combination of a primary route and a fallback. Put keywords and menu entries in front by default, back them with the five automatic-transfer scenarios in 5.2.2.6, and make sure that once the transfer happens the agent can see the full conversation, so the customer does not have to explain everything again.
First, see how many routes the standard actually gives you
GB/T 47746—2026 writes the intelligent-to-live switch as seven routes: switch method, keywords, menu, key press, voice, automatic transfer in specific scenarios, and emotion sensing. Note that this is a list of parallel entry points, not a menu to choose one item from.
The right shape: two layers
Layer one — primary routes (the customer initiates). Keywords, menu, key press and voice are all, at bottom, ways for a customer to say "I want a human". Put them where the customer can always reach them: a permanent "transfer to agent" button in the chat window, key-press options after a voice prompt, and a keyword list that covers synonyms such as "complaint / agent / transfer / let me speak to your manager".
Layer two — fallback (the system initiates it). Clause 5.2.2.6 requires automatic transfer in five situations: a) the interaction has reached the failure threshold and the system still cannot recognise the request; b) the customer explicitly refuses intelligent service; c) the conversation involves information security; d) an emergency or risk situation affecting personal or property safety; e) the intelligent response times out (the standard's own example being more than 3 min). This second layer is what really decides whether a customer ends up angry — three unresolved attempts while the system keeps re-asking the same question is the single biggest source of complaints.
What has to travel with the transfer
A transfer is not a new window starting from zero. At minimum, three things should cross over:
- the full conversation record (facts the customer has already given, so they do not repeat themselves);
- the customer identity and request category already identified;
- the handling actions already attempted, and their outcomes.
Chapter 4 of the standard describes the service experience as "smooth"; at the operational level, this is what that means.
Three ways businesses get it wrong
| Approach | Problem |
|---|---|
| Only a keyword entry point | Customers do not use the standard words, there is no fallback, and they are stranded inside the bot. |
| Transfer without context for the agent | The customer is forced to repeat the description, which is worse than having no AI in front of them at all. |
| Threshold set too late | The standard triggers a transfer when the failure threshold is reached, not only after every option has been exhausted. |
A suggested order of work
- Configure the five automatic-transfer scenarios first — they are mandatory, not optional;
- then add the keyword list and buttons for the customer-initiated routes;
- then wire up context passing at the moment of transfer;
- after go-live, sample real conversations once a quarter to check that transfers are firing as they should.
Key facts
| Routes for intelligent-to-live transfer | Seven (switch method, keywords, menu, key press, voice, automatic transfer in specific scenarios, emotion sensing) |
| Mandatory automatic-transfer scenarios | Five (5.2.2.6 a to e) |
| Timeout example | The standard uses a delay of more than 3 min as its example of a response timeout |
| What a transfer should carry | Conversation record, identity and request, actions already attempted |
Sources
- GB/T 47746—2026, clause 5.2.2 (intelligent to live handover)
- GB/T 47746—2026, clause 5.2.2.6 (automatic transfer in specific scenarios)
- GB/T 47746—2026, chapter 4 (general requirements — smooth service experience)
Follow-up questions
Do all seven routes have to be implemented?
The routes are a set of parallel entry points, and in practice they are combined as a primary route plus a fallback. But the five scenarios in 5.2.2.6 are mandatory automatic transfers, and that part cannot be dropped.
How should the failure threshold be set?
The standard gives no single figure; a business sets a value for its own context and keeps the evidence. The principle is that a customer who is repeatedly left unresolved must trigger a transfer — a common approach is to transfer after 2 or 3 consecutive rounds without recognition.
Does emotion sensing require an AI emotion model?
Not necessarily. Emotion sensing is one of the routes and can be implemented with keywords, tone rules or human monitoring instead. What matters is that the route exists and can be verified.
What if no agent picks up after the transfer?
The customer must be given a clear expected wait and a commitment to a reply rather than waiting indefinitely. This falls under service safety and control and a smooth experience; queue prompts and a callback-on-message option are reasonable measures.