When Should an AI Receptionist Hand Over to a Human?
Published
An AI receptionist should hand over when a caller requests a person, the enquiry exceeds its authorised scope, repeated clarification is not helping, or the required action needs human judgement. The handover also needs a fallback for when nobody answers. A transfer button alone does not create a complete service.
The design question is not simply how many calls the system can finish. It is whether the caller reaches a useful outcome, including on calls the system should not finish itself.
Define authority before writing responses
Separate information the assistant may give from decisions it may make. Stating approved opening hours is an information task. Promising a refund, changing a contract or committing to a delivery date may require authority the assistant has not been given.
Write that distinction into the brief. For each call type, specify the allowed answer or action, the information needed, and the point at which a person takes over. Do not rely on a broad instruction to “use good judgement”.
An illustrative rule might be: the assistant can describe the published cancellation process, but a request for an exception goes to the relevant team. The exact rule belongs to the business; the example is not a universal policy.
Use observable triggers
A rule based on what happens in the conversation is easier to test than one based on an assumed emotion. “The caller has requested a manager” is observable. “The caller is probably unreasonable” is an interpretation that should not determine their access to help.
| Situation | Suggested response | What the next person needs |
|---|---|---|
| Caller asks for a person | Offer the available human route promptly | Brief reason for calling, if volunteered |
| Request is outside the approved scope | Explain the limit and offer a transfer or callback | The actual request, without an invented answer |
| Clarification is not resolving the question | Stop repeating the same prompt and offer another route | What remains unclear |
| Caller disputes a decision or asks for an exception | Route to someone with the appropriate authority | Relevant context and the requested outcome |
| A connected system cannot complete an action | State that completion is unconfirmed and use the fallback | Attempted action and failure details |
Choose clarification limits appropriate to the service and test them. There is no single number of prompts that makes every conversation acceptable. Some callers need extra time; others have already clearly asked to leave the automated process.
Explain who is answering and what happens next
Identify the assistant as AI at the beginning. If a person is unavailable, say so and explain the available alternative rather than suggesting that a transfer is about to succeed.
Untangled's AI receptionist service describes AI introductions, configurable handover triggers, transfers and message capture. A business considering it should test those paths using its own roster and call types, including the case where the intended recipient cannot answer.
A warm transfer passes context to the receiving person before or as the call is connected. A direct or blind transfer sends the caller through without that introduction. Neither approach is automatically suitable for every enquiry. Decide what information should accompany the call and make sure it is accurate and appropriate to share.
Preserve context without turning guesses into facts
A helpful summary distinguishes what the caller said from what the system inferred. “Caller says the order has not arrived” preserves the report. “Warehouse failed to dispatch the order” adds a conclusion the assistant may not be able to establish.
Ask the caller to confirm important details where appropriate. Avoid requiring them to repeat a long account simply because the transfer process failed to pass on the information already collected.
Keep the summary proportionate to the task. The receiving employee may need an order reference and the requested action, not every personal detail mentioned during the conversation.
Give the fallback its own workflow
If the call cannot be transferred, explain whether a message can be taken, who will receive it and what response expectation the business can support. Do not turn “we have captured your message” into “the issue has been resolved”.
Specify who checks failed transfers and unassigned callbacks. For critical business functions, establish an alternative route if the AI service itself is unavailable. The National AI Centre's guidance recommends meaningful human oversight, intervention points and alternative pathways for critical functions. Guidance on maintaining human control
Test handovers as carefully as routine answers
Create a set of fictional calls with an expected result. Include a request for a person, an exception to policy, an unclear enquiry and a failed booking action. Run them when the recipient is available and when they are not.
Score concrete outcomes: did the assistant recognise the limit, explain the next step, preserve the caller's details and deliver the enquiry to the correct place? Record failures and retest after changes.
Do not make “fewest transfers” the only success measure. A low transfer count can hide calls that should have reached a person. Review repeated clarification, abandoned handovers and unresolved messages alongside completed automated tasks.
An effective handover rule gives the assistant a clear boundary and gives the caller a workable next step. Both need attention as staff, services and customer questions change.