A ticket routing engine looks reliable when every issue arrives with a clean tag. Real queues do not.
A disputed card payment arrives by email. The subject says "refund". The body describes a cardholder dispute. The attachment shows a chargeback notice. A rule routes on the subject. An experienced operator routes on the whole ticket.
The choice is not rules or AI. Rules handle facts the system already knows. AI triage suggests a route when the meaning has to be read. The operator remains responsible for the decision.
This is for
- Operations leads whose queue has outgrown sender, form, and tag rules.
- Support-platform owners deciding where AI belongs in ticket routing.
- Engineering teams that need routing to stay reviewable, self-hosted, and tied to the rest of the ticket lifecycle.
Routing rules are strongest when the signal is explicit
Deterministic rules are the right tool when a ticket arrives with a fact that maps cleanly to a queue.
Use a rule when:
- a form identifies the request type;
- an inbound address belongs to one team;
- a customer tier sets the priority;
- a product or region field is already known;
- a threshold has one documented outcome.
The rule is inspectable. The same input produces the same route. An operator can explain why it ran without interpreting a model score.
Do not replace that certainty with AI. A model adds cost and uncertainty where neither is needed.
Rules fail when language carries the decision
The chargeback ticket defeats a subject-line rule because the word "refund" is not the work type. It is one word inside a larger account.
Rules become brittle when teams respond by adding more keywords. One rule catches "chargeback". Another catches "card dispute". A third excludes "refund already issued". The list grows until nobody knows which condition controlled the final route.
That is where AI ticket triage and routing becomes useful. A model can read the description, attachments, sender context, and prior examples, then propose the chargeback queue instead of matching one word.
The proposal is not the decision.
Latch Workflow combines the rule, the suggestion, and the action path
Latch Workflow keeps deterministic routing for explicit facts and uses native AI for ambiguous tickets. The model proposes a queue and priority. The operator accepts, changes, or rejects the suggestion.
The correction stays with the ticket as a labelled example. A local or open-weights model can learn from that record inside the same on-premises deployment. The team does not have to send ticket content to a vendor model for routing to improve.
Routing is also only the first stage. Once the chargeback reaches the right operator, a plugin can expose the next eligible action inside the ticket page. The same plugin covers contextual inputs, an approval step, execution against the downstream system, and the returned outcome. The operator does not have to rebuild that lifecycle with separate hooks and admin tools.
An MCP client uses the same authority path. It can discover only the tools and tickets allowed by its credential. Its request still passes through role, policy, approval, and audit checks. The developer path shows how plugins, APIs, webhooks, and MCP share that boundary.
Human correction is the control, not a model failure
The disputed payment will still be misrouted sometimes. That is not a reason to hide the suggestion or automate it silently.
A useful triage workflow records:
- the route the model proposed;
- the evidence available at the time;
- the route the operator selected;
- who made the correction;
- whether the next similar ticket ranked differently.
The audit trail should preserve that decision. A routing system that stores only the final queue cannot show whether the model was useful, whether the operator corrected it, or whether the correction improved later suggestions.
Confidence should decide when the model stays silent
A model does not need to suggest a route for every ticket. Thin evidence should produce no suggestion.
The strongest operating model has three paths:
- A deterministic rule routes the ticket because the signal is explicit.
- AI proposes a route because the meaning is ambiguous but supported by examples.
- The system stays silent because the evidence is weak, and the operator routes the ticket manually.
Silence is part of the control. It prevents a low-confidence guess from looking like a system decision. Confidence scores alone are not enough; the workflow needs a threshold, a review path, and a record of corrections.
Measure routing quality after the handoff
Routing accuracy is not the only useful metric. A ticket can reach the right queue and still stall.
Use the operations dashboard to keep the downstream signals beside routing:
- backlog by status and priority;
- unclassified work;
- issue-type volume;
- intake sources;
- plugin health and recent executions;
- AI readiness by issue type.
Then watch handoff delay, reopen rate, blocked work, and outcome quality. Queue health metrics show whether the route produced durable progress.
The operating rule
Use a rule when the system already knows the answer. Use AI when the meaning has to be read. Ask the operator when the evidence is weak.
Keep all three paths in the same ticket workflow. That is how routing improves without turning a suggestion into hidden authority.