The decision turns on what you plan to run next year
ServiceNow gets bought for capability the buyer has no near-term plan to use. It also gets bought for reasons a lighter service desk tool cannot match at any price. Both happen often enough that arguing the general case leads nowhere. The question that pays is which of those two organisations you work in, and the answer sits in what your team has committed to deliver over the next twelve months.
I work the integration side of these programmes, so I meet the decision after it has been made and get to watch how it aged. Teams that got value from the larger platform had a second and third thing they needed it for before the first went live. Teams that regretted the spend delivered incident and request, stopped there, then met a renewal priced for everything they had not built.
Both outcomes came from the same product, so quality is not what separates them. What separates them is whether the organisation had work that needed a platform underneath it, and whether anybody was employed to do that work.
What a lighter service desk covers properly
A team that needs tickets captured, routed to the right group, a knowledge base people search and a report the service desk manager trusts can have that running in weeks. The lighter products are built around those four things and little else. Setup means a handful of queues, a category list, an email address and a portal, done by the people who will run it.
The administration saves more than the licence does. A lighter tool needs no named administrator tracking twice yearly platform releases, regression testing customisations and running a development, test and production pipeline. Changes happen in an afternoon, by the service desk lead, in the live system, because a queue change affects one queue.
Reporting is the part buyers expect to lose and usually do not. First response time, resolution time, volume by category, backlog by group, reopen rate. If leadership questions stop there, a lighter tool answers them without anyone building a thing. The gap opens when somebody asks which business service an outage affected, because that answer needs data a lighter tool has nowhere to keep.
The point where the lighter tool starts buying parts
Four requirements change the arithmetic. A configuration management database that genuinely feeds change and incident. Service level commitments that have to hold across several teams on different working hours. Workflow that leaves IT and lands in HR or facilities. Applications your own people build on the platform the service desk already runs on. Any one of those and the larger ITSM platform starts earning its price.
The CMDB is the hardest of the four to add later. Lighter tools carry an asset list, which tells you who has which laptop. It will not tell you that the database cluster behind the claims portal is the thing failing, and which change touched it last Thursday. Getting a CMDB into a state where something can read it is slow and political, and no product makes it faster. A tool with nowhere to hold relationships makes it impossible.
The cross-department requirement gets underestimated most. The moment a new starter needs a laptop from IT, a desk from facilities, a payroll record from HR and a badge from security, all moving under one request with one status, you need a workflow engine that owns records outside IT. You can wire that across three systems with integrations instead. I have built those, and I would rather not maintain them through the next joiner policy change.
Building applications is the fourth. If your platform team has a real queue of small process apps waiting, building them where the approvals and catalogue already run saves months per app. Check the queue exists, with names against it, before paying for the capability.
The insurer that bought a platform and ran a ticket queue
I spent eight months at a general insurer of roughly two and a half thousand staff, moving data between their instance and everything around it. They had bought ITSM and a CMDB the year before. Eighteen months after go live they were running incident, request and a knowledge base. Nothing else.
The CMDB held about nine thousand records from a discovery run and almost no relationships. Nobody had populated the service map, so change impact analysis was a free text field somebody typed a guess into. The service catalogue carried eleven items, all of them IT. There was no platform owner, only an infrastructure manager who also ran the virtualisation estate and gave the instance perhaps a day a week.
Their real usage would have fitted a lighter tool with room left over, and the infrastructure manager said so in a review. What kept them there was a plan nobody had been resourced to deliver. Every year somebody produced the slide about HR onboarding and facilities requests, and every year the two people who could have built it were busy keeping incident and request healthy. They had bought a capability and had not bought the person who would turn it on. Hiring a platform owner with a mandate to put two non-IT services live within the year changed more than any tool swap would have.
Signals that you will use a fraction of it
The strongest predictor of overbuying is the absence of a named platform owner. Not a project manager for the implementation. A permanent person whose job is the platform after the implementers leave, with a budget line and the standing to refuse configuration requests. If you cannot name them and their start date before you sign, you are buying capability you have nobody to operate.
The second signal is a roadmap that stops at incident and request. Ask what goes live in year two. If the answer is a list of module names rather than a named service with an owner and a date, it is ambition rather than plan. Scoping the programme before the build starts is where year two commitments get names attached or quietly disappear.
The third signal is quieter. If every requirement came from the service desk, you have specified an IT ticket tool and you will be charged for a platform. The ones that justify the bigger purchase come from the HR director tired of onboarding spreadsheets and the facilities manager who wants a request status people can look up. Licences nobody uses are the visible half of the waste. The rest is internal time spent running a platform at a fraction of its output.
Leaving costs money whichever way you go
Exit costs are real in both directions and shaped differently. Leaving a lighter tool means moving ticket history, knowledge articles and a category structure, plus an argument about how much history to carry. A few months of work, survivable because the configuration you abandon is thin.
Getting out of the larger platform gets harder in proportion to how well you used it. Custom applications, flows, integrations, service definitions and years of access control decisions do not export anywhere useful. I watched a team scope that exit and stop three weeks in, not because a contract trapped them but because too much of the business depended on what they had built and nobody could describe it fully enough to rebuild.
Lock-in runs the other way too. A lighter tool that keeps growing collects a survey add-on, an asset add-on, a change approval add-on and two integrations somebody wrote and then left. Each carries its own vendor, renewal date and owner, and the combined bill can pass what the single platform would have cost.
Before the next selection or renewal, write two sentences and take them into the meeting. Name the service outside IT going live within twelve months, and name the person who will own the platform the day the implementers leave. If either sentence needs a placeholder, buy the smaller thing this year. Moving up later costs money you can estimate, and moving back down costs a conversation nobody wants to have twice.
