Chatbot vs Human: The Handover Record at Escalation

Neither one wins outright, and the choice is not made where most buyer's guides put it. In an AI chatbot vs human customer service decision, the factor that decides the outcome is the handover: what the bot passes to the person at the moment it gives up. A bot that resolves 60% of contacts and loses the state on the other 40% has not saved you 60%. It has produced one clean queue and one queue of customers starting again.

Our position is that "which is better" is the wrong unit of analysis. The governed object is the handover record: the transcript, the commitments the bot already made on your company's behalf, whether the customer has to repeat themselves, and whether the human can tell what the bot was told from what it inferred. Get that record wrong and a single bad interaction becomes two.

A person on Hacker News described the failure precisely on 3 March 2026, commenting on the front-page piece "Don't make me talk to your chatbot". After a voice bot, a broken callback subsystem, repeated re-authentication and a text bot, they wrote: "I've just spent 10 minutes talking to a wall and punching in numbers." (comment permalink). They had already given the system their account details, their PIN and their question. None of it survived the transfer. They cancelled the account.

The short answer: Decide the split by what survives the handover, not by what the bot can answer. If the human cannot see the transcript, the promises, the provenance, the auth state, the writes already made and the reason for escalation, the automation is producing rework, not deflection.

Last updated: July 31, 2026.

The handover record: six fields that should cross the escalation line, and the three this article argues are hardest to build.

What a chatbot actually hands a human at escalation

At escalation, a support bot hands over some subset of six things: the conversation transcript, the commitments it made, the provenance of its answers, the customer's authentication state, the actions it already executed, and the reason it escalated. Of the three platforms whose documentation we read for this piece, two state plainly that the transcript crosses by default and the third documents only when the handover fires, not what it carries. None of the three documents commitments or provenance as an object of their own, and the auth state and escalation reason vary by channel and integration. The gap between "the transcript transferred" and "the human can act" is where the hybrid model leaks.

This matters because the escalated contact is, by definition, the hard one. The bot already took the easy volume. What reaches a person is what was ambiguous, angry, novel, or high-value, and it arrives with a history the person did not witness. Every fact the human re-collects is a fact the customer already gave once. The customer does not experience that as a system boundary. They experience it as your company not listening.

The framing this article uses throughout is the handover record: the structured object that crosses the line from bot to person. It is not the transcript. The transcript is one field in it. Treating the transcript as the whole record is, we think, the central design error in support automation. It is a mechanism by which a platform whose documentation promises the full history can still leave a customer repeating themselves. Every chatbot vs human comparison that stops at capability is describing the two tiers and ignoring the seam between them.

So the bot-versus-human debate collapses into a design question you can actually answer: what does the person receive, and is it enough to continue without restarting? That question has a measurable answer, scored against last week's escalations in an afternoon.

The handover record: six fields, one screen

The handover record has six fields. A human agent should be able to see all six before typing the first character of their first reply. If a field requires opening a second system, expect it to go unread during a live chat, and expect the agent to ask the customer instead. That is the exact failure you were trying to prevent.

Field 1 — the transcript, verbatim and complete

The transcript is the raw exchange, in order, including the bot's own opening messages and any silent retries. "Complete" is doing real work in that sentence. Zendesk's documentation on AI agent tickets states that the ticket is created by the first customer message, so "any initial message sent by the AI agent or basic message response (for example, a welcome message) is not included" — and that if the conversation is later escalated, "the conversation history is backfilled and any initial messages are inserted in the ticket upon escalation" (Zendesk help). Read that carefully. The bot's own opening words become part of the durable record because an escalation happened. In a contained conversation they are not in the ticket at all.

That is a reasonable product decision and a poor evidentiary one. If your bot's greeting or first answer contains a commitment, whether a price, an eligibility rule or a window, then in every conversation the bot handles alone that sentence is not in the ticket a future agent, auditor or lawyer will read. This is configurable in most stacks. Check whether you have configured it, because the default is not obvious from the agent's side.

Field 2 — the commitments already made

A commitment is any sentence the bot uttered that a reasonable customer would treat as a promise from your company: a refund, a credit, a delivery date, an eligibility rule, a deadline, a price. This is the field with the highest cost per miss and the lowest chance of being implemented, because none of the three platforms surveyed below documents it as a data type of its own. It has to be extracted.

Field 3 — provenance: told versus inferred

For every substantive claim in the transcript, the human needs to know whether it came from a system of record (order status, account balance, entitlement), from a retrieved knowledge-base article with a version, or from the model's own generation. The three have different reliability and different remediation paths, and they look identical in a chat window.

Field 4 — authentication state

Who has the system verified this person to be, by what method, and at what point in the conversation? If the answer does not cross the boundary, the human either re-verifies, adding friction the customer reads as incompetence, or does not, and acts on an unverified identity. Both are bad. One is a security finding.

Field 5 — actions already taken

Anything the bot wrote to a downstream system: a ticket created, a refund issued, an address changed, a subscription cancelled, an order held. Each one needs a reversibility marker, because a rational response to a confused handover is to do the thing the customer asked for. Where that instinct meets an invisible action log, the result is a duplicate.

Field 6 — the escalation reason

Not whether to escalate. That is a separate design question with its own literature. This field is the record of which trigger fired: the customer asked, a confidence floor was breached, a policy tripwire caught a restricted topic, a loop detector fired after three failed turns, or a sentiment threshold tripped. Without it, the agent cannot tell an angry customer from a confused one from a customer with an unsupported product, and the queue routes on guesswork.

What the major platforms document that they pass

Three widely deployed platforms, chosen here because their handover behaviour is publicly documented, all describe a handover mechanism, and all three document limits worth knowing before you design around them. What follows is what each vendor publishes, fetched on 31 July 2026, not what we measured in a customer environment.

Microsoft's handoff page is the most explicit of the three: "When your agent hands off a conversation, it shares the full history of the conversation and all variables collected in the interaction" (Microsoft Learn, Configure handoff to Dynamics 365 Customer Service). That is field 1 and part of field 5, delivered by default, and genuinely more than a raw transcript paste.

The same page documents something that belongs in field 4 and is easy to miss: "Authentication isn't supported for voice-based handoff to Dynamics 365 Customer Service instances. If you set up authentication for your agent, the authentication variables don't include authentication information when they're sent to your Dynamics 365 Customer Service instance." On the voice channel, in that integration, the vendor states plainly that the auth state does not cross. Whatever your bot verified, the human starts from zero. Run voice and chat on the same platform, assume parity, and you have a gap the documentation already told you about.

Intercom's model is different in an instructive way. Its escalation controls are about when the handover fires, not what it carries: "Escalation Rules trigger a handoff to your team when defined data attributes are detected in a conversation," while "Escalation Guidance lets you describe when and how Fin should escalate based on customer intent or behavior — even when structured data isn't available" (Intercom help). Both are trigger design. Neither is record design. That split runs through all three sets of documentation read here, and it is a plausible explanation for why a team can configure escalation carefully and still ship a thin handover.

If you want to see the mechanics rather than read about them, this walkthrough builds a bot-to-human handoff end to end in Dynamics 365 Customer Service and shows what lands on the agent's screen:

The silent-failure mode: the transfer succeeds, the context does not

The most damaging handover defect is not a failed transfer. It is a successful transfer with an empty payload, because no error reaches the agent and nobody is watching the field that went missing.

Microsoft documents this behaviour explicitly for Copilot Studio in Omnichannel. The integration uses the ACS channel, so "the same channel data message size limit of 28 kb applies", and the docs go on: "This limit can affect scenarios such as transferring to Omnichannel, where you pass all the variables (both local to the topic and agent variables available in the conversation) as context to the agent. If the size of all the variables you pass exceeds the limit, the ACS channel fails with error MessageSizeExceeded, and the transfer completes without the variables being passed" (Microsoft Learn, Quotas and limits).

Sit with that sentence. The transfer completes. The customer lands with a human. The human sees a conversation and no variables. Nothing in the interface says "context was dropped because the payload was 29 KB". So the agent asks the customer to explain the problem, which from the customer's side is indistinguishable from a company that never passed anything at all.

This is a vendor-documented example of a general class: handover state passed on a best-effort channel with a size ceiling and no delivery receipt. Any integration built on message payloads rather than a shared record has some version of it. The mitigation is a check, not clever engineering. Does your agent desktop show, positively, that each of the six fields arrived? An empty field and a missing field look the same under queue pressure, and only one of them is a bug you can fix.

The related failure is the growing conversation. A payload that fits comfortably in testing, with three turns and four variables, is a different object after twenty turns that collected an order history. Payloads are largest exactly when the conversation was hardest, which is exactly when escalation fires. Size ceiling and escalation trigger are correlated, not independent.

Commitments are the field nobody owns

Of the six fields, commitments is the one where the miss is not merely annoying but binding. A chatbot's sentence can create a liability your human agent has to honour, contradict, or escalate, and if the human never sees the sentence they will contradict it by accident.

The settled case on this is Moffatt v. Air Canada, decided by British Columbia's Civil Resolution Tribunal on 14 February 2024. A customer booking a flight after a bereavement asked the airline's website chatbot about bereavement fares. The bot told them to submit the ticket for a reduced rate "within 90 days of the date your ticket was issued". A separate Air Canada webpage — hyperlinked from the bot's own answer — said the policy did not apply after travel was completed. Moffatt followed the bot, applied within the window, and was refused.

Air Canada's defence is the part worth reading. The tribunal recorded that the airline argued it could not be held liable for information provided by its agents, servants or representatives, including a chatbot: "In effect, Air Canada suggests the chatbot is a separate legal entity that is responsible for its own actions. This is a remarkable submission." The member continued that it "should be obvious" that a company is "responsible for all the information on its website", and that "It makes no difference whether the information comes from a static page or a chatbot." The tribunal also noted that the airline had not explained why customers should have to double-check one part of its website against another. Damages were $650.88, with interest and fees bringing the order to $812.02 (Moffatt v. Air Canada, 2024 BCCRT 149).

The award is small. The design lesson is not. Read as an operational document, the decision says three things that bear on the handover record:

1. In that decision, the bot's words were the company's words. As an operating assumption, treat any internal distinction between "what the system said" and "what we said" as one a customer is under no obligation to respect.
2. A hyperlink to the correct policy did not cure the incorrect answer. The bot's answer contained the link to the accurate page. That was not enough.
3. The company's record of what the bot said came from the customer. The screenshot in evidence was Moffatt's. That is the position you are in when field 2 does not exist: the other side has better records of your commitments than you do.

How this reasoning would apply in another jurisdiction, or on slightly different facts, is a question for your counsel. The body of decided cases is still very thin. What is not jurisdiction-specific is the operational point: extract commitments at generation time, attach them to the record, and show them to the human before they reply.

Practically, this is a classifier and a field, not a research project. Every bot turn gets scanned for commitment language: amounts, dates, windows, eligibility statements, "we will", "you can", "within N days". Any hit is written to a commitments array with the exact sentence, the turn index and the source, and the agent's first screen shows that array above the transcript rather than buried in it. If the array is empty, say so on screen, because "no commitments detected" and "commitments not checked" are different states.

Told versus inferred: the provenance problem

A human agent reading a bot transcript cannot tell, from the text alone, whether an answer came from your order database, from a knowledge-base article written in 2023, or from the model producing a plausible sentence. All three read as confident prose, and the remediation for each is different, so picking wrong wastes the contact.

The Consumer Financial Protection Bureau made the underlying point in its June 2023 issue spotlight on chatbots in consumer finance, noting that for chatbots trained on large language models "the underlying statistical methods are not well-positioned to distinguish between factually correct and incorrect data" (CFPB, Chatbots in consumer finance, 6 June 2023). If the generating system cannot make that distinction internally, the transcript it produces certainly does not carry it — unless you attach it.

Three provenance classes are enough for a working record:

Attaching this costs almost nothing at generation time and is nearly impossible to reconstruct afterwards. If your retrieval layer already returns article IDs, the plumbing is a field on each turn.

Why this belongs in the handover record rather than a general quality programme is timing. Quality review happens days later, against a sample. The agent needs provenance in the first ten seconds of a live conversation, while the customer is quoting the bot back at them. Our earlier analysis of AI observability and audit trails makes the same argument at the infrastructure layer: a record assembled after the fact is a reconstruction, and reconstructions do not survive being challenged.

The Ten-Handover Read: a diagnostic you can run in one sitting

Here is the whole diagnostic. Pull the last ten escalated conversations. Score the six fields present or absent, then count two numbers: facts the customer restated that they had already given the bot, and bot commitments the human agent never saw. An afternoon, no tooling, no vendor call.

We have not run this against a client environment. The procedure below is derived from the vendor documentation quoted above and the failure modes in the public record, not from a measured engagement, so treat the thresholds as starting points to argue with rather than benchmarks.

Step 1 — Sample. Ten escalations from the last full week, taken in order rather than picked. A cherry-picked sample over-represents conversations someone already looked at.

Step 2 — Score the six fields. Mark each field Present, Partial or Absent from the agent's view, not the admin's. Open the agent desktop, not the API. A field that needs a click into a second system is Partial at best.

Step 3 — Count restated facts. Read the first three customer turns after the handover. Count every distinct fact the customer supplies that already appears in the bot transcript: order number, account identifier, the nature of the problem, dates, what they already tried. This is the repeat count. It is the most honest single number in support automation, because the customer produces it involuntarily.

Step 4 — Count unseen commitments. Read the bot's turns. Flag every sentence a reasonable customer would treat as a promise. Then check whether that sentence was visible anywhere in the agent's first screen. Anything promised but not visible is an unseen commitment.

Step 5 — Read the two numbers together.

The Ten-Handover Read, end to end: five steps producing two numbers, and what each combination tells you to fix first.

The fourth row is the one that changes decisions. A repeat count of four or more alongside a healthy containment rate means the automated tier is producing rework the reporting does not show. That is the same class of measurement error we described in why deflection is not resolution, approached from the other end: that analysis reads the metric, this one reads ten conversations.

A worked example, assembled from the documented failure modes rather than a client. A billing bot on a voice channel authenticates a caller by account number and PIN, answers two questions from the account record, gives a third answer generated without a source, and escalates on a loop detector after the caller repeats themselves twice. On the documented Copilot Studio voice path, the auth state does not accompany the transfer. So the human re-verifies. Restated facts: account number, PIN, and the problem statement, because the transcript arrived but the reason for escalation did not, leaving the agent to open with "how can I help?" Repeat count for that single conversation: three. Unseen commitments: zero, because the bot happened not to promise anything. On the table above that lands in the 2-3 band with zero unseen commitments, and the worked detail tells you which sub-case it is: not a layout problem but two fields that never crossed, so the fix is field 4 and field 6, not more model training. Run this ten times and the pattern names its own remediation.

Four handover postures, scored

Four postures cover essentially every deployment, and choosing between them is the real chatbot vs human agent decision. They are not maturity stages: a mature team may deliberately pick the first for one contact reason and the fourth for another. What is not defensible is not knowing which one you have.

The four postures scored field by field: filled means the field reliably reaches the agent's first screen.

Posture A — Restart

The bot ends the conversation and the customer is placed in a normal queue, by a different channel or a new session. Nothing crosses. The human starts from "how can I help?"

• Best for: very short bot interactions with no data collection: a routing menu, a store-hours answer, an opening triage question.
• Cost to build: none. This is what you have if you built nothing.
• What it loses: everything. Fields 1 through 6 are all absent.
• Expected repeat count: equal to the number of facts the customer gave the bot.
• Verdict: Honest and cheap when the bot turn was genuinely trivial. Indefensible the moment the bot collected an identifier or gave an answer.

Posture B — Raw transcript

The full chat log is attached to the ticket or shown in the agent's panel. This is the default in most helpdesk integrations and it is a real improvement over Posture A.

• Best for: text channels with short conversations and a low commitment surface.
• Cost to build: usually a configuration setting.
• What it loses: fields 2, 3, 4 and 6. Field 5 only if writes happen to appear as visible bot messages.
• Expected repeat count: low if the agent reads the transcript, high if the queue is busy. A twenty-turn log is not readable in the seconds an agent has before the customer expects a reply.
• Verdict: The right floor, and a poor ceiling. Its failure mode is that everything needed is technically present and practically unread.

Posture C — Bot-written summary

The model writes a summary of its own conversation, which the human reads instead of the transcript. It demos well, and it is increasingly offered as a built-in option.

• Best for: long conversations where the transcript is unreadable at speed, and the summary sits beside it rather than replacing it.
• Cost to build: low; often a toggle.
• What it loses: anything, silently. A summary is the bot's own account of what it did, produced by the same system whose reliability is in question. The commitment the bot should not have made is exactly the sentence a summary is likeliest to smooth over, because summarisers compress toward the typical case.
• Expected repeat count: low, which is what makes it dangerous. The number that would have warned you improves while the risk gets worse.
• Verdict: Useful as an index, unsafe as a substitute. Never let the summary be the only artefact the agent sees, and never let it be the artefact the audit reads.

Posture D — Structured handover record

All six fields cross as data, rendered on the agent's first screen: transcript, extracted commitments, per-turn provenance, auth state, executed actions with reversibility, escalation reason.

• Best for: any contact reason where the bot can make a commitment, touch money, or act on an identity.
• Cost to build: the highest of the four, and most of it is not model work. It is a commitment extractor, a provenance field on each turn, an auth-state passthrough, an action log, and desktop layout work so an agent under pressure actually reads it.
• What it loses: nothing structurally. It can still fail on delivery, as the 28 KB ceiling shows, which is why it needs a positive per-field arrival indicator.
• The real constraint: most agent desktops are vendor-controlled, and what you can lay out on the first screen ranges from an app framework to a single custom-field panel. Where layout is fixed, the achievable version is fewer fields rendered well, commitments and auth state above the fold and the rest a click away, rather than six crammed into a sidebar nobody reads.
• Expected repeat count: near zero when it works, and when it does not work you can see which field failed.
• Verdict: The only posture that lets you honestly say the hybrid model is working, and the only one where a failure is diagnosable rather than anecdotal.

Choose which: an explicit decision path

Run the contact reason through this, not the company. Different queues should end up on different postures. A team that applied one posture uniformly has usually not made a decision at all.

• Can the bot say anything a customer would treat as a promise? If yes, you need at least Posture D for field 2. Prices, eligibility, timelines and windows all count. This is the branch Moffatt speaks to directly.
• Can the bot write to a downstream system? If yes, Posture D for field 5. Without an action log the human's default repair — do the thing again — creates the duplicate.
• Does the bot authenticate the customer? If yes, Posture D for field 4, and verify on your actual channel rather than assuming, because at least one major platform documents that auth state does not cross on voice.
• Is the conversation typically over ten turns? If yes, Posture C plus B — summary as an index, transcript beneath it. Never C alone.
• Is the conversation under four turns, read-only, and identifier-free? Posture A or B is defensible and cheap. Do not build a record for a store-hours bot.
• Unsure which of these applies? Run the Ten-Handover Read first. It takes an afternoon, and it names the branch you are actually on rather than the one the design document claims.

What a lost handover costs, and who pays

A lost handover has four cost lines, and only one of them appears in a support budget.

The second line ends relationships, and it is invisible to the systems that measure support. The commenter quoted at the top of this piece did not file a complaint. They cancelled. The company's reporting will show a resolved billing contact and a churn event, with nothing connecting them.

The CFPB's issue spotlight documents the same shape at scale. It describes conversations that lead customers "in continuous loops of repetitive, unhelpful jargon or legalese without an offramp to a human customer service representative", calls these "doom loops", and reproduces complaints from the Bureau's public database, including one consumer who "ran into loop after loop of the same questions". The report records that each of the ten largest US commercial banks had deployed chatbots in customer service, and estimates roughly 37% of the US population interacted with a bank's chatbot in 2022.

The third line is where a small technical omission becomes an unbounded one. Air Canada's exposure in the decided case was $812.02. The exposure of the policy, one chatbot answering a common eligibility question wrongly at volume with no record of what it said, is that sentence multiplied by every customer who read it.

Where transcript custody ends and the handover begins

These are two different governance questions and they are routinely merged, which leaves both half-answered.

Custody asks who holds the transcript, where it lives, how long it is retained, which vendor and sub-processor can read it, and what happens when the contract ends. That is a data-protection and vendor-management question, and the subject of our separate analysis of who keeps the transcript in a conversational AI platform.

Handover asks something narrower and more immediate. At the single moment of escalation, what moves from the automated tier to the person, and is it enough to continue? A stack can have flawless custody, with a negotiated zero-retention posture, transcripts in your own tenant and a clean deletion path, and still hand the agent nothing but a name. A leaky custody posture, meanwhile, does not stop a well-built handover record from working. It just means more parties can read it.

The practical distinction: custody is about the transcript's life, handover about its crossing. Custody failures show up in a security review. Handover failures show up in the next few seconds, in front of the customer.

A third, adjacent question is out of scope here: the handover in the other direction, from a human to an AI assistant at setup time, which we treated in the five-page handover. The direction changes the artefact completely. That one is a briefing pack you author once; this one is a record the system produces on every escalation.

Six ways handover design fails in the first month

Two of these are grounded in vendor documentation quoted earlier; the other four are reasoned predictions rather than observations, and are marked as such. Read the section as a pre-mortem, not as findings.

1. The transcript is present and unreadable. (Predicted.) Twenty turns of bot chat in a scrolling panel is technically full context and practically nothing. If an agent under queue pressure reads only the most recent turns, a commitment made at turn four is invisible. The fix is layout and extraction, not more data.

2. The summary quietly becomes the only artefact. (Predicted.) A summary panel gets added beside the transcript, it is faster to read, and the transcript stops being opened. Nothing is configured to cause this; it is what tends to happen when one panel is easier than another. The audit trail is then a model's paraphrase of itself.

3. The payload silently truncates. The 28 KB ceiling above is one documented instance of a general pattern: variables passed as a message payload, a size cap, no delivery receipt. It passes testing, because test conversations are short.

4. Auth state is assumed to cross because it crosses on the other channel. Chat and voice are different integrations with different capabilities on the same platform, and at least one vendor documents the gap in plain language.

5. Actions are logged where the agent cannot see them. (Predicted.) The bot's writes land in an audit log, an API history or a separate admin view. All are real records, and none of them is necessarily on the agent's screen during a live conversation, so the agent repeats the action.

6. The escalation reason is a routing tag, not a record. (Predicted.) It is easy to set a queue tag on escalation and consider field 6 done. A tag routes the conversation; it does not tell the agent that this customer already failed three attempts at the same question. Those are different pieces of information and only one of them changes the opening sentence.

When the plain restart is still the right call

Posture A has a real constituency and it is not only the unmodernised. There are cases where building a handover record is the wrong investment:

• The bot turn was genuinely trivial. A menu that routes on "billing or delivery?" collected no facts worth carrying. Building a six-field record around it is ceremony.
• Re-verification is required anyway. Some regulated flows require the human to verify identity independently regardless of what the automated tier did. Passing the fact of prior verification may help routing, but the friction the customer feels is not removable.
• The escalation is a channel change with a natural break. A chat that becomes tomorrow's scheduled callback has a gap the customer already expects. The transcript still matters; the live-continuity pressure does not.
• Volume does not justify it. A queue of eight escalations a week needs an agent who reads the transcript, not extraction infrastructure.
• The honest alternative is not automating that contact reason. Sometimes the read's finding is not "build a better handover" but "this contact reason should not be in the automated tier". Which contacts belong there is the subject of the read-say-do ladder, and it is a cheaper fix than any of the six fields.

The general principle: the record earns its cost where the bot can commit, act, or authenticate. Where it can only read aloud, a transcript is enough.

Where LeapForce fits, and where it does not

LeapForce is not a contact-centre platform. It does not render your agent desktop, own your ticket, or write the handover record into Zendesk. The six fields above have to be built in the support stack you already run, and no governance layer substitutes for that.

What the layer underneath owns is the part of the record concerning the AI itself. Every model call through the AI Gateway is attributed to user, team, tool, agent, model and cost, so what the automated tier did is recorded at execution rather than reconstructed later. That is field 3's provenance problem seen from the infrastructure side. Observability and audit covers tracing and a tamper-evident action record, including what was refused, not only what ran; the site states that Leapforce is in active development and that per-capability build status is disclosed on request, so ask which of those capabilities is live before you plan around them. Workflows carry human approval gates as first-class steps: field 5's idea applied before an action rather than after. Our published rollout model for the gateway is deliberately unglamorous, and it maps onto handover work without much translation: Observe first. Enforce second. Optimize third. Run the Ten-Handover Read before configuring anything, fix the fields the read names, then tune once the record is complete.

Where this analysis is uncertain

Several things in this piece are weaker than they look, and it is better to say so.

• We have not run the Ten-Handover Read in a production support environment. It is constructed from vendor documentation and public failure reports. The thresholds in the scoring table are reasoned starting points, not measured benchmarks, and the first team to run it properly should expect to move them.
• The vendor behaviour cited is documentation, not testing. Microsoft, Zendesk and Intercom describe what their products do. We fetched those pages on 31 July 2026 and quoted them; we did not build the integrations and watch the payloads. Documentation drifts from behaviour in both directions.
• The legal ground is thin and jurisdiction-bound. Moffatt is one small-claims tribunal decision in British Columbia. It is settled, and it is quoted here from the primary decision, but it is not a body of law. How similar reasoning lands elsewhere, on different facts, is a question for counsel. We are not answering it, and any article that does should be read sceptically.
• We could not reach some sources a reader would expect. CanLII, the usual public route to Canadian case text, blocked automated fetching on every tier we tried, so the decision here is quoted from the tribunal's own published document. Gartner and similar analyst material sits behind access controls we did not attempt to bypass, so no analyst estimates appear in this piece.
• The six fields are a design proposal, not a standard. No published specification defines a handover record for AI support. If one emerges, from a vendor consortium or a regulator, it may cut the object differently.
• Escalation trigger design is out of scope here on purpose. When to escalate, what refund authority to grant, and how many automated conversations one supervisor can oversee are separate decisions with their own literature. This article assumes the escalation happens and asks only what crosses.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.