Choosing an ITSM or ESM tool: not the heaviest, but the one that fits

The best ITSM or ESM tool is not the most powerful platform on the market. It is the platform that fits how your organization works, what your team can handle and where you want to go. Sounds obvious, but in practice it often goes differently.

The trap of the heaviest platform

Many selection projects start with a demo of the best known, biggest platform. It can do everything. And that is exactly the problem. A tool that can do everything demands an organization that can manage everything. Configuration, governance, ongoing maintenance: that costs people and time you do not always have.

In many organizations we see the same thing happen. A heavy platform gets bought, an external party configures it, and after go-live nobody dares to touch it. Every change becomes a project. The system steers the organization instead of the other way around. That is the opposite of what you wanted.

Fit over features

The honest question is not "which platform can do the most?" but "which platform fits us?". A tool that lets you handle ninety percent of what you need simply and on your own is usually more valuable than a tool that can do one hundred percent but needs a consultant for every button.

Fit is about the match between the platform and your organization: your size, your maturity, your in-house knowledge and your ambition. A platform that is too heavy stays half configured. A platform that is too light you will outgrow within a year. The art is in the right size. Before selecting, an ITSM maturity assessment shows where you actually stand, which makes the shortlist much easier to build.

The criteria we look at

In a tool selection we weigh a fixed set of criteria. Not to tick boxes, but to keep the conversation sharp:

• Organizational fit. Does the platform match your size, culture and way of working?
• Ease of configuration. Can you make changes yourself, or do you always need help?
• Self-support. Can your own team maintain the system without a permanent external dependency?
• AI roadmap. Where is the vendor heading with AI, and is that realistic?
• Automation capability. How easily do you automate repetitive work?
• Vendor vision. Is the vendor building a future that fits yours?
• Complexity. How much knowledge does it cost to keep the system running and healthy?
• Pricing. Not just the license, but the total cost over a few years.
• Integrations. Does the platform talk well to the systems you already have?
• Implementation effort. How much time and how many people does rollout really cost?

No single criterion wins on its own. It is about the balance. A cheap platform you cannot manage yourself is expensive in the end. A powerful platform without a clear AI direction can fall behind within two years.

Involve the team that uses it

A tool is not used by the steering committee but by the people on the floor. Yet we see selections decided entirely at management level. The result: a platform that scores perfectly on paper and gets avoided in practice.

Let the people who work with it daily join the demos. Give them a real case to try, not a polished click-path from the vendor. Their reaction predicts adoption better than any feature list. Adoption is ultimately where the value sits. A tool that is not used delivers nothing, however good it is. The article on ITSM tool adoption after go-live explains how to set up the period after launch so the change actually sticks.

The role of the AI roadmap

AI is changing what a service tool can do, and it is moving fast. So in a selection we look not only at what the platform does today, but at where the vendor is heading. Is there a serious AI roadmap, or are these loose features that mainly sound good?

Watch the difference between marketing and reality. Ask further: how does the AI work with your knowledge and processes, who keeps control, and what happens to your data? A platform with a clear, realistic AI direction gives you room to grow. A platform that pours AI over the top as a topping does not. The article on AI readiness for the service desk covers what the internal foundation needs to look like before AI actually adds value.

Integrations: the real selection factor

In the list above, integrations appear as one criterion among many. In practice they often turn out to be the deciding factor, yet they are the thing least concretely tested during a demo.

The reason is simple: in a demo the vendor shows integrations that work. What you do not see are the connections that require custom code, the API limits that only surface at scale, and the question of who is responsible for that integration three years from now when the person who built it has moved on.

Which integrations matter for ITSM

For a standard ITSM platform, a handful of integration categories come up almost every time:

• Identity and directory. A connection with Active Directory or Entra ID for user management, group memberships, and automatically provisioning or deprovisioning accounts when someone joins or leaves.
• Monitoring and alerting. Systems that automatically open an incident when a server, application or network device crosses a threshold.
• Communication and collaboration. Teams, Slack or email as a channel for notifications and status updates toward the end user or the assignee.
• Asset and configuration management. A link to a CMDB or discovery tool so a ticket automatically knows which device, application or service is involved.

For each of these categories the key question is: does the integration use a standard connector, or does it require custom work? Standard connectors are supplied and maintained by the vendor. Custom integrations are maintained by whoever built them. Over five years that is a significant difference.

Extra integrations for ESM-wide use

Once you use ESM beyond IT, meaning HR, facilities or other internal service providers also run on the platform, a second layer of integrations appears:

• HR systems. For joiner-mover-leaver processes: a new employee in the HR system triggers tasks in the ITSM platform to create an account, order a laptop and arrange access.
• Facilities systems. Building management, room booking or visitor registration that runs through the same portal as IT requests.
• Financial systems. Approval workflows for requests above a certain amount, where the tool communicates with the ERP or purchasing module.

The more departments use the platform, the greater the chance you need integrations the vendor does not supply as standard. That is not a problem, as long as you know it before you sign.

Where integrations go wrong

The most common problems:

• Custom integrations without an owner. An integration is built during implementation, works fine, and two years later it breaks after an API update on the other side. Nobody knows exactly how it was built because the person who made it is gone.
• API limits at scale. A monitoring tool sends a hundred alerts per minute during a major incident. The ITSM tool has an API limit of twenty calls per minute. Result: tickets that arrive late or not at all.
• Data ownership at contract end. When you end the contract with the vendor, how do you export historical data including integration logs? Ask this explicitly, because the answer is not always what you expect.
• An integration that breaks the user experience. A self-service portal that looks great, but where the HR integration means a new employee does not have an account until three days after starting. Technically everything works, but the outcome is wrong.

What to ask per integration during a selection

For each integration that is critical to your organization, ask the following:

1. Is this a standard connector or custom work?
2. Who maintains the connector when the other side changes its API?
3. What are the API limits, and how does the system behave when the limit is reached?
4. How does authentication work? Is it OAuth, an API key or something else, and how does credential rotation work?
5. Can you test the integration in an acceptance environment before going live?
6. What is the procedure if the integration fails? Who gets alerted, and how quickly?

This sounds like a lot of work, but you only need to do it for the integrations that are truly critical. Three or four solid conversations about specific integrations give you more useful information than ten demos where the vendor shows their best slide.

Which ITSM tool fits our organization? A decision guide

"Which tool should we choose?" is the question everyone asks. The answer depends on questions that need to be answered first. Here is a step-by-step sequence that points you toward a direction without handing you a vendor list.

Step 1: How large is the organization, and how mature is IT service delivery?

A team of five support staff serving a few hundred users has different needs than a team of fifty covering multiple locations and external providers. Larger organizations generally need layered authorization, extensive reporting and more integrations. Smaller organizations need speed and simplicity above all. If you do not have a clear picture of your current maturity yet, an ITSM maturity assessment is a good first step.

Step 2: Does your own team manage the system, or is that outsourced?

If your own administrators configure, maintain and adjust the system, choose a platform with a low configuration threshold. If you are structurally dependent on an external partner for every change, that is fine as long as it is a deliberate choice and the costs are factored in. What you want to avoid is unintended dependency: choosing a platform that promises to be simple but in practice needs constant outside support.

Step 3: What is the ESM ambition beyond IT?

If IT is the only department using the platform, the requirements are different from a situation where HR, facilities or finance are also on it. ESM-wide use requires a platform that properly separates roles and permissions per department, has a portal that non-IT users can understand, and supports integrations with HR and ERP systems. Once the platform is in place, a service catalogue written in plain language helps make the services for all those departments actually findable.

Step 4: What does the integration landscape look like?

List the ten systems the ITSM platform needs to communicate with. Categorize each one: standard connector available, custom work needed, or unknown. The more custom work is needed, the higher the implementation costs and the maintenance risk. Take the answers into your vendor conversations.

Step 5: How serious is the vendor's AI roadmap?

AI in ITSM tools ranges from text suggestions in the ticket form to full automation of categorization, routing and replies. The question is not whether a vendor has AI, but how it works with your data, processes and knowledge base. Ask specifically: which AI features are already in production, which are planned, and how is data isolation handled between your environment and other customers?

Step 6: What is the budget reality?

License costs are rarely the biggest expense. Implementation, configuration, ongoing management and integrations all count. Calculate the total cost of ownership over three years, not just the per-user-per-month rate. A cheaper platform that requires more custom work can turn out more expensive than a pricier platform that integrates well out of the box.

Once you have honest answers to all these questions, the shortlist gets short on its own. Only then do you start watching demos, using real cases from your own organization.

Frequently asked questions

Which ITSM platform is the best? There is no best platform in general. The best platform is the one that fits your organization, team and ambition. So a good selection starts with your situation, not with the tools.

What is the difference between ITSM and ESM? ITSM focuses on IT service delivery. ESM (enterprise service management) applies the same approach to other departments, such as HR and facilities. Many platforms can do both, but not all equally well.

How long does a tool selection take? A focused selection does not need to take half a year. With clear criteria and the right people at the table you can reach a well-founded choice in a few weeks.

Which ITSM tool fits a mid-sized organization? It depends on three things: whether you want to manage the system yourself, how far your ESM ambition reaches beyond IT, and which integrations you need with existing systems. A mid-sized organization typically benefits from a platform that is easy to configure, integrates as standard with identity and monitoring, and has a clear AI roadmap. The steps in the decision guide above will point you toward a direction without needing to work through a vendor list first.

How important are integrations when choosing an ESM tool? Integrations are often the deciding factor for ESM tools precisely because ESM touches more systems than pure ITSM. Think of HR systems for joiner-mover-leaver processes, facilities platforms, communication tools and monitoring. The question is not whether integrations work in the demo, but who maintains them when something changes on the other side. For each critical integration, ask whether it is a standard connector or custom work, and what the procedure is if it breaks or the API changes.

A tool selection is not a purchasing decision, it is an organizational decision. Choose the platform that fits you and genuinely helps your team, not the platform with the longest feature list. If you plan to extend service management beyond IT, see how ESM works across departments. For guidance on the selection process: see our service management services.

Want to choose a tool that fits how you work? book a call and we will walk through the criteria that matter for your organization.

Further reading

• IT service management (Wikipedia)
• Enterprise service management (Wikipedia)