How Should a UAE Business Hand AI Enquiries to Its Human Team?

A handoff works when it is built as a process, not left to the moment. Decide in advance which conversations leave the AI, where they go, what the human receives, who is actually watching, what happens when nobody is, and how you will know the case was picked up. The single most important design decision is recognising that a platform telling you a handoff occurred is not the same as a human accepting the case — and the rest of the checklist exists to close that gap.

Why the handoff signal is not a handoff

Google’s Dialogflow CX documentation is unusually explicit about this. It describes the LiveAgentHandoff response as indicating that the conversation should be handed off to a live agent, and states that the platform uses the signal only to determine which conversations were handed off to a human agent for measurement purposes — what happens to it next is left to the implementer and its own handoff procedures. The metadata you attach is freeform; the platform imposes no structure on it. In practice, the software firing an event records that a handoff signal went out. It does not prove the trigger was appropriate, that routing worked, or that a person received the case. Whether someone saw it, opened it, or answered the customer is entirely your process. Design for that gap.

When should the AI stop?

Pick a small set of explicit conditions and encode them, rather than trusting the model to guess. A proposed starting point: the customer asks for a human; the case involves money, a dispute, or a complaint; the topic is sensitive or outside what the AI was trained on; the customer has been repeatedly misunderstood. Devs Group’s own site draws the line at escalating “complex or sensitive cases to human agents with full conversation history” — a useful shape for the rule, understood as the vendor’s description of its service rather than a benchmark. Whatever the set, write it down so two managers would escalate the same conversation the same way.

What must the human receive?

At minimum: the relevant permitted context — the conversation history, what the customer wants, what the AI has already confirmed or promised, and the ticket identifier. The idea is that the human picks up the case without starting over; anything they would have to re-ask is context the handoff should have carried. Branch and preferred language are optional routing fields — worth including if your team genuinely dispatches on them, unnecessary if it is one desk.

Who owns the case?

A named queue or a named person, with a backup. “The support team” is not an owner. A shared inbox is a design risk — when everyone assumes someone else will take a case, nothing in the process forces it to happen. If the queue is one person in Dubai covering the day shift, the checklist should say so, and it should name who covers the gaps.

What if nobody is there?

State your staffed hours, then design the after-hours path. WhatsApp’s Business Messaging Policy allows automation inside the 24-hour customer service window, but requires “prompt, clear, and direct escalation paths,” and names examples that qualify: in-chat human agent transfer, a phone number, email, web support, an in-store visit, or a support form. Two consequences follow. The 24-hour window is a messaging permission that opens and resets with each customer message — it is not a requirement, and it is not evidence, that humans staff around the clock. And if your team covers business hours only, the customer still needs one of those named routes, offered plainly. Presenting it at the moment of handoff is a proposed workflow choice, not timing language from the policy.

How do you know it worked?

Track two numbers separately. Acknowledgement: did a human accept the case, and how long after the signal fired? Closure: was the case resolved and the customer answered? Counting handoff events alone measures the machine. If your acknowledgement rate falls below whatever bar you set, the result points to a process that needs inspection — the trigger, the queue, and the hours are all suspects, and the number does not say which one is at fault.

The checklist

1. Trigger — the specific conditions that move a conversation from AI to human: explicit request, money or dispute, sensitive topic, repeated misunderstanding.
2. Permitted action — what the system does when the trigger fires, and what the AI may tell the customer while they wait. Do not promise a response time you do not staff for.
3. Owner — the named queue or person who takes the case, plus a backup.
4. Context — the relevant permitted context: conversation history, stated intent, prior commitments, ticket ID; branch and preferred language only if you dispatch on them.
5. Staffed hours — the published times when a human will actually take the case.
6. Fallback — the route a customer takes when nobody is staffed: phone, email, web form, or in-store visit, drawn from the policy’s named escalation paths. A stated callback commitment is your own operational addition, not a route the policy establishes.
7. Measurement — human acknowledgement time and closure rate, tracked separately from handoff signal count.

Before switching the flow on for real customers, send a test enquiry through the entire chain and confirm a person sees it. The checklist’s job is to give every link in that chain a defined owner and a number to watch — which is what separates a handoff you can verify from one you are hoping works.