The Paradox We're Living In

Something genuinely interesting is happening with ITSM tool selection right now. The tools themselves are better than they've ever been. Feature-complete, integrated, cloud-native, AI-adjacent, whatever you want to call it. And yet, I'm hearing the same conversation from service desk teams now that I heard a decade ago: "We bought the right tool, but it doesn't feel right."

The honest part? It usually isn't the tool's fault.

What's Changed (and What Hasn't)

The vendor landscape has consolidated a bit. Some players have moved upmarket, others have focused on specific niches. The cloud shift is real, not hypothetical anymore. Most teams aren't self-hosting their ITSM platform anymore, and that's genuinely freed up energy for other things.

What hasn't changed: the gap between what a tool can do and what a team actually uses it for.

I think a lot of the confusion in selection right now comes from vendors selling based on capability and features, while teams actually buy based on whether the tool will fit into how they already work. Those are not the same thing. A tool might have beautiful reporting, but if generating a report takes three clicks and your team wants one, that's still friction. It's small friction, but friction compounds.

The Questions Worth Actually Asking

Here's what I notice teams wrestling with when they're serious about selection:

First is integration reality. Not theoretical integration, actual reality. Does the tool play nicely with the systems that already exist in the environment? This sounds obvious, but the conversation usually starts abstract and ends concrete, which is backwards. Picture a service desk where tickets live in one system, knowledge lives in another, assets in a third, and nobody wants to leave the first one open while they check the second one. That's an integration problem wearing a tool problem's clothes.

Second is the learning curve versus the onboarding reality. Every tool is learnable. Most tools are learned while the team is also doing actual work. That's the gap that matters. Some platforms have spent genuine effort making common workflows obvious and quick. Others have everything available but buried three levels deep. That difference matters enormously when someone's got fifteen tickets in the queue.

Third is actually about governance, but nobody frames it that way. It's whether the tool lets a team enforce its own way of working, or forces the team into the tool's idea of the right way. Sometimes the tool's idea is better, and the team should adapt. But sometimes it's just different, and different creates resistance that looks like tool resistance but is actually change resistance. Knowing the difference before you buy is useful.

Fourth is around what happens when the platform changes. All platforms change. New features, interface updates, integrations shift. The question is whether the vendor is changing things because they've genuinely learned something better, or whether they're changing things because they want to justify the subscription. The honest answer is often both. What matters is whether the team finds the change manageable.

What the Vendors Are Actually Doing

Lots of vendors are pouring effort into mobile experiences right now, which is interesting. A lot of service desk work happens on phones now, or starts on phones. The teams that have decent mobile experiences seem genuinely happier, which seems like a small thing until you realize it's not.

AI integration is everywhere, and that's real, but the actual utility varies wildly. Some vendors have AI features that genuinely reduce toil. Others have AI features that generate noise. The difference is usually in how much thinking went into what the AI should actually automate versus what it's technically possible to automate.

Customization and configuration are getting smarter too. Less coding, more configuration, more no-code options. That's a real shift that changes who can shape the system and how quickly it can adapt.

The Honest Part

Most ITSM tools in 2026 will do what a service desk actually needs. They'll create tickets, route them, track them, close them, report on them. That part is solved. The selection battle isn't really about that anymore.

It's about which tool's assumptions align with how the team thinks, how much space it gives the team to be themselves, how it handles the moments when something unexpected happens, and whether the vendor is making life easier or more complicated with each update.

Those are harder things to evaluate than feature lists, which is probably why feature lists are what get compared. But they're the things that actually determine whether a tool becomes part of how work happens or becomes something the team tolerates.

The good news? Most teams figuring this out right now are doing it more thoughtfully than they used to. They're testing with real workflows, watching how people actually use the demo instance, asking harder questions about what happens on day 200 of ownership, not day two.

That's the interesting shift. Not the tools getting better, but the teams getting more honest about what they're really buying.