A Dubai retailer uses a chat assistant to answer delivery questions. One customer asks where an order is and gets an accurate tracking link. Another says the carrier marked a package as delivered but it never arrived. The assistant supplies the same link. The second customer now needs someone who can check delivery evidence, open a dispute and explain what happens next. Both conversations began as tracking questions. Only one could be resolved by showing the tracking page.
An AI handover works when the customer reaches someone with the context and authority to take the next action. A message that says the team has been notified is worth little if the ticket was never created, nobody owns it or the employee cannot see the order. For a UAE business, design the escalation around what has happened to the customer, then test that the route works in Arabic and English, during quiet hours and when the receiving team is busy.
Decide who can take each action
Separate questions the assistant can answer from requests it can safely complete and cases that need discretion. For a retailer, opening hours might come from an approved knowledge base. A delivery estimate might come from an authenticated order lookup. A charge dispute, repeated failed delivery or refund exception may require an employee who can inspect records and decide what the company will do. That authority needs to exist in the receiving queue. A person who can only read the same tracking result adds a second conversation without advancing the case.
Give customers a direct route to a person when they ask for one. Test common Arabic and English wording and the ways someone might make the request mid-conversation. Other triggers can come from the facts of the case. A request to change an account after suspected misuse warrants a different route from a typo in a delivery address. An assistant that cannot establish whether a refund has already been issued should pass along that uncertainty before anyone makes a second payment.
Write the trigger and receiving role together. Build a working fallback for any trigger that can arrive outside the team's hours or when a queue is full.
| Signal | Assistant action | Receiving role |
|---|---|---|
| Customer asks for a person | Offer the available live or asynchronous route | General support, with requested language recorded |
| Delivery marked complete but disputed | Save order reference and record that receipt is contested | Delivery investigation team |
| Duplicate charge or disputed refund | Stop payment actions and create a case after the required verification | Payments or refunds team |
| Possible account misuse | Follow the verified security route and limit account disclosure | Staff trained in account security |
| Repeated failed attempts | Keep the case history and bypass the loop that already failed | Support agent able to inspect prior contacts |
| Transfer fails technically | Offer a fallback channel or record a callback if it can be fulfilled | Queue owner or duty supervisor |
A category detected by AI can help route the case. Verify the route against visible facts such as whether the customer requested a person, a transaction has already failed or the queue is currently available. A score for model confidence cannot establish whether the customer is entitled to an exception or whether a human is on duty.
Keep formal complaints distinct from general help
Decide how the system identifies and registers a complaint. Someone who says they have asked three times for a promised refund may be complaining without using that word. The workflow should preserve the customer's own description, route it according to the company's policy and show whether a formal case has actually been opened. Confirm what the business must record, acknowledge and retain for its sector and jurisdiction.
Dubai Consumer Rights describes a complaint service for eligible individuals dealing with Dubai Department of Economy and Tourism-licensed establishments within its jurisdiction. TDRA's dispute resolution service for consumers of approved UAE telecom providers says a customer must first submit a complaint to the service provider. These are distinct routes. A bot that uses a single external referral for all cases risks pointing a customer to the wrong place or skipping the provider's own complaint step. Keep the relevant route in a maintained policy record and make it visible to the receiving team. Dubai Consumer Rights complaint service and TDRA dispute resolution service
A Dubai Consumer Rights reel illustrates complaint follow-up as a separate step after the initial contact. For the business, the design question is whether the customer can retrieve the case reference and whether a second agent can see what has happened since it was issued.
Pass the minimum context needed to act
A handover should deliver a case reference, the reason for escalation, the requested outcome, the language of contact and a short account of the actions already taken. Include which checks succeeded and which remain outstanding. Link to approved supporting evidence with the same access controls the receiving employee would normally use. If the bot has only recorded the customer's account of events, label it as such. A statement such as “customer reports no delivery” preserves uncertainty that would vanish in a summary saying “order lost.”
Where the order system supplies a value, identify that system as the source. Where the assistant infers a detail, allow the employee to check the original message. An Arabic note that conveys a dispute over which person received the parcel may lose meaning if translated into a generic complaint summary. Keep the relevant original wording accessible to authorized staff. Avoid copying full transcripts into every receiving queue when a short summary and a controlled link would suffice. Set the treatment of sensitive content, access and retention before enabling transcript transfer.
Microsoft documents one example of a custom handoff adapter that relays conversation context between a Copilot Studio agent and an engagement hub. A product that offers a transfer feature still needs a successful test of the buyer's own integration. Confirm that the destination receives the reference and relevant context and that access to attachments works for the staff role expected to handle the case. Microsoft Copilot Studio handoff documentation
Treat delivery to the queue as something to verify
Distinguish a request for transfer from a confirmed handover. Record when the request was made, when the destination accepted it and when someone took responsibility. An order reference printed in the chat is different from a case identifier issued by the support system. Give the customer a case reference only after one exists, then explain whether the next step is live chat, a callback or an asynchronous reply. Any timing the assistant gives should reflect an operating commitment the team can actually meet.
If a connection fails midway, the system may be unsure whether the first attempt created a case. Test how it checks before creating a second one. For example, the integration can send a stable transfer identifier and look it up after a timeout. If the queue has accepted the case, the customer can recover the reference. If the attempt genuinely failed, the service can retry or provide a real alternate route. Include the reverse test too. A customer who starts a new conversation about an unresolved complaint should be able to reach the existing case after the appropriate verification.
Work out what happens when there is no live agent. For an asynchronous queue, capture the approved contact method and tell the customer how to find the update. Give the queue an owner who checks old and unassigned cases. A supervisor should be able to see when the assistant has accepted work that a person still needs to do. Put failed transfers and unclaimed tickets on the same operating dashboard used to run the support team.
Measure resolution across the whole contact
Consider a hypothetical week with 1,000 support conversations. The assistant makes 200 requests for transfer. The receiving system acknowledges 180 and staff pick up 150. The acknowledgement rate is 90% of requested transfers. Staff pick up 75% of requests. If an operations report shows only the 180 acknowledged cases, the team misses 20 failed transfers and may overlook another 30 acknowledged cases that nobody picked up. Those gaps need different fixes.
Count resolved cases separately from completed transfers. For each group of requests, review the time from first contact to resolution, the number of times the customer had to return and whether a promised action was carried out. Track unsuccessful exits from self-service by sampling chats that end after repeated prompts or an unanswered request for help. A closed chat can mean the customer left. Compare it with support tickets and repeat contacts where the company is permitted to connect those records.
Segment the results by channel, language, reason for transfer and time of day. Report the sample size beside the rate. A small group of overnight Arabic payment complaints can be missed in a daily average. Review those cases directly if the volume is too low for a stable rate. Separate slow queue pickup from errors in classification or missing context so the team knows which part to change.
Measure staffing where work actually arrives. Suppose the hypothetical retailer sees 18 handovers in the busiest half hour and each takes eight minutes of employee effort. That is 144 minutes of work in 30 minutes. Five people would supply 150 minutes only if every minute were available for this queue. Calls already in progress, breaks and uneven arrivals make five a thin starting assumption. Measure elapsed time and employee effort separately for asynchronous cases before applying the same arithmetic.
Test the handover before widening automation
Use approved or synthetic records to walk through actual screens and queues. Simulate an Arabic complaint after closing, a dropped connection while a ticket is being created and a returning customer who already has a case. Test someone asking for a human while the assistant is still trying to answer, then check that the agent sees the request and all necessary context. Have the agent take the next action, such as requesting delivery evidence, and verify that the action appears in the case history.
Write the expected result before each run. For a disputed delivery, a successful test might require the assistant to create a case in the correct queue, capture the language preference, preserve the fact that receipt is disputed and avoid promising reimbursement. For an account concern, the expected result may be to move the customer to an approved security route without exposing account details. Run those cases again after any material change to the model, routing rules or support platform.
Start with the cases whose paths are understood and inspect early failures with the people who answer the queue. Set thresholds for missing case records, long waits and wrong destinations, then agree who can switch the affected flow back to staff. The retailer can keep automated tracking available while sending disputed deliveries to its investigation team. Expanding to more cases becomes a decision about the evidence the business has, the authority its staff can exercise and the service it can deliver after the assistant hands over.


Comments (0)
No comments yet. Be the first!