How to Set Up Agentforce-to-Human Escalation

Most escalation setups fail in the same quiet way. The agent decides it's stuck, fires the handoff, and a human picks up a conversation that opens with "Hi, how can I help you today?" The customer has now explained their problem twice, and the agent's entire transcript — the question, the records it pulled, the action it almost took — evaporated at the boundary. The routing worked perfectly. The escalation still failed.

That gap is the whole subject of this post. Escalation is not a routing problem. It's a state-transfer problem. Getting the conversation to the right human is the easy 20%. The hard 80% is making sure the human inherits everything the agent knew, so the handoff feels like a relay, not a reset. This is written for the person who has to build it in Agentforce, with enough framing that whoever funds it understands why the cheap version costs more.

Three triggers, and only one of them is 'the agent failed'

Before you wire anything, separate the reasons an agent should escalate, because they need different detection and they route to different places. Teams build one catch-all "if confused, transfer" rule and then wonder why escalations feel random. There are really three distinct classes.

• Capability escalation — the agent can't answer or can't act. It lacks the knowledge, the tool, or the permission. This is the one people build for. It's also the rarest if your agent is scoped well.
• Policy escalation — the agent could answer, but it shouldn't without a human. Refunds over a cap, contract changes, anything with legal or financial weight. This is a deliberate boundary, not a failure, and it should fire even when the agent is fully confident.
• Sentiment escalation — the agent is technically handling it, but the human on the other end is angry, confused, or has asked for a person. The conversation is failing even if the task isn't. This one is about the relationship, not the answer.

Conflating these is why escalation tuning feels like whack-a-mole. A confidence threshold catches capability escalation and completely misses the customer who calmly types "just get me a human" three times. Build a detector for each class. Treat "the customer explicitly asked for a person" as its own hard trigger that overrides everything — arguing with that request is the fastest way to turn a salvageable interaction into a complaint.

Detecting 'stuck' is harder than detecting 'wrong'

The trickiest trigger to build is capability escalation, because a language model's worst habit is answering confidently when it should have stopped. It will not raise its hand. Left alone, it produces a fluent, plausible, wrong answer and reports success. So you cannot rely on the agent to self-report being stuck. You have to instrument the conditions around it.

In practice that means watching signals the model doesn't volunteer: the grounding retrieval returned nothing above its relevance floor, the same topic has re-fired across two or three turns without resolving, an Apex or flow action threw or came back empty, or the user's last two messages trend toward frustration. Any one of those is a better escalation trigger than asking the model "are you confident?" — because the failure you most need to catch is precisely the one the agent is least equipped to notice about itself. Detect stuck from the outside, not from the agent's own optimism.

The handoff carries a contract, not just a transcript

Here's the part the demos skip. When you escalate, dumping the raw transcript into the case is not a handoff — it's homework. You've asked a stressed human to read a wall of chat under SLA pressure and reconstruct what's going on. The good version hands the human a structured contract: a small, predictable package that lets them take over in seconds.

• A summary of intent — what the customer is actually trying to accomplish, in one or two sentences, generated at the moment of handoff.
• What's been verified — identity confirmed, account located, the specific record in question. So the human doesn't re-authenticate or re-ask.
• What the agent already tried — the answers given, the tools called, the action it was blocked from taking. So the human doesn't repeat a path that already failed.
• Why it escalated — which of the three triggers fired, explicitly. "Refund exceeds the policy cap" is a different starting posture than "customer is upset."
• The raw transcript, attached but not foregrounded — available if the human wants to dig, never the thing they have to parse first.

“

The test of an escalation isn't whether it reached a human. It's whether the human's first sentence to the customer proves they already know the story. If they have to ask 'so what's going on?', the handoff lost the only thing worth transferring.

Wiring it in Agentforce without reinventing the routing

The mechanics in Agentforce are more about composing existing platform pieces than building from scratch, and that's the point — escalation routing is a solved problem in Service Cloud and you should not rebuild it inside an agent. Read the current Agentforce and Omni-Channel docs before you wire anything, because the exact action and topic names shift between releases. The shape, though, is stable.

• Give the agent an explicit escalation action or topic — not a vague instruction to 'transfer when needed,' but a defined action with required inputs: the intent summary, the trigger reason, the relevant record IDs. Make the inputs required so the model can't fire a handoff with the context fields blank.
• Let Omni-Channel own the routing decision — skills, queues, availability, capacity. The agent decides that it should escalate; the platform decides who to. Keep those two jobs separate or you'll hard-code routing logic into an agent that can't see who's online.
• Construct the handoff package as a real object — fields on the case or a structured summary written before the transfer fires — so it survives the move and lands in the human's console, not just in a chat log nobody opens.
• Define the fallback when no human is available. After-hours and queue-full are not edge cases; they're Tuesday. Decide deliberately: callback, async case with the same context package, or a clearly-set expectation. An escalation into an empty queue is worse than no escalation, because you raised the customer's hope first.

The principle underneath all four: the agent's job is to recognize the boundary and package the state. The platform's job is to move it to the right person. When you blur that line, you get an agent with brittle routing logic baked in and a routing system that doesn't know why the conversation arrived.

Escalation has a return path, and almost nobody builds it

Teams treat escalation as a one-way door: agent hands to human, done. But the richest interactions are round trips. The human resolves the hard part — approves the exception, makes the judgment call — and the routine follow-up flows back to the agent: send the confirmation, update the record, schedule the next step. If your only path is one-way, every escalation permanently consumes a human for the entire remaining interaction, including the parts the agent could have finished.

You don't have to build the return path on day one. But design the handoff so it's possible later — keep the agent's context alive through the human turn instead of tearing it down at transfer. The teams that get real leverage from agents are the ones where the human handles only the slice that genuinely needs a human, and the agent picks the rest back up. That's the difference between an agent that deflects work and one that merely delays it.

The escalation rate is your most honest agent metric

Once this is live, the escalation rate becomes the single most useful number you have about the agent — far more honest than deflection rate, which can be gamed by an agent that stubbornly refuses to hand off. Watch it as a trend, broken out by trigger type, and it tells you exactly where the agent is weak.

Capability escalations clustering on one topic? That's a knowledge or tool gap with a name and an address — go fix that topic. Policy escalations dominating? Your cap might be too tight, or there's a self-serve flow worth building. Sentiment escalations rising on a flow that used to be calm? Something upstream degraded. A rising escalation rate isn't the agent failing — a flat-lined zero is. Zero means the agent is bluffing through cases it should be handing off, and you're paying for that confidence in churn you can't see. The goal isn't fewer escalations. It's escalations that fire at the right moment, on the right trigger, with the context intact.

Why this is an operating job, not a setup task

You can stand up the routing in an afternoon. Keeping it good is the actual work, and it's continuous. The right escalation thresholds drift as the agent's knowledge grows and the customer's questions change. The handoff package needs the fields humans actually use, which you only learn by watching real escalations. The fallback behavior needs tending as your staffing and hours shift. None of that is a launch task — it's an operating responsibility someone has to own past go-live.

This is the part that's easy to underprice. An escalation system tuned right in March, watched by no one, is quietly mis-firing by June — over-escalating easy cases or, worse, bluffing through hard ones. In our Data-to-Agent method this lives in Agent Care, the named phase after launch, and it's a big reason SkySync ties its fee to the outcome rather than the install. The handoff between agent and human is exactly where the return is won or lost, and it's won by maintenance, not by setup.