Writing a Humane Handoff Note When a Model Routes a Ticket

Start the note with the condition that fired. "Billing" is a label. "Refund request over the agent's approval limit" is a rule, and the difference tells the agent what the model actually detected.

Rules and models are not the same tool. A rule-based classifier requires specific keywords or phrases to map input to an intent, while a machine-learned model is trained on examples of input and the intent they correspond to, as this overview of intent classification approaches explains. Production systems usually mix both. The note should say which one fired, because the two fail in different ways. Rules break when a customer uses unexpected wording. Models break less obviously, on the long tail of inputs that resemble the training data but mean something else.

Write the matched rule as a named, numbered condition, plus the values that satisfied it:

matched_rule: R-114 "Refund over approval limit"
  condition: intent=refund AND amount > agent_limit
  observed: intent=refund (from classifier), amount=$412.00 (parsed from body)

Two details matter here. First, record the rule identifier so the note can be audited against the rule set that was live at the time. Second, show the observed values that triggered it, including where each came from. An amount parsed from the message body is a different fact from an amount read from the order record, and the agent needs to know which one they are looking at. Structured outputs make extraction easy, but the fields are still a model's claim. Teams that score those outputs find that flagging the 1 to 5 percent of cases where the model is untrustworthy lets the other 95 to 99 percent proceed automatically, per this benchmark of trust scoring for structured outputs. The same logic applies at handoff: name the field, name its source, and let the agent spot-check the ones that decide money or access.

The second line of the packet is the model's own view: the label it chose, the score it attached, and the score of the runner-up. A confidence score compresses uncertainty into one number, which makes it useful for ranking and dangerous when it becomes the only gate, as this piece on confidence scores in AI routing argues. Two tickets can both score 0.94 and only one be fit for automation.

Three practical rules make the score meaningful to a human reader.

Show a margin, not a single number. A 0.82 top label with a 0.79 second choice is a coin flip dressed up as a decision. A 0.82 with a 0.31 runner-up is a different situation entirely, and the agent can see that in one glance.

Say what the score is a score of. A probability from a fine-tuned classifier, a self-reported number from a generative model, and a trust score computed by a separate checker are three different quantities. Do not print them in the same field. Label the source.

Carry the gate that applied. If the handoff fired because the score fell below a threshold, say so and give the threshold. If it fired because a rule overrode a high score, say that instead. The agent's first question is always "was this a confidence problem or a policy problem," and the note should answer it before they ask.

A worked example helps. Suppose the threshold for automatic reply is 0.85. A ticket arrives with a top label of "password reset" at 0.71 and a runner-up of "account locked" at 0.66. The handoff note says: below threshold, margin 0.05, no rule fired. The agent opens with the knowledge that the two most likely causes are nearly tied, and checks whether the customer can still log in at all. That one question separates the two candidates. Without the margin, the agent would have started by drafting a reset link.

This is the part most routing packets omit, and it is the part that decides whether the agent trusts the label.

List the material the model retrieved or was given, with enough identity that a person can open it: the knowledge base article and section, the order or account record, the earlier ticket in the thread. Quote the sentence or field that carried the signal. If the model grounded its label in a retrieval step, show the chunk, not just the document name.

The evidence list is also where you record what is absent. The ticket data classification question usually starts with raw text, and the informative part of a note is often what the model could not find, as the discussion around classifying raw support ticket descriptions makes clear. An order lookup that returned nothing is evidence. A customer record with no prior tickets is evidence. Write "missing" explicitly rather than leaving a blank the agent may read as zero.

A useful structure is four lines, the same shape used in good tier escalations:

• Confirmed: the facts the model had and that check out (reproduced, matched a record, quoted source).
• Assumed: what the model inferred without direct support (intent, urgency, cause).
• Missing: what was looked for and not found (order record, prior ticket, attachment).
• Conflicting: signals from different parts of the message that point different ways.

The distinction between confirmed and assumed is the whole point. It is what lets the receiving person spend their attention on the thin parts instead of re-reading everything. Automated email response systems already separate the path where the intent matches the knowledge base from the path where it goes to the support team for a manual reply, which is the same split expressed as a pipeline rather than a note, as described in this write-up of automated email response with classification and entity detection. The note gives the human the classifier's side of that split.

One caution on structured outputs: a schema-valid extraction is not a correct one. Practitioners have described prompting for the fields without the structured output mechanism, then falling back to constrained decoding only when the free-form result fails the schema, because constrained generation can reduce extraction quality on some inputs, as discussed in this thread on structured outputs and false confidence. Whatever the mechanism, the packet should carry the fields as claims, with the source passages next to them. That way the agent can verify the two fields that matter rather than trusting the whole object.

End the packet with a single recommended action, written as an instruction a person can accept, edit, or reject. "Customer requests refund of $412 on order 88214; recommend verifying the order amount against the record and approving or declining within the 24 hour window."

Three properties make the recommendation usable. It is specific: it names the record, the amount, and the decision. It is bounded: it says what to check, not just what to do. And it is reversible in the sense the agent needs, a decision they can make and record, not a sequence of irreversible steps they must complete.

The recommendation should also state what happens if the agent rejects it. Where does the ticket go, and who is told? Cross-team handoffs fail because "passed to billing" names a group, and a group cannot own a ticket; the transfer needs a named person or an explicit rotating role, a date by which something happens, and a defined path back, per the handoff checklist. A model route has the same requirement. The packet should name the fallback queue and the person or role that receives a rejected recommendation.

There is a decision rule underneath the recommendation, and it is worth stating in the note so the agent understands the model's posture. The two questions that place a human gate are reversibility (how hard is this to undo) and blast radius (how many people or how many dollars does it touch), and the four combinations sort almost any step into autonomous, monitored, confidence-gated, or always gated, as laid out in this guide to human in the loop design. A refund of $412 to one account is low reversibility, low blast radius: gate by confidence and escalate when the model is unsure, which is exactly what happened here. Saying so in the note helps the agent see why the work landed with them.

Routing without context forces every handoff to rebuild the full picture from scratch, and effective routing does the opposite by carrying the history, urgency, and intent forward so the next owner can act immediately, as ticket handling best practices describe. Extending the service level agreement across the whole lifecycle, not just the first reply, is the measurement that keeps this honest.

Two numbers do most of the work. Time to first action measures whether the packet let the agent start without reading everything. Re-open rate after handoff measures whether the recommendation and evidence held up. Both are behaviors of the packet, not of the agent.

Keep the note short. A three screen packet that gets read beats a ten screen packet that gets skimmed, and the same advice that applies to human shift notes applies to model output: write the facts while they are live, record negative findings explicitly, and flag anything with a clock on it, per support shift handoff practice. A machine writes its note at the moment of routing, when the context is as live as it will ever be. There is no excuse for a thin packet.

If you are building this pipeline and want one key across text, embedding, and classification models so the note generator and the router share a provider, Quanta Inference gives you that with an OpenAI-compatible interface at https://quantaintelligence.ai/inference.

Put the four components in a fixed order so agents learn where to look. This plain-text block works in any helpdesk internal note field.

HANDOFF PACKET
rule: R-114 "Refund over approval limit" (fired)
label: refund_request  conf=0.71  runner_up=account_locked 0.66  gate=below_threshold(0.85)

evidence:
  confirmed: order 88214, amount $412.00, source=order record
  confirmed: customer used the word "refund" twice, source=message body
  assumed: purchase was within 30 day window
  missing: prior contact history, attachment mentioned but not found
  conflicting: none

next action: verify amount against order record, then approve or decline
  within 24 hours. If declining, route to billing-queue and name an owner.

Run the template against your last twenty routed tickets before changing anything else. Count how many of the four components were already present somewhere in the thread. The gap is the size of the problem, and it is usually larger than the team expects.