What Has to Move When AI Hands a Customer Over

A customer has typed their order number, described the fault, and been sent the article they had already read before they started. The conversation then reaches a person, and the first thing that person types is "can I take your order number". Nothing has been saved. A step has been added, and the customer now has a story to tell about your AI.

That failure is not in the answering. The classification was right, the escalation rule fired as designed, and a human picked it up inside the target time. It failed in the half-second where the conversation crossed between systems and arrived stripped.

Handover is where deployments fail, and it is the part nobody tests

Answering gets tested to exhaustion, because answering is what the demo shows. Handover gets a checkbox marked "escalate to human", for two reasons that compound before the architecture even comes into it.

The standard success metric works against it. Containment counts conversations closed without a person, which frames every handover as a failure rather than a designed path, and nobody engineers the thing their dashboard classifies as a loss.

Handovers also behave differently in production. In testing they happen on straightforward questions, in working hours, on a clean test account. In production they cluster on the messy ones: the angry fourth message, the customer with two accounts, the enquiry arriving at 17:58 on a Friday.

The six things that have to move

Treat the handover as a payload with a specification, not as a notification. This is what a person needs at the moment they take over.

1. The conversation itself, in the record rather than linked from it

The full exchange belongs on the customer's record in the system your team already works in, as part of the thread they are replying to. A link to a transcript in another tool is another login, and in a year it is a dead URL where the context used to be.

2. What was already tried, and what the customer already rejected

The customer said they had restarted it, that the article did not help, and gave the order number. Each is an instruction not to repeat that step, and each is lost by default, because a transcript records what was said rather than what it means for the next action. Carry the steps attempted and their outcomes as structured facts.

3. What is known, separated from what was inferred

The customer typed an order number: that is known. The system matched it to an account, a contract and a delivery address: that is inferred, and it can be wrong. A payload presenting both as plain facts invites a person to act on a guess while believing it was verified.

So mark provenance per field: stated by the customer, read from a record, or worked out, and on what basis.

4. The account context the human needs and the customer should not supply

Contract tier and what it covers. Renewal date and how close it is. Open tickets, and whether this is the third this month about the same thing. Who else at that company has been in touch this week. None of it is a customer's job to provide, and all of it already sits in the CRM. Sending a person to find it while a customer waits is how a two-minute reply becomes a twenty-minute one.

5. Why the handover happened, meaning which rule fired

"Low confidence" is not a reason. "The question asks what a contract clause means, and contract interpretation is restricted" is a reason, and it tells the person what they are being asked to do.

6. What has already been done, and its state

If a ticket was created, say so and give the identifier, or the human creates a second one. If a password reset was triggered or a record updated, that has to be visible before the person acts. Writes need to be idempotent: a retried step must not produce a duplicate contact, a second ticket or a second refund request.

When identity or entitlement is uncertain, it stops

The hardest failure to design for is not a system that does not know the answer. It is one that does not know who it is talking to and proceeds anyway. Two directions of failure, and they are not equally bad. No match is an inconvenience: the customer confirms something, or a person picks it up. A false match is a disclosure, where you tell one person about somebody else's order, invoice or account. Weak identity evidence resolves to no match, never to a probable one.

Entitlement is the same problem one layer along, and easier to miss because identity looks solved. You know who they are, the record is right, and the question is whether their contract covers what they are asking about. If that cannot be established from a source applying to this specific customer, the workflow stops and hands over rather than answering from the general article.

Stopping properly is itself part of the payload. The escalation carries what was matched, what was not, and on what evidence, so the person taking over knows whether they are verifying an identity or picking up a verified one, and what the customer sees is a person rather than an error.

Why a bolt-on chatbot cannot hold this together

A chat layer that runs alongside your CRM, rather than inside it, keeps its own copy of the customer. The cost is not the subscription. It is that at the moment of handover the record the agent worked from and the record the person opens are two different things.

The chatbot's database has the conversation, its own idea of who the person is, and its own status for the issue. The CRM has the contact, the tickets, the deals and the history your team works from. They diverge immediately, because reconciliation runs one way and only for the fields somebody remembered to map. Six months later, a question as basic as how many times this account has complained this quarter has two answers.

Built inside the CRM you already run, the conversation, the record and the escalation are one object rather than three that need synchronising. There is no payload to move across a boundary, because the human opens the record the agent was already working in. That is why our customer service capability for HubSpot customers is designed to start from the record and work outwards, rather than from a chat widget integrating backwards.

What to check before you rely on your platform's handover

If you run HubSpot, its customer agent hands over by reassignment rather than by export: HubSpot documents that when it cannot resolve a query "it'll reassign the conversation to a human agent according to your configured handoff process" (knowledge.hubspot.com, retrieved 16 Aug 2026). It is enough when everything the person needs is already inside HubSpot, meaning content-answerable questions and history held in the CRM. What your own subscription includes is account-specific and changes, so check yours.

Then test the payload rather than the routing, because routing is the easy half. Open a real escalated conversation and read what the person actually received. Is the full thread on the record? Are the attempted steps there as facts? Is inferred data marked as inferred, is the account context assembled, is the rule that fired named, and are prior actions visible with their identifiers? Whatever is missing is not a complaint about the platform. It is the specification for what has to be built around it.

The order status in your ERP, the entitlement in a contract record and the reason an invoice was raised twice are the usual gaps, because an agent answering from your published content never held those facts to hand over. Reaching them is an integration problem, and integration is engineering rather than configuration.

How you would know the handover works

Three measures, all cheap, and the first captures the failure customers actually notice.

• Repeat-information rate. Take twenty handovers and count how often the person asked for something the customer had already supplied.
• Time from handover to first human reply. Measured from the handover, not from the start of the conversation, so you can see whether the escalation path is staffed.
• Reopen rate on handed-over conversations. Rising reopens mean the person resolved it without the context they needed, which points at the payload rather than at the person.

Baseline all three before anything is built. Handover quality is invisible in aggregate reporting and obvious in a sample of twenty.

The next step

Two questions sit behind a handover that works. Which conversations should reach a person at all is a policy decision, set out in when an AI should answer a customer and when it must not. What travels with them when they do is this one. Designing the payload needs your service lead and whoever knows the data model in the room.

That design sits inside the customer success wave of our 12-month AI programme, which brings one department onto AI per quarter, before anything is connected. If you would rather establish the ground first, start with a diagnostic. The AI and Data Readiness Assessment is short, fixed in scope and carries no obligation, and it will show you which records could carry a handover today and which would arrive empty. Where handover sits in a wider plan is covered in the case for taking one department at a time.