Case classification rules for routing approval

Use a sample of misrouted tickets to produce a routing-rules sheet that an operations lead can approve, test and maintain. This method is for queue owners who need clearer boundaries between teams, not another list of vague ticket labels.

The sheet records the evidence for each rule, the queue that owns it, and the cases that must be escalated for a human decision. You use the model to organise and challenge the evidence. You retain ownership of the routing decision.

1. Assemble one review pack

Create a working folder with three inputs. Use recent tickets that were moved after initial routing, rather than tickets that happened to arrive in the right queue.

1. Export a misrouted-ticket sample. Include the ticket ID, initial queue, final queue, move reason, subject, first customer message, relevant custom fields, tags and resolution note. Remove personal data that is not needed for routing review.
2. Copy the current queue definitions into a plain document. Include each queue's purpose, exclusions, service target and any existing priority rules.
3. Add ownership notes from team leads. Ask for the work each team accepts, declines and escalates. Require examples for disputed boundaries.
4. Set a review period and write it at the top of the pack. Do not mix a historic sample with rules that reflect a newly changed product or support policy.

Keep the source items identifiable. A proposed rule without ticket IDs or an ownership note behind it will be difficult to approve.

2. Make the model classify the failures

Give the model the three documents and state that it must not invent queues, product behaviour or ownership. Ask it first to group the misroutes by the reason the initial route failed.

Use a prompt in this form:

Review the attached misrouted-ticket sample, queue definitions and ownership notes.

Group tickets by the reason their initial routing failed. For each group, provide:
- ticket IDs
- the evidence in the ticket that should determine routing
- the initial and final queue
- the likely classification conflict or missing rule
- any conflict between the final queue and the ownership notes

Use only the supplied material. If evidence is missing, write "insufficient evidence". Do not propose a routing rule yet.

Read the groups before asking for rules. Combine duplicate groups only where the deciding evidence is genuinely the same. For example, “billing query” and “refund request” may sound related but can require different owners when one needs invoice explanation and the other needs a payment reversal.

If the model's file handling or document formats affect your workflow, check the current guidance in the xAI documentation overview. Available behaviour is version-dependent.

3. Turn failure groups into testable rules

For each failure group, ask the model to draft a rule in a fixed structure. A queue name is not a rule. “Send account problems to Account Support” leaves the agent to guess what counts as an account problem.

Use this routing-rules sheet structure:

Field	What to record	Example form
Rule ID	Stable identifier for review and change history	RT-014
Trigger evidence	Facts that must be present	Customer asks to cancel a paid subscription
Route to	Named destination queue	Retention
Exclusions	Similar cases owned elsewhere	Trial cancellation, fraud report
Required fields	Data needed before routing	Subscription status, payment method
Escalate when	Conditions that prevent normal routing	Account access is blocked and renewal is due
Evidence	Source ticket IDs and ownership note	CS-1842, Retention note 3
Owner	Team accountable for the rule	Retention queue owner

Then use this prompt:

Draft a routing-rules sheet from the failure groups.

For every rule, use the fields in the supplied sheet structure. Make the trigger evidence observable from ticket content or required fields. State exclusions and escalation conditions explicitly. Cite ticket IDs and ownership notes for each rule.

Separate: proposed rules, unresolved ownership conflicts, and cases needing a new queue or process. Do not assign ownership where the notes conflict.

4. Check where the draft is wrong

Treat every proposed rule as a claim that can fail. Sample tickets from both sides of the boundary: tickets the target queue should receive, and similar tickets it should reject. Also include tickets with sparse information, because they expose rules that depend on details agents rarely have.

Use the following checks before approval:

1. Pick three to five source tickets cited by each rule. Confirm that the stated trigger is actually visible in the original ticket or its allowed fields.
2. Find near-miss tickets from neighbouring queues. Check that the exclusions send them somewhere specific, or escalate them, rather than leaving them unclassified.
3. Read the rule without its evidence column. If two experienced agents could apply it differently, replace broad terms such as “technical”, “urgent” or “complex” with observable conditions.
4. Compare the destination with the ownership notes. Any mismatch is an approval question, not a wording edit.
5. Count rules that rely on a field agents do not routinely complete. Either make that field mandatory in the workflow or remove it as a routing condition.

5. Run approval as a short operating cycle

Send the sheet to the queue owners with unresolved conflicts in a separate section. Ask each owner to approve, reject or amend each rule ID. Do not ask for general feedback on the whole document.

After approval, keep a change log with the rule ID, change reason, approver, affected queues and review date. Review new misroutes on a regular cadence. Add a rule only after you can show a repeated failure pattern, or revise an existing rule where the boundary has changed.

When the method does not work, stop expanding the sheet. First check whether the issue is missing intake data, overlapping team ownership, or a queue that has no realistic capacity for the work. Take that finding to the operations owner as a process decision. A classification rule cannot repair an unresolved ownership dispute.