The forward lands at 18:40 with "FYI, can you take this one?" and forty-one messages stacked underneath it, oldest at the bottom. The new owner reads upward through two people who have left the account and a subject line that changed twice. Forty minutes later they have a rough picture. Then they open a reply and type the sentence that undoes all of it: "so I can get up to speed, could you walk me through what happened?"
That sentence is the escalation. Not the outage, not the billing error — the moment a customer who has already explained this twice is asked to do it a third time. It tells them their history with you is not stored anywhere. It lives in whichever human happens to be holding it.
A forwarded chain loses the same three things every time
A chain is a transcript, and a transcript is written for people who were already there. Read from the bottom, three things are missing no matter how carefully you go.
What the customer wants now. The thread records what they wanted on day one in great detail. The want has usually moved since — from "fix it" to "fix it and tell me why it happened" to "fix it, tell me why, and give me something to send my own client." Nothing marks the change.
What has been promised. Commitments hide in the middle of long de-escalating replies. "We'll have someone look at this today" is a promise the customer is counting. In a chain it looks exactly like the sentences either side of it, and it appears in no tracker.
What has already been tried. The failed attempts are the most expensive information in the thread and the least legible, because they read as history rather than as evidence. Nobody rereads them, so somebody repeats them.
Asking the customer is the fastest way to recover all three. It is also billing them for your filing problem.
Three facts, above the chain
Write these before the forwarded history, not after it. The chain can stay attached for anyone who wants detail; the point is that nobody needs it to act.
What they want. One sentence, present tense, in outcome terms. "A credit for the March overage and a written explanation of the cause" — not "customer is unhappy about billing."
What has been promised. A list, each item with who promised it and when. Include the soft ones, especially "we'll come back to you by end of week," because the customer counts those as firmly as the formal ones. This is the section people leave out because writing it is uncomfortable, and it is the section the new owner needs first — their next message either keeps a promise or breaks one.
What has been tried. Each attempt with its outcome and what it eliminated. Three lines is usually enough. If an attempt ruled nothing out, say so; that is still worth knowing, and it stops the next person spending a day on it.
Separate what the customer said from what you concluded
The most damaging line in a handoff is a conclusion that became a fact by being typed. "Customer is threatening to churn." Did they say that? Or did they write "we're reviewing our options for next quarter," and somebody reasonable turned it into churn risk over coffee?
Both are worth passing on, and the new owner will behave differently depending on which happened. Once the conclusion is in the summary, the sentence underneath it is unrecoverable without rereading forty-one messages — the exact work the summary existed to prevent.
So split them physically. One block of what the customer said or wrote. One block of what the account team concluded, each conclusion sitting next to the observation it came from. Some conclusions do not survive being written that way, which is the point.
This is the same distinction provenance applies to AI-drafted text, moved up one level — not who typed the sentence, but who is answerable for the claim inside it. The failure is identical either way: a plausible sentence acquiring authority nobody granted it.
Keep the customer's own words
Paraphrase is lossy in one direction. It keeps the summariser's read and drops the customer's framing.
"They're frustrated with the delays" is a paraphrase. "This is the third date we've given our own client" is what they wrote, and it carries something the paraphrase does not — that the customer has an audience of their own. That is usually the real engine of an escalation, and usually the part you can actually address, by giving them something to forward.
Two or three quoted lines is plenty. Choose them for load-bearing content rather than for heat: the sentence stating the request, and the sentence stating any date they committed to.
Name the open decision and who owns it now
A handoff without a named decision produces a new owner who monitors instead of acting. Close with the decision that is genuinely open, the options, your read, and the fact that it now belongs to the person reading.
"Open — whether we issue the March credit before root cause is confirmed. I have been holding it pending engineering. It is yours from now; I would issue it."
The ownership sentence is the one that gets skipped. "Let me know if you need anything" transfers the work and keeps the authority, which is how an escalation ends up with two owners and no decisions. Withholding your recommendation wastes the only real advantage you have over the new owner, which is having been there.
Where the format helps, and where it stops
RelayLink carries a handoff as a structured briefing between two assistants rather than as a chain. The relevant fields are the ask with a response shape of decision, an urgency of none, when convenient, this week or today, a TL;DR, the context brief, open questions as their own field, and decisions carrying a confidence of low, medium or high plus a reversible flag. After you send it, thread_status reports whether the latest package has been seen — the literal words are "they have seen it" or "not seen yet" — which is deliberately a weaker claim than "they read it."
Two limits matter here, and both are real.
Quoted lines go in an excerpts field capped at three, and that field attributes to exactly two speakers — the sender and the sender's AI. It renders as quotes selected by the sender's AI and can never carry the verbatim label, because the server has no way to check what the drafting model put there. So a customer sentence carried in an excerpt arrives as something you quoted, which is what it is. Nothing in the product attests third-party authorship. Put the customer's exact wording in quotation marks inside the brief with the source and date attached, and treat it the way any paper trail treats a quotation.
The bigger limit for escalations is that a thread has exactly two participants. No cc, no group thread, no multi-recipient send, and no attachments — a package is text fields. An escalation involving an account manager, a support lead and an engineer is either several threads or a channel where all three already are. This shape fits the handoff itself, one owner to the next, and not the crowd around it.
What a good handoff does not do
It does not make the customer less angry, and it does not shorten the fix. It removes one specific insult — being asked to start over — and one specific risk, the new owner breaking a promise they never saw. Everything else is still the work.
It has one uncomfortable side effect worth naming. Writing the promises down in one list occasionally reveals that more was committed than anyone intended. That is better discovered at handoff than by a customer holding you to all of it.
Handing off a project is the calmer version of the same problem, and most of the moves are shared. If there is an escalation sitting in your queue right now, connect your assistant and have it assemble the promise list while you decide what the open decision actually is.