Why Most ITSM Tool Selections Start in the Wrong Place

The Super Car Problem

There is an argument for owning a super car and using it for the weekly shop. It is a poor argument, but it exists. Whatever the economics, most people would accept it is a waste of a very good car. It was built for a race track, not for carrying bags of groceries home from the supermarket.

So why do so many IT organisations invest heavily in a sophisticated ITSM platform, then use it to track calls and requests at the service desk?

That is not a criticism of the platforms. The leading tools are genuinely capable, and organisations that use them properly get enormous value. The problem is the mismatch between what was bought and what was needed, and that mismatch is created during selection.

How It Happens

The sequence is remarkably consistent.

Something triggers the review. The current tool is end of life, or a contract is up, or a new CIO arrives, or the service desk has simply had enough. Someone says the tool is holding us back, and a selection process begins.

The first move is almost always to see what is available. Demos get booked. Vendors arrive, and they are good at this, because they do it every week and you do it every five years.

What follows is a persuasive account of a maturity journey. Here is where you are now, here is where you could be, here is the platform that takes you there. Continual improvement roadmaps. Capability models. A vision of the service management organisation you could become.

It is compelling because much of it is true. And by the end of it, the requirements have been written by the vendors rather than by you.

What It Actually Costs

The licence cost is the visible part, and it is usually the smaller part.

A sophisticated platform assumes a sophisticated operation. It assumes you have process owners. It assumes someone will configure workflows as the business changes. It assumes there is a product owner, a governance route for changes, and a budget line for continual improvement rather than just support and maintenance.

If those things do not exist, the platform does not fail on day one. It quietly reverts to being a ticket tracker, because that is the only part anyone has the capacity to operate. Three years later the conversation starts again, with a different vendor and the same assumptions.

The honest question to ask before signing is not whether you can afford the subscription. It is whether you are genuinely committed to the maturity journey the platform assumes you are on. If you are not, buy the run around. You do not need the super car yet.

Requirements First, Tool Later

The alternative is not complicated, but it does require doing the harder thing first.

Before any vendor is contacted, an organisation should be able to answer four questions:

1. Where are we now? Not an opinion, but an evidenced view of current maturity across the disciplines that matter. Which are working, which are not, and what the gap actually is.
2. Where do we need to be? Tied to what the business needs from IT, over a defined period, with a realistic assessment of the capacity available to get there.
3. What does the tool need to do? Requirements derived from that gap. Not a feature list assembled from vendor websites, and not everything anyone can think of.
4. What are we committing to operate? Who owns the platform after go live, what governance changes go through, and what budget exists for improvement.

Answer those and the tool selection becomes straightforward. You have a requirements set that came from your organisation rather than from a sales deck, you can score vendors against it, and you can tell the difference between a feature you need and a feature that is impressive in a demo.

You will also frequently find the honest answer is that your problem was never the tool. Poor first contact resolution is usually thin knowledge articles rather than a platform limitation. Low portal adoption is usually a knowledge base that cannot answer the question rather than a bad interface. Those problems follow you onto the new platform, at considerable expense.

The Roadmap Is the Deliverable

What comes out of that work is more valuable than the tool decision itself.

A prioritised roadmap tells you what to fix and in what order, which improvements need tooling and which are process or behaviour, and where the tool genuinely is the constraint. Some of it can start immediately, on the platform you already have.

The tool decision then becomes one item in a plan, sized correctly, rather than the plan itself.

Why This Advice Is Hard to Find

Almost everyone who offers guidance on ITSM tool selection has an interest in the outcome.

Vendors need you to buy their platform. Resellers earn on the licence. Implementation partners earn on the configuration that follows. None of them are acting badly, but none of them can credibly tell you that you do not need a new tool, or that a smaller one would serve you better, or that the money would be better spent on knowledge management first.

That conclusion is only available from someone with nothing riding on which platform you choose.