The misrouted ticket nobody wants to explain
Say a client emails your firm: "Need the updated numbers before the board meeting Thursday." At a 60-person professional services firm, that one line has to be decoded fast. Which client? Which engagement? Is this the active M&A matter where two of your partners are walled off from each other, or the routine bookkeeping account? Is "Thursday" an SLA clock that already started, or a soft ask? A coordinator who knows the book of business answers in four seconds. A new hire forwards it to the wrong team, and now you have engagement-scope material in front of people who shouldn't see it.
That is the actual job ticket triage does at a services firm, and it is why "let AI summarize the queue" misses the point. The risk isn't a slow response. It's routing a confidentiality-sensitive client request based on a confident-sounding summary that ignored a conflict wall, a retainer scope, or a privilege boundary. Speed is the easy part. Routing the right matter to the accountable owner, without exposing what shouldn't be exposed, is the hard part.
The adoption data backs treating this as an operating decision rather than a prompt experiment. The RSM middle-market AI survey, the San Francisco Fed small-business AI analysis, and the OECD SME AI adoption report all show the same gap: firms adopt the model, then never define which record the model is allowed to trust or who owns the decision when it's wrong. Triage is worth doing only when the answer to "where does this go and who is accountable" gets faster without getting riskier.
What the model needs to see, and what it must never touch
Most teams hand the model the raw ticket text and hope. For a services firm, the design question is narrower and sharper: what does the triage model get to read, and what does it have to stay blind to? A model that can see every client's matter history to classify urgency is also a model that can leak one client's situation into another's routing. The CISA AI Data Security Best Practices are the place to settle exactly what gets exposed: ticket text, the client record, engagement or matter context, the SLA threshold, the relevant knowledge article, the routing queue, and prior escalation history each get a deliberate exposed / retained / logged / excluded decision. Conflict-walled matters belong in the excluded column.
Then use the NIST AI Risk Management Framework to name the reviewer who owns each queue and the measurable thing that counts as a triage failure. A useful shorthand: every triage recommendation has to arrive as a packet a coordinator can inspect in one glance, not a paragraph they have to trust. That packet carries the urgency class, the client-sensitivity flag, the named project owner, the routing rationale, a link back to the source ticket, and a one-click reviewer override with a reroute reason. If the model can't show why it picked a queue, the coordinator can't catch the moment it routed a privileged matter to the wrong partner.
The line to hold: a general assistant is fine for drafting a triage suggestion and surfacing candidates. It is not fine for writing the routing decision into your system unattended. If a broad assistant is all you have, keep its output in draft and require signoff. The moment triage starts touching system records, exception queues, or anything tied to engagement scope, you build deterministic checks around the model. The model proposes; the rules and the reviewer dispose.
Reroute rate is the number that tells the truth
Pilots love vanity metrics: tickets summarized, minutes "saved." The Deloitte State of AI in the Enterprise 2026 point is that production value, not pilot activity, is what separates a triage tool that scales from one that quietly dies. For a services firm, the honest scoreboard is six numbers: time to first owner, reroute rate, severity-override rate, SLA-breach exposure, reviewer-correction rate, and client-response delay. Reroute rate is the one to watch hardest. If recommendations keep bouncing between teams, the model isn't the problem, your matter taxonomy is too coarse for anyone to govern, and adding AI on top of it just automates the confusion faster.
Run the pilot on one queue with named reviewers. Require every recommendation to show its source ticket and its routing reason. Review the reroute pattern weekly, and read it as a diagnostic of your own categories, not just the model's accuracy. The pilot earning expansion looks like this: fewer bounced tickets, escalation ownership you can actually inspect, and a coordinator who trusts the suggestion enough to accept it but can override it in a click when a conflict wall is in play.
Two next steps. Use the manual-work scoring guide to confirm triage is the workflow worth fixing before you build anything, then stage source cleanup, prototype, reviewer training, launch, and scale with the 90-day AI implementation plan. And budget time after the pilot to redraw your ticket taxonomy, because a working triage model almost always exposes categories that were too broad for client-service managers to route cleanly in the first place.
