The Real Cost of ITSM: What Should You Compare?

Buying an IT service management platform would be much easier if you could compare two prices and pick the cheaper one. It rarely works that way.

Per-agent pricing, consumption-based pricing, feature tiers, cloud infrastructure, support levels, integrations and implementation costs all affect what you actually pay for an ITSM or ESM solution. That's before you think about what might happen to the pricing, the packaging or the product itself over the next few years.

---

TL;DR

The headline licence price is only part of the cost. Before committing, look at how the pricing model scales, what's included, infrastructure and service levels, implementation and support, the chance of future packaging changes, and how hard it would be to move elsewhere. In short: understand the cost of getting in, the cost of staying in and the potential cost of getting out.

---

This month's news shows why that last point matters. On 10 September, Salesforce completed its acquisition of Fin, the AI customer service agent formerly known as Intercom. Fin is best known for outcome-based pricing, where you pay per successful resolution. Help Desk Migration, a data migration provider, has already questioned whether that model could change now that Fin sits inside a much larger enterprise ecosystem.

Fin is a customer service product rather than an ITSM platform. But AI agents with usage- and outcome-based pricing are arriving in service management too, and the question applies just as much there.

Start with what you're actually paying for

A price like £X per agent per month looks simple. Before you compare it with another platform, find out what it includes:

• Which ITSM features are available at that tier?

• Are there limits on agents, customers, assets or usage?

• Are reporting, automation and integrations included?

• Are AI capabilities included, or charged by consumption?

• What support level do you get?

• Are backups and disaster recovery part of the service?

• What happens to the price as your usage grows?

The last question matters most. A pricing model that works well for 20 agents can look very different at 200. Consumption- or outcome-based pricing is attractive because you pay for what you use, but that also means wider adoption can push your costs up. Neither approach is wrong. What matters is knowing which variables drive your bill.

 

Technical architecture belongs in the pricing discussion

GLPI recently redesigned its pricing information to show more detail about its Public, Private and Custom Cloud offerings. As well as prices, the page now covers service levels, RPO/RTO metrics, backup policies and availability guarantees.

That's a sensible move, because technical and commercial decisions aren't really separate. A self-hosted platform might have a cheaper licence than a managed cloud service, but your organisation could still be responsible for infrastructure, upgrades, monitoring, security, backups and disaster recovery. A cloud subscription moves some of that to the provider. Neither is automatically better. What matters is the total cost and the operational responsibility that comes with each.

So don't just ask "What's the licence price?" Ask "What are we responsible for once we've bought it?"

 

Pricing models matter as much as prices

Vendors can charge per agent, per user, per asset, per transaction or per resolution, often with consumption-based AI components on top. That makes comparisons surprisingly hard.

Say Platform A charges per agent, while Platform B charges partly per successful automated resolution. Which is cheaper? You can't say without knowing your agent numbers, ticket volumes, automation rate and growth forecasts.

That's why it's worth modelling scenarios instead of comparing today's invoice. What happens if you double your users? If ticket volumes rise by 50%? If an AI feature takes off and handles thousands more interactions? Ironically, successful adoption can be the thing that changes your cost profile most.

 

Vendors change, and so do commercial models

One variable is much harder to put in a spreadsheet. Products get acquired, portfolios get consolidated, features move between tiers, perpetual licences become subscriptions, and standalone products become part of wider platforms.

To be clear about Fin: whether its pricing will change is an open question, not an announced Salesforce decision. But there are real examples of how things can play out.

Opsgenie. Atlassian acquired Opsgenie in 2018 and gradually built its functionality into the wider Atlassian platform. In 2025, Atlassian ended standalone sales and set end of support for 5 April 2027. Customers are being given migration paths to Jira Service Management or Compass, and Atlassian's guidance specifically tells them to consider licensing capacity and potential costs when planning the move. That isn't necessarily a bad outcome, and customers have a long migration window. But the product you originally bought no longer exists in the same form.

VMware. Outside ITSM, Broadcom's acquisition of VMware brought a major simplification of the portfolio and a full move to subscription licensing, including the end of perpetual licence sales.

The lesson isn't whether either strategy was good or bad. It's that commercial change doesn't always look like "your product now costs 10% more". Sometimes it looks like "the way this product is packaged and licensed has changed", and for customers that difference matters.

 

Think about the cost of getting out

This is probably the most overlooked part of an ITSM business case. What if, three or five years from now, the platform no longer suits you? Your requirements might change, a better option might appear, or the licensing or product strategy might shift after an acquisition.

You can almost always move, but migration has a cost. Service management platforms hold years of tickets, knowledge, workflows, automations, integrations, attachments and reporting structures. The more embedded a platform becomes, the more there is to untangle.

We've seen this first-hand. When PartnerHero consolidated its work management from Monday and Jira into a single Atlassian environment, it was far more than exporting one CSV and importing another. We had to understand the source and destination structures, extract Monday data via API, map fields and subtasks into suitable Jira configurations, run test migrations and train users on the new environment.

That's not an argument against committing to a platform. It's an argument for thinking about portability before you do.

Ask "How portable are we?"

Some dependency on a platform is healthy. If a system works well, people will build workflows, integrations and knowledge around it, and that's where much of its value comes from. The more useful question is how portable you'd be if things changed:

• Can we export our data in useful formats?

• Are APIs available?

• How much business logic sits in proprietary workflows and automation?

• How much do we rely on vendor-specific integrations?

• Is our data structure understood and our configuration documented?

• What would need to be rebuilt elsewhere, and is there a realistic migration route?

You don't need an exit plan before you've implemented your new service desk. But you should know whether an exit is feasible.

 

Don't forget implementation and ongoing support

The licence price doesn't tell you what it costs to make the platform useful. Configuration, migration, integration, training and adoption all add to the investment. After go-live, someone also has to maintain configurations, improve workflows, onboard new teams, build reporting and keep up with changing requirements. That might be an internal team, external specialists or a mix of both.

BDQ, for example, provides flexible Managed Support Services across Atlassian, HaloITSM, Asana, Zephyr, Monday.com and Freshworks. Options range from prepaid Consultation Time Banks to SLA-backed support, so you can choose the level of help you need instead of signing up to a rigid long-term arrangement. Whatever approach you take, include it in your total-cost calculation.

 

A practical ITSM pricing checklist

1. What do we pay today? The basic licence or subscription cost, and exactly what it includes.

2. What drives the price? Agents, users, assets, resolutions, AI consumption, storage or something else?

3. What happens as we grow? Model expected usage, not just today's.

4. Which capabilities need a higher tier? Check automation, reporting, integrations, AI and asset management.

5. What infrastructure is included? Hosting, availability, backups, RPO/RTO, security, and what's left to you.

6. What will implementation cost? Configuration, migration, integrations, testing, training and adoption.

7. What will ongoing management cost? Someone needs to own and develop the platform after go-live.

8. How exposed are we to commercial change? Renewal terms, feature packaging and the effect of a different pricing model.

9. How portable is our data and configuration? Exports, APIs, integrations and documentation.

10. What would it cost to change direction? You don't need to plan a migration now, but understand what one would involve.

 

There's no single "cheapest" ITSM platform

The platform with the lowest licence price isn't necessarily the lowest-cost option. And an expensive-looking subscription can be good value if it removes infrastructure overhead, includes capabilities you'd otherwise buy separately and needs less admin. The right answer depends on your organisation, your requirements and your expected usage.

Products evolve, vendors evolve and pricing evolves. Your business case should be able to cope with that. So before you choose your next service management platform, don't just work out the cost of getting in. Understand the cost of staying in, the value you get while you're there, and how hard it would be to get out.

How BDQ can Help

If you're evaluating ITSM platforms and want an independent conversation about requirements, costs, migration or implementation, get in touch with BDQ. We work across several service management technologies and can help you weigh the options against the outcomes your organisation needs.