AI ticket triage and routing that learns from your operators
Email, web forms, alerts, and system events land in one queue as tickets - or cases, if you work in a regulated function. Latch Workflow classifies each one, proposes a route and a priority, and flags the ones running against an SLA. When an operator overrules the route, that correction becomes training signal inside your own deployment.
Duplicate settlement, reviewed before reversal.
A second capture of 4,850.00 arrives with a ledger trace; the original payout has already posted.
Amara checks the payout and amount, selects Reprocess, and takes ownership of the exception.
The provider action remains held for another reviewer; the evidence and decisions remain on the ticket.
TRIAGE IN PRACTICE
A duplicate settlement needs a decision before a reversal.
A settlement webhook reports a second capture of 4,850.00 for Northwind Distribution. Payout PO-88213 has already posted. The amount and ledger trace give the operator enough context to investigate the duplicate.
01 · Intake
The case enters triage
The webhook creates a ticket in Triage Queue with the payout reference, captured amount, and ledger trace attached.
02 · Operator review
The evidence sets the priority
Amara checks the posted payout and matching amount, marks the work High priority, selects Reprocess, and takes ownership.
03 · Controlled next step
A reversal still needs review
The proposed provider action stays behind a second-approval gate. The ticket keeps the decision, evidence, and action history together.
Task: Duplicate settlement not reversed · Northwind Distribution · SET-4471
Auto-created by settlement-webhook/v1/duplicate-capture after the nightly settlement run matched a second capture against a payout that had already posted.
Reverse the duplicate capture on SET-4471 and credit Northwind 4,850.00. Payout PO-88213 posted on 04/08, so the second capture is recoverable in-ledger without a customer-side refund.
Matched 37 resolved tickets with the same settlement signature. Operators reversed in 35; the two exceptions were both post-dated captures.
Actions
payments-provider · second review required above $2,000
Send settlement correction notice to ap@northwind.example
Attach ledger trace SET-4471 to this task
TKT-20260805-000142
Duplicate settlement not reversed
Northwind Distribution · Nairobi CBD Branch
Request
A second capture matched a settlement that had already posted.
AI suggestion
Reverse the duplicate capture and credit the merchant.
Approval and audit trail
- policy gate requested second approval
- amara.kimani proposed the reversal
- settlement-webhook attached the ledger trace
Illustrative case with fictional names and amounts. The composite view shows the ticket after triage.
A shared inbox routes nothing
A shared inbox centralises incoming messages and stops there. Nobody owns a thread until someone claims it, and the second reply usually starts from scratch. Ticket routing assigns the owner, the queue, and the due time at intake, so the work is placed before anyone reads it twice.
Escalation policy runs on the queue
Each ticket carries a due time and an escalation policy from the moment it lands. Breaches surface in the queue rather than in a weekly report, and triage learns which ticket types your team escalates early so it stops promoting the ones they never do.
Context switching drops fast
When every issue starts in the same place, teams stop reassembling context from inboxes, spreadsheets, admin panels, and Slack threads before they can decide what to do.
Handoffs start with the full picture
Suggestions, customer context, attachments, and available actions are all on the ticket. When the first handoff happens, the next team sees the real state of the issue - not a forwarded email with half the story.
Triage is where plugins become useful
Once the operator understands the issue, they should be able to take the next step from the same ticket. That is why ticket triage and plugin actions belong together.
Follow the control path from intake to evidence
These pages work together: intake shapes the ticket, approvals gate sensitive actions, maker-checker enforces independence, security controls the deployment boundary, and auditability preserves the proof. The claims use case shows the controls assembled end to end.
Enforce separation between the person preparing an action and the person approving it.
Route sensitive actions through role checks and approval gates before they run.
Keep decisions, blocked attempts, approvals, and action results on the same record.
Deploy where ticket data, identity, and the AI models you choose stay inside your environment.
See the controls assembled for claims work: checklist-driven file reviews, maker-checker, and upstream execution proof.
AI can propose the route. The queue still needs a control boundary.
See how classification, operator correction, authority, and audit evidence fit into one triage path.
An email becomes operational only when the context survives intake.
Follow the path from mailbox receipt to a routed ticket with attachments, sender context, ownership, and failure handling intact.
A shared inbox centralises messages. Unified triage governs work.
Compare message visibility with ownership, routing, SLA state, approval, and a complete case history.
Duplicate, rejected, and cancelled work still needs a durable record.
See why terminal paths belong in the workflow model instead of disappearing from the queue.
Questions about how the queue actually works
Common questions about ticket triage, routing, and what happens to the corrections your operators make.
How is this different from a shared inbox?
A shared inbox centralises messages. It does not assign an owner, apply an escalation policy, or track an SLA clock. Latch turns each inbound message into a ticket with an owner, a queue, a due time, and an action history. If two people handle twenty messages a week between them, a shared inbox is enough and this is not worth the change.
What does the AI decide, and what does the operator decide?
Triage classifies the ticket, proposes a queue and priority, and flags missing context. The operator accepts, adjusts, or rejects the suggestion, and nothing routes or runs on its own. Every accepted and every corrected decision is kept as a labelled example, so the next suggestion on a similar ticket reflects what your team actually did.
Do our corrections train a shared vendor model?
No. Classification and routing run inside your own deployment - on-premise, private cloud, or air-gapped. Ticket text, attachments, and the corrections operators make stay behind your boundary. There is no pooled model that improves for other customers because of your queue.
Can teams adopt this without changing every workflow at once?
Yes. Teams can start by bringing intake and ticket routing into one place while keeping downstream systems as they are, then add sensitive actions through plugins over time.
How does context stay attached to the ticket?
The ticket record holds the issue description, who reported it, attachments, notes, routing changes, approvals, and action results in one place. When the ticket is handed off or escalated, all of it travels with the ticket.
Walk through your own intake and triage flow
Follow how email, tickets, and exceptions land in one queue, where triage suggests a route, and where approvals and plugin actions take over.