A CTO I worked with once told me, with genuine frustration, that they had replaced their ITSM platform three times in eight years and the service management function still did not work. Different vendor, same problems. Tickets still piled up. Escalation paths were still unclear. The SLA reports still showed numbers that had no relationship to what customers were actually experiencing.
"We keep buying the wrong platform," he said.
He was not buying the wrong platform. He was buying a platform and expecting it to solve a leadership and process problem. That distinction matters a great deal -- because it changes where you start.
The platform is not the transformation
When an ITSM programme stalls -- and most of them do, at some point -- the conversation almost always turns to the tooling. Is the platform configured correctly? Did we pick the right vendor? Should we have gone with a different licence tier? These are not stupid questions, but they are almost always the wrong ones.
The platform exposes the organisation. It does not fix it. If your service processes are poorly defined, if ownership of incidents is contested, if your change management governance is informal at best, a new platform will surface all of that with uncomfortable clarity. And the natural human response to that kind of exposure is to blame the tool.
I have sat through more post-mortems than I can count where a stalled ITSM implementation was attributed to a feature gap in the platform or an integration complexity that nobody anticipated. Occasionally that is true. More often, it is a retrospective rationalization for an organizational maturity problem that was visible before the project started, if anyone had bothered to look.
The question to ask before you buy anything
The most useful question I have found in any ITSM assessment is this: if I removed every constraint on your tooling tomorrow -- unlimited budget, perfect integration, any platform you want -- what would you do differently?
If the answer is immediate and specific, the problem is probably the tooling. If the answer is vague, circular, or involves a list of things that are fundamentally about how your organisation behaves, the problem is not the tooling.
That second answer is far more common than most technology leaders would like to admit.
What this means for agentic AI
This problem is becoming significantly more important as agentic AI enters the ITSM conversation. In 2026, every major platform vendor has an AI story. Most of it is legitimate -- the capability is real. But the risk of layering AI on top of poorly designed processes is not new. It is the same risk that existed when ITSM platforms first offered automated routing and self-service portals.
Bad processes automated at scale are just bad processes running faster.
If your incident management process has ambiguous ownership, adding an AI agent to triage tickets will surface that ambiguity at three times the volume. If your change management governance is informal, an AI-powered change advisory board assistant will be making recommendations into a vacuum.
Where to start instead
Before any ITSM transformation -- and certainly before any AI layer is added to an existing ITSM function -- the work that matters is process work. Not a theoretical exercise, but an honest mapping of how service management actually happens today. Where do tickets go when they get complicated? Who actually makes change decisions, and on what basis? What does an incident commander look like in your organisation, and do people know who it is?
The answers to those questions will tell you more about your readiness for transformation than any platform demo. And they will tell you whether the investment you are about to make is going to land -- or whether you are about to buy a platform that surfaces problems you were not ready to solve.
The CTO I mentioned at the start eventually got there. His fourth platform implementation worked. Not because he found a better platform, but because before he bought it he spent three months redesigning his service management processes with the team that had to live with them. The platform was almost incidental at that point.
That is the sequence that works. Assess honestly, redesign before you automate, then let the platform do what platforms are actually good at.