The two-day-old ticket nobody owned
Picture the shared queue at a 70-person B2B services firm. Sales, support, billing, and delivery all dump into it. A customer writes "we need to talk about renewing" and a coordinator, glancing at the word "renewing," files it under billing. It sits for two days while a $90K account quietly decides you do not care. Nobody did anything wrong. The routing rule was just a human under load, pattern-matching on the first noun they saw.
That is the exact failure AI triage is built to attack, and it is why triage is a smarter first project than the prospecting bots most vendors push. Every routing decision has a verdict you can check within a day: did the right owner get the right request fast enough? Compare that to autonomous outbound, where you find out you embarrassed yourself three weeks later in a reply-all. Salesforce State of Sales research and Salesforce State of Service research both matter here precisely because a B2B services queue lives in the seam between selling and serving, and the renewal-that-looks-like-a-complaint is the seam.
So scope the first pilot narrow. One queue. A short, fixed set of destinations: sales owner, support owner, renewal risk, billing, delivery escalation, or manual review. Have revenue operations sign off on that taxonomy before a single ticket touches the model. If the six buckets are wrong, no amount of model quality saves you. Then have the queue manager log, for each routed ticket, one of three outcomes: accepted, corrected, or blocked. That log is the whole pilot.
One number runs this pilot: wrong-owner rate
Most AI dashboards drown you in metrics. Triage needs one to lead: wrong-owner rate, the share of tickets a human had to re-route after the model picked. It is brutally honest. A flashy "94% routing confidence" means nothing if 1 in 5 still lands on the wrong desk. Track it weekly, and track its companions: first-ownership delay, manual-review share, and how many SLA-clock tickets got stuck in the wrong queue.
To earn a low wrong-owner rate, the model cannot behave like a generic text classifier. Feed it a packet, not a sentence: request source, current account owner, customer tier, SLA status, recent opportunity activity, prior escalations, the suggested queue, and the one-line reason it chose that queue. That reason field is doing double duty. It is how the reviewer audits the call, and it is what lets you tell, later, whether a miss came from a bad model or a stale CRM record. The NIST AI Risk Management Framework is the right lens because in triage the danger is confident misrouting, not a wrong "answer" — a system that is sure and wrong does more damage than one that flags itself for review.
Then carve out the tickets that never auto-route, no matter how confident the model gets: cancellation threats, contract disputes, executive complaints, data-security questions, pricing exceptions. These go straight to a human until you have written escalation rules. Drawing that line is not a limitation. It is the cheapest way to find out which categories your org has never actually defined.
Run a queue-health meeting, not a model demo
The pilot succeeds or fails in a weekly meeting that has nothing to do with AI. Pull ten corrected tickets. For each, ask one question: why did the original route fail? The answer almost always points somewhere other than the model — stale CRM ownership, a category so broad reviewers were guessing, a seller who never updated the account, or a genuinely ambiguous request. Decide where the fix belongs: CRM hygiene, taxonomy, training, or the prompt. That loop is what turns a classifier into a cleaner revenue process.
Because a services ticket can carry renewal pressure, support frustration, and billing sensitivity all at once, keep one hard rule through the pilot: the model recommends a route, a human still sends anything customer-facing. CISA AI data-security best practices should govern what the model can read, how long it retains it, and the wall between internal routing notes and customer replies. Recommend, do not respond, not yet.
You have earned the right to scale when three things are true for a few weeks running: wrong-owner rate is falling, first-ownership delay is shrinking, and the queue-health meeting keeps surfacing data fixes instead of model failures. At that point, connect the workflow to the AI Opportunity Score and extend the same recommend-then-review pattern to renewal alerts or follow-up. The order matters: reliable routing first, customer-facing automation only after the queue has stopped bouncing work.
