All articles
Priya Raman · · AI handoff

Handoff Logic: How AI and Human Agents Share a Queue Without Friction

Queue interface showing AI-resolved tickets and handoff notes passed to human agents

The framing that AI support automation is "replacing human agents" is both common and wrong, at least when the automation is scoped correctly. What a well-designed automated resolution system does is not replace agents -- it changes the composition of the work that reaches them. Instead of a queue that's 65% mechanical lookup-and-action and 35% cases requiring judgment, agents work a queue that's closer to 100% judgment-requiring cases. The agents aren't removed; they're better utilized.

Getting that division right -- which tickets go to automation, which go to humans, and how the handoff happens when a ticket needs to move from one to the other -- is the design work that determines whether "support automation" means "better support outcomes" or "worse customer experience with cheaper labor." This is our current thinking on handoff logic, built from what we learned in our first year of building and operating Replylume.

The Division Principle

The cleanest way to think about AI versus human work in support is to ask two questions for any given ticket: Is the resolution deterministic given the available data? And is the customer in a state where the resolution mechanism matters to them?

When the resolution is deterministic (there's exactly one right answer given the data) and the customer is in a transactional state (they want the outcome, not a relationship interaction), automation is the right resolver. Order status checks, within-policy refunds, subscription confirmation lookups -- these are deterministic and transactional. The customer wants the answer, they want it quickly, and they don't particularly care whether a human or a system provided it. In our beta data, these tickets CSAT-scored higher when resolved by automation in under 30 seconds than when resolved by humans in 4-6 hours overnight.

When the resolution requires judgment (multiple data points don't produce a single obvious answer) or the customer is in a relational state (they're frustrated in a way that requires acknowledgment, or they're a high-value account where the interaction itself matters), humans are the right resolver. Disputed charges where the customer believes the billing system is wrong, account situations involving multiple subscriptions and compounding billing errors, cancellation requests from customers who might be retained -- these require reasoning that doesn't reduce to rules, and the customer experience of being handled by a human who understands nuance matters as much as the resolution outcome.

The Handoff Scenarios

Handoffs between automation and humans happen in four directions, each with different design requirements.

Automation to human on escalation: This is the most common direction. Automation evaluates a ticket, determines it doesn't meet autonomous resolution criteria, and routes it to a human with a context note. The handoff quality requirement here is completeness -- the agent needs to know what the automation checked, what it found, and why it escalated, so they don't repeat work. A good escalation note takes about 15 seconds to read and tells the agent everything they need to know before opening a CRM tab. A poor escalation note says "ticket requires manual review" and provides no context.

Automation to human on discovery: Sometimes automation, while processing a ticket, discovers information that makes the ticket look more complex than the initial classification suggested. A refund request that looks standard until the order lookup reveals three previous refund requests in 60 days from the same customer is a discovery escalation -- the ticket type hasn't changed, but the customer context has. The handoff note for discovery escalations needs to lead with the discovery: what did the automation find that changed the routing decision? The agent needs that information before they read the ticket content.

Human to automation on re-routing: Occasionally, a ticket lands in the human queue that actually should have gone through automation -- usually because the routing rules had a gap, or because the ticket was initially miscategorized. Agents should be able to hand off tickets to the automation layer when they recognize a clearly-automatable case that was mis-routed. This direction is less common but important for the system's efficiency over time: re-routing corrections provide feedback that can be used to improve routing accuracy.

Automation to human on mid-resolution discovery: The rarest and most important handoff type: the automation starts executing a resolution, then discovers mid-execution that something is wrong. The billing system returns unexpected data (a previous charge that shouldn't exist, a subscription state that contradicts the ticket claim). This handoff needs to be clean and immediate -- the automation stops, marks the ticket as needing review, adds a specific note about what was discovered, and routes to a human who can investigate the inconsistency. The design requirement is that the automation never partially executes a resolution and leaves the ticket in an ambiguous state. Either it completes successfully, or it escalates cleanly with the mid-execution state documented.

What the Handoff Note Must Contain

Every handoff note from automation to human should contain five elements: (1) the escalation reason, stated in one sentence that an agent can read in under five seconds; (2) what the automation checked before escalating, so the agent doesn't duplicate the lookup work; (3) the resolution the automation would have taken if it had the authority, so the agent understands the automation's assessment; (4) any customer-context signals that were part of the escalation decision (health score, recent ticket history, CRM flags); and (5) the recommended next action, as a suggestion not a directive.

Teams in our cohort that standardized the five-element handoff note format found that agents resolved escalated tickets 35-40% faster than before, and reopening rates on escalated tickets dropped significantly. The time savings come from eliminating the agent's context-assembly step -- the most time-consuming part of working any complex ticket is understanding what's already been tried and what the data shows. A good handoff note front-loads that work.

When the Human Hands Back to Automation

There's a second type of handoff that doesn't get discussed enough: after a human agent investigates and makes a judgment call, the execution step might still be mechanical. An agent who reviews an out-of-policy refund request and decides to approve it as an exception is making a judgment call that automation couldn't make. But the execution -- issuing the refund, updating the CRM, closing the ticket with a confirmation message -- is mechanical. There's no reason the agent has to do the execution themselves once they've made the decision.

A mature handoff design allows agents to make a decision and pass the execution back to the automation layer. "Approve exception: refund $89 for order #ORD-4421, note exception reason as 'returning customer / first issue in 18 months'" -- the agent makes the decision in 30 seconds, the automation executes in 10 seconds, and the agent is already on the next ticket. This hybrid flow is available in Replylume's escalation design but requires explicit configuration -- teams need to define which execution actions are available for agents to delegate back.

The Long-Term Division

The right division of work between automation and humans isn't static. As the automation handles more tickets over time, the routing rules improve, the escalation thresholds get calibrated, and the human queue composition shifts toward the genuinely complex cases. In parallel, as support teams use the escalation data to understand which tickets consistently require human judgment, they can feed those patterns back into policy decisions that make more cases deterministic -- reducing the judgment-required category over time.

The goal isn't to minimize human involvement. It's to ensure human involvement is applied where it produces the best outcomes -- on the cases where reasoning, empathy, relationship context, and exception authority matter -- and that automation handles the rest so human attention isn't diluted across work that doesn't need it. The handoff logic is the mechanism that keeps those categories properly sorted, and it deserves as much design attention as the automation capability itself.