Designing the Human Handoff for a Support Agent: Context, Routing, Timing
When teams evaluate a support agent, they usually look at one number: how many tickets it resolves on its own. I get why. But in the rollouts I've worked on, the cases the agent hands to a person shap
Responses
Markdown supported · ⌘↵ to post
Treating the handoff as a structured object instead of a free-text note is the right call, and the two fields you singled out are the ones I would keep too. A fixed list of stop reasons makes routing testable, and confidence_notes keeps the agent's doubts from disappearing between the bot and the person who picks up the case.
Keeping the routing map in config and not in the prompt is a good split. The model decides which stop reason applies and the system decides where the case goes, so you can change queues without retesting the agent.
The failed handoff test is the one most teams skip. On support agent builds at Ascendra Ventures we include it in the acceptance checks: if the target queue is down, the case has to land in a default queue and someone gets alerted. "The case disappeared" is not something you want to discover from a customer.
On rework rate, how do you measure it in practice? Is it tagged by the person who picks up the case, or inferred from the conversation?