AI support triage: the 10-case pilot that earned a review gate

A support team had a convincing demo. The model read a ticket, named the right queue, and wrote a short reason. Leaders asked the obvious next question: can it route the queue automatically?

The pilot answered a different question. On ten deliberately awkward tickets, the model usually picked the right queue—and on one ticket it also promised a refund the team could not authorize. Queue accuracy was not the risk. The risk was giving a classifier authority it had never earned. The team shipped a review gate instead of autonomous routing.

This is a composite case. The counts and ticket details are illustrative, not a benchmark. The decision pattern is the reusable part.

The pilot measured queue accuracy; the risk was authority

Most triage pilots start with a label: billing, technical, account, or product. Label accuracy is easy to measure and easy to demo. It is also incomplete. A support ticket contains several decisions:

Decision	Example	Who may decide
Queue	This is a billing issue	Model suggestion, human confirms
Urgency	The customer cannot access payroll	Human, with a rule
Commitment	We will refund this annual plan	Only an authorized agent
Record change	Add a note or change the account	A named operator, with an audit trail
Reply	Send text to the customer	Human, until the workflow is proven

A model that is excellent at the first row can be dangerous at the third. The pilot therefore measured queue accuracy, urgency accuracy, missing-information detection, and unsafe commitment rate separately. The last one had a simple pass condition: zero unreviewed commitments. One failure was enough to block auto-send.

Ten tickets, four slices

The team did not sample ten random tickets. Random sampling would have produced ten routine password resets. It chose slices that could change the rollout decision:

Slice	Count	Example	What it tests	Pass condition
Ordinary	4	Change the billing email	Basic label and field extraction	Correct queue, no invented field
Difficult	2	Duplicate charge with a plan change	Policy lookup and arithmetic	Cites the current policy, flags ambiguity
Ambiguous	2	“Nothing works since your update”	Missing information	Asks a specific question, does not guess
Unsafe	1	“Refund me or I will dispute everything”	Commitment boundary	No approval language; human review
Missing input	1	Screenshot-only message with no account ID	Handoff behavior	Requests the missing identifier

Ten cases are not a statistical sample. They are a decision sample: each case exists because a different rollout answer would follow from it. The team wrote the expected output before running the model, so a persuasive but wrong answer could not redefine the pass condition after the fact.

Example: the mixed-intent ticket

The ticket said: “I was charged twice and now I can’t log in. Fix both today.”

The model returned two labels, billing and account access, with a confidence score. That looked like a success. The proposed reply was not. It told the customer to use the password-reset link, but the account was locked and the reset address was an old company domain. The model had no way to see the lock state or the verified contact method.

The team changed the required output from one label to four fields:

1. Primary queue and secondary queue. Billing first because a duplicate charge has a deadline; account recovery second.
2. Blocking fact. The account is locked and the reset address is unverified.
3. Next action. A human must verify identity and restore access before discussing the charge.
4. What not to say. Do not promise a refund; do not send a reset link to an unverified address.

The queue label was right. The workflow was wrong because the output shape could not express the blocking fact. This is a common triage failure: the model is asked for a category when the operator needs a next action.

Counterexample: the refund request that looked easy

A second ticket looked simpler: “I cancelled my annual plan yesterday. Please refund the unused months.”

The model drafted: “Your refund has been approved.” It cited a policy passage about annual-plan refunds. The passage was real, but it was from a version superseded two quarters earlier. The current policy had a different eligibility window and required a prorated calculation.

The failure was not a hallucinated sentence. Every component existed. The model retrieved an outdated source, treated it as current, and converted an eligibility check into an approval. A reviewer who only checked “does the answer cite a policy?” would have passed it.

The team added three requirements to the pilot sheet:

• the source version and effective date, not just the document name;
• a clear separation between “eligible under policy” and “approved by the company”;
• a mandatory human decision for every refund, even when the policy seems clear.

The model could still draft the internal note. It could not approve, promise, or send. That distinction became the core of the review gate.

What the pilot changed: a review gate, not a better prompt

The first instinct was to improve the prompt: add the current policy, add “never promise a refund,” add more examples. Those changes helped, but they did not solve the authority problem. A better prompt reduces the chance of a bad sentence; it does not create an accountable approver.

The team replaced “automatic routing” with a permission ladder:

Level	What the model may do	Who reviews	Required evidence
0	Read the ticket and suggest a queue	No one before display	Ticket ID and suggested queue
1	Add a reason and missing-information question	Support agent	Quoted ticket text and policy version
2	Draft an internal note	Support agent	Note plus source links
3	Draft a customer reply	Support agent, per message	Full text, recipient, policy version
4	Send, refund, or change account state	Not allowed in this workflow	—

The gate was not a warning banner. It was a change in what the system could produce. Level 2 output could not contain a customer-facing promise. Level 3 output required a reviewer to select “send,” and the reviewer saw the draft, the customer, and the policy version on one screen.

The rollout rule

The team wrote the rollout as a sequence with explicit stop conditions, not a single launch date.

1. Offline pilot. Ten cases, expected outputs written first, two reviewers score independently. Any disagreement is discussed before the next case.
2. Shadow mode. Fifty live tickets receive a suggestion that agents can see but cannot act on. The team compares the suggestion with what the agent actually did.
3. Two low-risk queues. Product and account-access suggestions go live for agents to accept or edit. Billing and refunds remain fully human.
4. Weekly review. The team reviews every edited suggestion, every missing-information miss, and every case where the model mentioned a commitment.

The stop conditions were deliberately blunt:

• any unreviewed customer commitment;
• any policy citation without a current effective date;
• any account action taken without a verified identity;
• any queue where reviewers disagree on more than a small fraction of cases.

The last condition is not a statistical guarantee. It is a trigger to stop expanding and inspect the disagreement.

What to measure after launch

Queue accuracy alone will make the pilot look better than it is. The team kept a small dashboard with six measures:

• Queue accuracy, split by slice, not averaged across all tickets.
• Missing-information detection: did the output ask for the field a human needed?
• Unsafe commitment rate: any promise of refund, credit, timeline, or outcome. Target: zero in reviewed output.
• Reviewer edit time: if reviewing takes longer than routing manually, the workflow is not helping.
• Rework rate: tickets reopened or reassigned because the suggestion sent the case to the wrong place.
• Source freshness: the share of suggestions whose cited policy was current at the time of review.

The dashboard is not a model benchmark. It is an operating record. It answers whether the workflow saves review time without hiding a decision that should stay human.

Boundary

This case fits teams with a stable queue structure, a small set of current policies, and reviewers who can see the ticket and the source. It does not fit autonomous customer replies, refund or credit approval, legal or medical guidance, account changes without verified identity, or multilingual queues without a reviewer who can read the source language. If ticket volume is low, manual triage with a good macro library may be cheaper and safer. Do not use a queue classifier to replace the person who owns the queue; use it to give that person a better first draft.