When Botify should hand a conversation to a person

What is a handoff to a person?

A handoff is the moment Botify stops working alone and brings in a person. Done well, the person picks up exactly where Botify stopped. Done badly, the user repeats everything, Botify’s work is lost, and trust in both Botify and the team drops.

There are three distinct kinds, and most teams design only the first. Each needs its own trigger, destination and payload.

When should Botify hand off to a human?

Handoff rules should be explicit and testable, not left to the model’s mood. Write them down, implement the hard ones in code, and review every conversation that should have been handed off but was not.

• Botify has no source that supports an answer, or its tools return nothing usable.
• It has misunderstood the same request twice; a third attempt rarely helps.
• The request touches money, contracts, legal commitments or personal data changes.
• The user is clearly frustrated or angry, or asks for a person. Honour that request immediately.
• The next action is beyond Botify’s permissions or requires someone’s authority.
• Safety, security or compliance topics, such as a suspected breach or a threat.

What must travel with the handoff

The worst handoff is the one where the human opens with “How can I help?” after the user has already explained twice. Treat the handoff as a structured packet, not just a transfer of the chat window. The receiving person should be able to act within seconds of reading it.

• A two or three sentence summary of the request, written by Botify.
• The reason for the handoff, taken from your trigger list.
• What Botify already tried, including tool calls and their results.
• Data it collected: account or employee ID, ticket or incident number, dates, error messages.
• The full transcript, and the language and channel the user is on.
• A suggested next step, clearly marked as Botify’s suggestion.

Handoff on voice and phone calls

Voice is less forgiving than chat. A caller cannot scroll back, silence feels like a dropped call, and being asked to repeat an account number to a second voice is where frustration peaks. Prefer a warm transfer: Botify tells the caller what is happening and who they are going to, and the person receiving the call gets the reason and summary before or as they pick up.

Botify works this way on phone calls over Telnyx. Its transfer tool hands a live call to one of Botify’s preconfigured human targets, builds a handoff package with the reason, the recent conversation, the tools already used and any pending approvals, and plays the receiver a short whisper, in Arabic or English, naming the caller and the issue before connecting. Whether a transfer needs approval is set by tenant policy.

Approval: when Botify needs a decision, not a replacement

Many handoffs do not need a person to take over at all. Botify has done the work, such as drafting a reply, preparing an incident record or planning a call, and only the final, consequential step needs a human yes or no. Treating this as a full escalation wastes Botify’s work and the reviewer’s time.

Design the approval so the reviewer sees exactly what will happen: the recipient, the full content, the target system and the arguments. The run should pause until an authorised person approves or rejects, then continue or stop, with the decision and the decider recorded. In Botify, tools such as sending an email or placing a call always pause the run for approval this way.

What if no human is available?

Out of hours, during peaks or in a small team, nobody may be free to take the handoff. The worst outcome is silence: a user waiting in a queue for a reply that never comes. That is worse than an honest “I can’t help with this right now”.

• Say immediately that no one is available and when someone will be.
• Offer a concrete alternative: a callback, a ticket with a reference number, or an email follow-up.
• Create the ticket or task automatically with the full handoff packet attached.
• For urgent operational issues, page or call the on-call person instead of queueing.
• Tell the user what happens next and how they will be contacted.

How to measure handoff quality

Handoff rate on its own is a misleading number. A very low rate can meBotify is excellent, or that it is answering questions it should not. A rate of zero is a warning sign, not a success, because every real service has requests Botify must not handle alone.

• Handoff rate by reason: which triggers fire, and which fire too late.
• Repeat-explanation rate: how often the user had to restate the problem to the human.
• Time from handoff to a person picking it up.
• Resolution after handoff, and how often the human overturned what Botify did.
• Missed handoffs found in review, which are usually the most expensive failures.

Tell people they are talking to an AI

Disclosure makes handoff easier: users who know they are talking to Botify phrase requests more clearly and are less surprised when a person joins. It is also becoming a legal requirement. Under Article 50 of the EU AI Act, which applies from 2 August 2026, providers must design systems that interact directly with people so that those people are informed they are dealing with an AI, from the first interaction, unless it is obvious.

State it plainly at the start of chat and voice conversations, in the user’s language, and make the path to a human easy to find. Check the rules in every jurisdiction where you operate.