A CTO at one organisation said, 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," was the conclusion.
The platform was not the problem. The organisation 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? Was the right vendor chosen? Would a different licence tier have made a difference? 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.
Post-mortems on stalled ITSM implementations almost always attribute the failure to a feature gap in the platform or an integration complexity that nobody anticipated. Occasionally that is true. More often, it is a retrospective rationalisation for an organisational 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 in any ITSM assessment is this: if every constraint on your tooling were removed 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.
That CTO eventually got there. The fourth platform implementation worked -- not because it was a better platform, but because before buying it the organisation spent three months redesigning its 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.