Handover to Humans
Handover is the moment your Agent Stack stops handling a conversation and a human takes over. Sometimes this is graceful — the AI gathers what it needs, summarizes, and a human picks up with full context. Sometimes it’s urgent — the customer is frustrated and the AI gets out of the way. Either way, the Handover tab is where you configure both ends of that handoff.
The three sub-tabs
The Handover tab has three sub-tabs that walk you through the lifecycle of a handover:
- Triggers — Whether handover is allowed at all, and what triggers it
- Prerequisites — The information the AI must collect from the customer before handing off
- Delivery — Who picks up, and what happens outside opening hours
Disabling handover at the Triggers level (setting handover mode to “never”) greys out the other two sub-tabs — they only matter once handover is allowed.
Handover modes
A stack can be configured with one of three handover modes (full reference: handover modes):
- never — the stack never hands off. Conversations either resolve in-AI or the customer gives up. Rare; only sensible for stacks that handle a single closed task with no human-help fallback.
- by_description — the AI decides when handover is needed based on its trigger rules (frustration, legal threat, escalation request, stall) and routes to a team derived from the conversation context. The default for most stacks.
- explicit_team — handover always goes to one specific team you choose. Use this when only one team handles all human-needed cases for this stack.
Prerequisites — gather before you handoff
Prerequisites are the questions the AI must have answers to before handing off. Each prerequisite has:
- A field — either a conversation field or a contact field. The answer is saved into that field.
- An ask prompt — operator guidance and diagnostic text that tells the AI what information to collect. This is not customer-facing copy: Atender generates the customer-visible ask in the conversation language using the prerequisite field label, so make the field label clear and easy to translate.
- A condition mode —
always(always required) orwhen(required only when a stated condition is met). - A sort order — prerequisites are checked in order.
A typical setup: a billing stack might require the customer’s account email and the invoice number before handoff. The AI checks each prerequisite, asks for anything missing, and only triggers handover once everything applicable is collected. If the customer can’t or won’t provide a value, the orchestrator may hand off anyway under risk-escalation logic — prerequisites are best-effort.
Outside opening hours
The Delivery tab includes opening-hours behavior. When Check opening hours before handing over is on (off by default) and the team is closed, the AI offers the outside-hours options you enabled:
- Offer email follow-up — Asks for the customer’s email so the team can reply during opening hours (default: on)
- Offer to close and reach out later — Lets the customer close the conversation and try again during opening hours (default: off)
Ask the customer to confirm before handing over (default: off) sits beside these but is not an outside-hours option — it is an independent toggle that applies to every handover, whether the team is open or closed. When the customer confirms and the team is still closed with email follow-up enabled, that confirmation is treated as email follow-up; if the team has reopened, the confirmation proceeds as a live handover or queueing.
Email follow-up on web chat
On a web chat conversation, choosing email follow-up does two separate things, and only the first is immediate:
- The handover commits right away. The team receives it with the address the customer gave, whether or not that address is ever confirmed.
- Moving the conversation onto email waits for proof. Atender parks the channel switch and emails a confirmation link to the address (valid for 24 hours). The conversation only becomes an email conversation once the customer opens that link and confirms — the link is confirmed by a POST, never a plain page load, so a mail scanner cannot confirm it on the customer’s behalf.
There is no shortcut: the link is sent every time, including for an address already on the contact. If the workspace cannot send on email at all, or the widget’s tenant has channel switching unavailable, the switch is skipped and the handover stays a metadata-only handover on web chat.
Handover instructions
The Delivery tab also has a free-form Handover instructions field — extra context the AI uses to decide how to hand off and what to put in the handoff pack. Examples: “Mention if the customer has been a customer for over 5 years,” or “Always tell the customer the human’s first name.”
What the human picks up
When handover delivery succeeds, the conversation moves out of the Alia tab and into the chosen team’s queue. The handoff pack (prepared by the handoff infrastructure agent) is attached to the conversation: a summary of what happened, the customer’s sentiment, key details collected during prerequisites, and suggestions for next steps. The human picks up with all of that available, not from scratch.
For normal configured handovers, if Atender cannot assign a team, or if handover resolution repeatedly fails, it does not promise the customer a human follow-up. Instead, the AI stays engaged in the conversation and operators are alerted so the delivery problem can be investigated.
Repeated guardrail failures are not a handover. When a reply fails the output guardrails twice, the platform never forces a handover in any mode: it ships the canned “ran into a problem, try again” line, records the turn’s outcome as a forced fallback, and leaves the AI engaged so it can try again on the next turn. A handover the discarded reply itself asked for is not dispatched either, because the whole turn was thrown away. If the conversation genuinely needs a person, the orchestrator hands over on a later turn through the normal path above.