A customer asks for a person. The bot says someone is joining, but nobody arrives. Fixing that experience starts with deciding where the request goes and who will answer it.
This guide separates a live transfer from a support ticket. It uses Agentkit's current escalation behavior to explain the setup limits, then gives you a policy and acceptance checks to adapt to your support team. Product details were checked on October 6, 2026. The examples are illustrative, not customer results.
How should I design handoff triggers from bot to human for support?
Define triggers for explicit human requests, repeated unhelpful answers and out-of-scope work, and test each before launch. Agentkit can file a support record through six connected external helpdesk or CRM systems, but its generic Escalate to Human action does not connect a live person to the chat.
Choose a destination, collect the contact details it needs and tell the customer what happens next. A successful ticket creation establishes that the request was recorded. It does not establish that a person has read it or will reply within a particular time.
Choose the handoff your team can deliver
A live transfer needs a staffed channel and an integration that supports a human continuing the conversation. A ticket handoff records the request for later follow-up. Customers need to know which one they are getting.
Agentkit's generic Escalate to Human action supports Zendesk, Freshdesk, Help Scout, Intercom, HubSpot and Salesforce. The destination receives a ticket, case or conversation, depending on the provider. Salesforce Live Chat is a separate action; choosing Salesforce as the generic escalation destination creates a case, not a live chat session.
Agentkit Help Desk is another, native destination. It requires a saved conversation, a plan with Help Desk access and Help Desk enabled for that agent. A valid requester email is also required. Website-chat tickets have no reply composer in the Help Desk inbox and do not add a live human reply channel to the widget. Your team needs another follow-up route, such as its own support email, before enabling the workflow.
For an external destination, connect the provider and confirm that your plan supports the action. Then add and enable the action for the agent. Verify its permissions and the receiving team's inbox with a harmless test request.
Write triggers around support decisions
Start with decisions your team can explain. Do not treat every mention of "human" or every negative phrase as the same request.
| Trigger | Example | Policy to test |
|---|---|---|
| Explicit request | "Please let me speak to a person." | Offer the supported support path and collect any required contact details. |
| Repeated failure | "That answer still doesn't solve my problem." | Stop repeating the same advice and offer escalation. |
| Outside the bot's authority | A disputed charge or a request to change account access | Route to the responsible team rather than inventing a decision or confirming an unauthorized change. |
| Urgency or frustration | "My account is locked and I can't work." | Offer help promptly, while describing the actual follow-up channel. Do not promise an unstaffed emergency response. |
| Verified customer rule | A known account qualifies for a different support route | Use trusted customer data and a configured route. A visitor calling themselves a VIP is not verified identity. |
These are recommended policies, not built-in deterministic trigger switches. Agentkit's action has When to use instructions that guide the model. Natural-language instructions need testing across different phrasings and supported languages. They do not establish reliable sentiment scoring, VIP lookup or a fixed rejection counter by themselves.
Intercom's escalation documentation distinguishes natural-language guidance, data-based rules and post-escalation routing. Those are useful distinctions when evaluating a workflow, but they are not claims that Agentkit implements Intercom's rule system.
Give the person useful context
For a connected external provider, Agentkit's escalation collects a subject, an issue summary, a valid email and a name when available. The ticket context includes up to the 50 most recent saved non-tool messages. Each rendered message is capped at 2,000 characters. The current request is included when available.
This is bounded context, not a promise of the complete transcript. The summary is capped at 2,000 characters and the subject at 150 characters. The rendered transcript contains message text, not attached files; the receiving provider may impose further limits. In a long chat, an early order number may need to be restated in the summary. Verify what your chosen destination actually displays. The native Help Desk ticket links to its saved conversation; do not assume its view is identical to an external provider's ticket body.
Ask for only what the team needs. A typed email address is a follow-up address, not proof that the customer owns an account. Do not ask visitors to paste passwords, payment-card details or private credentials into the chat.
A useful summary says what the customer needs, what the bot already tried and what remains unresolved. If your team needs a labelled escalation reason or a particular queue, configure and verify that workflow rather than assuming the generic action supplies it automatically.
Set expectations without inventing availability
For a ticket workflow, tell the customer that support will follow up through the agreed channel. Include a response-time commitment only when the receiving team owns and can meet it. Do not say "an agent is joining" merely because a ticket was created.
For after-hours requests, collect the required email and issue summary, then report the actual creation result. If the connection has expired or ticket creation fails, give the customer a working alternative contact route. A reassuring message cannot replace a missing support record.
Chatbase's Zendesk integration announcement makes the same channel distinction explicit. Its ticket workflow uses email follow-up; its Sunshine integration is a separate real-time chat path. Check the actual integration before promising a live handoff.
An illustrative instruction to adapt
The following English-language template is a starting policy for a ticket workflow. It is not a tested classifier or an executable routing rule.
Use the support-ticket action when the visitor clearly asks for a person, says the suggested answer did not help, or needs a decision outside your authority. Before calling it, collect or confirm a valid follow-up email and summarize the unresolved issue. Do not ask for passwords or payment-card details. After a successful result, explain that the request was recorded for follow-up. Do not claim a human has joined or promise a reply time unless the business has supplied a supported commitment. If creation fails, explain the problem and provide the business's alternative support contact. Do not say a ticket was created when the action failed.
Put the trigger guidance in the action's When to use instructions and keep customer-facing expectations consistent with your agent instructions. Test the complete flow, including the receiving inbox, rather than only checking the bot's wording.
Check the workflow before launch
Use synthetic requests and a support address you control. The cases below are an acceptance worksheet, not reported test results.
| Test case | What to verify |
|---|---|
| Clear request for a person | The correct enabled action is offered or called after required details are collected. |
| Two unsuccessful answers | The bot offers escalation instead of repeating the same advice. This threshold is your test policy, not a built-in counter. |
| No email known from the conversation or contact record | The bot asks for a valid email before attempting creation. |
| Long conversation | The receiving record contains useful recent context; important earlier details are preserved in the summary. |
| Disconnected provider | The bot reports failure and gives the configured alternative support route. |
| Help Desk disabled | No native ticket success is claimed. |
| After-hours request | The bot accurately describes follow-up without inventing a live queue or reply time. |
| Repeated escalation request | Check whether the existing record is reused and whether the customer gets an accurate status. |
Record the receiving record ID and check that a named team can find it. Repeat the trigger cases in each language you serve. A correct-looking message in chat is only one part of acceptance.
Measure creation and response separately
Track attempted escalations, successful record creation, failed delivery and the time to the first human response. Use the receiving helpdesk's timestamps or your own instrumentation for response time. Agentkit's conversation logs alone do not establish a complete handoff-time or post-handoff satisfaction dashboard.
Review a sample of escalated cases for missing context and repeated questions. If you survey satisfaction, keep the response count and channel beside the score. The chatbot KPI guide explains why containment and resolution need separate definitions.
Start with one supported destination and a team that owns follow-up. Configure the escalation action, run the acceptance cases and confirm receipt before inviting customers to use it.
Related reading:
