I spend most of my week in rooms with IT leaders who are all under the same pressure: do more with less. And I keep hearing the same frustration. They bought “AI for ITSM,” and what they got was a suggestion engine bolted onto a ticket system designed 15 years ago.
“AI-powered routing” turns out to be rules with a ChatGPT wrapper. “AI summarization” writes a nicer paragraph on a ticket a human still has to close. The interface got smarter. The work stayed exactly where it was.
That era of AI-washing in ITSM is ending. What follows is how I have come to think about it, pulled together from a run of conversations and a handful of vendor evaluations I watched play out over the past few months.
Suggestion is not resolution
The distinction that matters most is simple. Real service desk AI has to do four things:
- Understand what someone actually wants, not just match keywords.
- Pull live context from identity, assets, and policy at the moment of the request.
- Execute the fix rather than recommend one.
- Know when a human needs to approve before it acts.
Most tools on the market handle the first two, stop short of the third, and never seriously considered the fourth. The gap between suggesting and executing is the whole ballgame.
An AI that can’t take action is a search bar with a chat interface. Deflection is a vanity metric. Resolution is what matters.
I watched one organization run a bake-off across 15 enterprise AI vendors. The vendors that offered suggestions all underperformed. The one that won could actually take action. It authenticated the user, created the case, ran the workflow, and escalated with full context only when it genuinely needed a person. It now resolves roughly 70% of issues on its own and is on track to save more than $4.5M a year.
Change the unit of work
The reason legacy systems stall is philosophical, not technical. They treat the ticket as the unit of work. You can summarize the ticket, route the ticket, and suggest a knowledge article for the ticket, and a person still has to do the actual resolution.
Employees do not want a ticket number. They want a password reset, a laptop delivered, access provisioned. The shift that unlocks everything is moving from “ticket as the unit of work” to “outcome as the unit of work.” That takes an execution layer, not another chatbot.
Why almost nobody can actually execute
Here is the part the market glosses over. Every vendor now says the word “resolution.” Very few can deliver it, and the reason is architecture, not ambition.
To reset a password, provision access, or ship a device, an agent needs to know who the person is, what they are entitled to, what assets they own, what policy applies, and what happened the last time someone asked. In most stacks that information lives in five different systems held together with integration middleware. Bolt an LLM on top of a legacy ticket database and it can read the ticket, but it cannot safely act, because it never had the context to act on in the first place.
This is where DevRev is built differently. Identity, assets, tickets, engineering work, and customer records live in one connected data model rather than in silos wired together after the fact. When the agent acts, it acts on a single source of truth, so it already knows what it is allowed to do and for whom.
The data model is the moat, not the model
Everyone has access to the same large language models. What separates a system that suggests from one that resolves is whether the AI can see identity, entitlements, assets, and history in one place at the moment of action. Unified context is what makes safe execution possible. Fragmented context is why bolt-on AI stays stuck at suggestions.
Three things fall out of that design, and they are hard to replicate by adding features to a ticket tool:
- Trust is native, not bolted on. Permission-awareness, approval gates, and audit trails come from the fact that the agent operates inside one identity-aware graph. Governance is a property of the architecture, not a compliance checkbox added later.
- No integration tax. Support, product, engineering, and CRM sit on one platform, so the agent works across the whole flow instead of the ticket queue alone. There is no iPaaS layer to buy, staff, and maintain just to let the AI reach the systems it needs.
- The feedback loop closes. A recurring issue does not just get resolved faster every time. Because service and engineering share the same graph, the signal reaches the team that can fix the root cause, so the problem stops generating tickets at all.
Resolving a ticket faster is efficiency. Eliminating the reason the ticket exists is leverage. Only a unified platform gives you the second one.
What that looks like in the field
A retailer hiring more than 2,000 people a year was drowning in provisioning: laptops, credentials, software access, onboarding workflows, with no budget to grow the IT team. They stood up an execution layer instead of adding headcount.
2,000 new hires, zero new IT headcount
Same-day IT setup became self-service. The IT team moved to strategic work instead of the queue. And it happened in weeks. For context, a traditional ITSM platform rollout of that scope routinely runs 12 to 18 months before anyone sees a resolved ticket. Sixty-eight days to production is not a nicer version of the old model. It is a different model.
Why the service desk is the right place to start
When CIOs ask me where to begin an AI transformation, my answer is almost always the service desk. Not because it is the flashiest, but because it is the smartest first move.
- Results show up in weeks. Resolution rates move fast, which builds the internal case for everything after it.
- The risk is contained. It is internal-facing, so you are not betting customer relationships on version one.
- It proves the trust model. Audit trails, approval gates, and permission-awareness get battle-tested where the stakes are lower.
- The ROI is self-funding. The savings justify the next round of investment on their own.
Start where the pain is obvious and the blast radius is small. Then scale the same platform into customer support, HR, and operations once trust is earned. The point of starting on one platform is that scaling later does not mean buying and stitching together the next tool.
Don’t try to boil the ocean with enterprise-wide AI governance on day one. Start where friction is most visible, and let that foundation earn you the right to expand.
The cost of standing still
Picture a lean team of 12 agents handling 120,000 tickets a year with no meaningful automation. That is roughly $5M to $10M in savings left on the table every year while the same routine requests recycle through the queue: password resets, MFA unlocks, access provisioning, device requests.
Now compare it to the retailer that automated 60% of those tickets in 68 days with the same size team. The difference was never headcount. It was whether the system could actually do the work.
The same pattern in customer support
This is not only an internal IT story. A $1.6B fintech moved AI query resolution from 17% to 70% in 15 weeks and passed a $4.5M savings target. Response times dropped from minutes to seconds. Satisfaction went up. The part that surprised people internally: customers started preferring the AI over waiting for a human, because the AI actually resolved things.
It worked for the same reason the retailer worked. The system authenticated users, created cases, ran workflows, and escalated with full context when it needed to. Not because it had a nicer chat window.
The question worth sitting with
If the AI had proper controls, meaning audit trails, approval gates, and permission-awareness, would you trust it to take real actions on your service desk? Not suggest. Act.
That is the line the market is crossing right now. The organizations pulling ahead stopped asking “how do we deflect more tickets” and started asking “what is the single most repetitive request clogging our queue, and why is a human still closing it?”
Answer that honestly and you have found your starting point. If you want to compare notes on where your team sits, my inbox is open.
This piece pulls together a series I wrote on LinkedIn between July 6 and July 13, 2026, on the shift from AI-washing to AI that resolves. If it resonates, or if you see it differently, I would genuinely like to hear where you land.