Almost every ITSM conversation I walk into these days has a common thread: someone wants to add AI to their service desk. Virtual agents, auto-triage, smart routing, auto-generated ticket summaries, the whole catalog of promises. And I get it. There's huge value in using AI to assist with your service operations. The pressure to "leverage AI" or "become an AI-forward organization" is real, and we've all seen some very impressive demos.
But here's the uncomfortable truth I keep having to say out loud: AI won't fix a broken request catalog or underbaked processes. It will just help you be wrong faster.
Most service desks I assess have a catalog that grew over time rather than one that was designed with a strong vision. Maybe you've seen the symptoms. One hundred (or more) request types, half of them spun up for a specific team or tool. Confusing overlaps, do I submit the "Microsoft Access" form, or the "Access Request" form? Request names written in IT's language ("VPN Tunnel Provisioning") instead of the requestor's ("I can't connect to VPN"). Forms that collect fields nobody downstream really needs. SLAs bolted onto categories that have nothing to do with true business urgency. And no clear owner for most of it.
Everyone already knows the catalog is messy. It's tempting to think that AI will smooth over the mess, so nobody has to do the unglamorous work of fixing it.
The problem is, AI is very good at doing exactly what you tell it to. And a broken catalog is telling it the wrong things.
AI classification learns from your taxonomy. If that taxonomy is ambiguous, the model learns from the ambiguity, then applies it confidently, at scale, to every ticket that comes in. A virtual agent can't explain a service that was never clearly defined in the first place. An AI summary of a vague request is still a vague request, but with better grammar and more text. The confusion is still there for both the agent and the customer, and in many cases is even worse.
This is the part that should give you pause. A human agent staring at a poorly defined request will at least hesitate, feel the friction, and ask a clarifying question. AI doesn't feel that friction, it just routes. If you feed it a broken catalog, you don't get an intelligent system, you get high-throughput misrouting and a team of agents constantly having to catch up.
The fix is not glamorous, and it hasn't changed in twenty years.
Design the service before you configure it. For every request type, you should be able to answer three questions:
• Who owns this?
• How will the requestor find it?
• What does fulfillment actually look like?
And more importantly, the answers need to be defined in the system. If they're not, no amount of automation will save it.
Write for the requestor, not the resolver. Your request types and form fields should map to how end users describe their problems, not how IT files them internally. Bob in Accounting doesn't know if he needs to request an AWS account/access, or if he just needs to request a VM directly. His job is to describe what he's trying to do, and the system's job is to route that to the right team. When you make Bob pick the technical solution, you've outsourced service design to the person least equipped to do it, and you'll pay for it in misroutes, reassignments, and the tickets that never get filed at all.
This single change does more for deflection and self-service than most AI features on the market.
Prune ruthlessly. A lean catalog of well-defined, clearly-owned request types will outperform a comprehensive-but-chaotic one every single time. Retiring dead request types isn't busywork; it's the highest-leverage cleanup you can do.
None of this is an argument against AI, it's an argument about implementation sequence. The organizations actually seeing a return on AI in their service desks are the ones who did the boring catalog work first. Clean taxonomy plus AI routing is how you'll achieve real
deflection. Well-designed forms plus an AI triage agent is how you'll achieve faster assignment, and therefore resolution. AI is a wonderful accelerator, but it's no substitute for intentional service design.
So before you sign off on the AI add-on, run a simple test, pull your top twenty request types. For each one, can you name the owner, trace how a requestor would actually find it, and explain what fulfillment looks like? If you can't do that for the twenty that matter most, you're not ready to point AI at the other eighty.
Fix the catalog first. Then let AI make what already works, work faster.
If your team is thinking about adding AI to your service desk, we'd love to talk. Praecipio helps organizations get the foundation right before the AI goes in.
This Blog was written by, Sam Besozzi, Principal Architect at Praecipio, specializing in ITSM and service management implementations.