A few years ago I sat in on a quarterly service review at a manufacturing company, mid-sized, three sites, the usual sort of setup. The slide on the wall said first-contact resolution was sitting at ninety-one percent, and everybody in the room seemed reasonably pleased about it, and honestly, on the face of it, why wouldn’t they be? That is a good number. Then we broke for coffee, and I ended up standing next to one of the site engineers. I asked him the lazy question you ask when you are making conversation, which was something like, “So how is it going on the floor?” And he said, and I am quoting him almost exactly here, “Fine, I just fix most of it before it gets to the system.” Sadly, it was an unwanted byproduct of their IT service management (ITSM) tool license model.
“I Just Fix Most of It Before It Gets to The System”
I have thought about that sentence probably once a month ever since.
Because he wasn’t being difficult, going rogue, hiding anything, or working around a process out of spite. He was doing what the ITSM tooling had trained him to do over about two years, without anybody ever writing it down as a policy or so much as discussing it in a meeting. And what trained him wasn’t the workflow, the catalog, or the ITIL practice we had all sat in a room and so carefully designed. It was the license model.
The Number Of Seats Is A Process Decision
Here is the bit that I think we collectively skip past. When procurement signs a per-agent ITSM tool contract, everybody in the room treats it as a finance decision. It goes in a finance conversation, lands on a finance line in the budget, and the service owner is usually asked one question: how many seats do you need? They give a number, and that number gets negotiated down a bit. Then everyone moves on to the next agenda item.
But that number is not a finance output. That number is a process constraint, and it is probably the single most powerful one in your whole service management design, because it decides who is physically permitted to touch the queue.
Think about what your beautifully mapped incident process actually assumes. It assumes that when work happens, the person doing the work records it. Every single downstream thing you care about hangs off that one assumption. Your trend analysis hangs off it. Your problem management hangs off it, especially the proactive kind, which depends on somebody somewhere seeing the same small, irritating thing happen forty times before it ever gets a chance to become the big thing that takes a site down. Your configuration management database (CMDB) accuracy hangs off it. Your capacity planning, your knowledge base, your automation candidates, your business case for headcount, all of it, right down to the report you take to the board.
And then we go and buy the tool in a way – the license model – that makes recording work cost money per person.
A Small License Model Example With Round Numbers
Let me make this concrete, because in the abstract the license model issue sounds small, and it really isn’t.
Say you have an IT service desk of twelve people. You are paying around $80 per agent per month, so twelve seats works out to roughly $11,500 a year, and nobody blinks at that; it is a perfectly normal number for a perfectly normal IT service desk.
Now, behind those twelve people you have got another twenty-odd humans who touch support work regularly without ever being called IT service desk staff. Two field engineers, a handful of application specialists who get pulled in whenever the finance system misbehaves, the one person in the warehouse who everybody rings about the label printers, you know the one; every organization has got one of them. A couple of developers who take escalations, and the site lead who fixes things because they happen to be standing there, and it is faster than raising something.
Twenty more seats at $80 is another $19,000 a year. Now the total is over thirty thousand dollars, and that is the exact moment somebody very sensible indeed says, hang on, do all of those people really need a license? And of course, framed that way, the answer is “no,” they are not IT service desk staff; they handle maybe three or four things a week each, and paying one thousand dollars a year for somebody to log fifty tickets is genuinely hard to defend on a spreadsheet in front of a finance director.
So they do not get a license, and I want to be clear: it is a defensible decision on the day it is made.
What happens next is that those twenty people carry on doing the work anyway, because the work does not go away just because the license did. They simply do it somewhere else. It goes into email, into Microsoft Teams messages, into a corridor conversation on the way to the canteen, into a shared mailbox that nobody reports on, or into somebody’s own head. Fifty tickets a week that used to be visible are now invisible, and you can multiply that by fifty-two if you want to ruin your afternoon.
And your first-contact resolution goes up. Obviously it goes up: you have quietly removed all the hard cases from the denominator and handed them to people who aren’t being counted in the first place.
Nobody Did Anything Wrong, And That Is The Annoying Part
I want to be fair to everyone in this story, because there is a version of this article that is just vendor-bashing, and it would be both boring and untrue.
The finance team was right that twenty part-time users at full sticker price is poor value; they were right, and anybody looking at that line on a renewal quote would have said exactly the same thing.
The vendors are not being wicked either. Per-agent pricing license models exist for perfectly ordinary reasons: it is simple to explain, easy to forecast, loosely maps to the cost of serving the customer, and is what the market got used to buying. If you have ever tried to build a pricing model, you will know that “simple and predictable” wins over “clever and accurate” nearly every time.
And the service owner wasn’t asleep at the wheel either; they asked for the seats and were told “no.” They don’t really have a next move in that conversation, because they cannot articulate the cost of the very thing that is about to stop being measured. How do you build a business case for data you do not have yet? You cannot, and that is the trap, and it is a quiet one.
License Models: Where It Quietly Goes Wrong
The damage does not arrive all at once, which is why it is so easy to miss.
First, the tail disappears long before the head does. The big incidents still get logged; they are far too visible not to be. What stops being logged is all the small repeated stuff: the label printer, the report that fails on the first Monday of the month, the login that needs clearing every few weeks. And that small repeated stuff is precisely the raw material of problem management. So you keep your incident data and quietly lose your problem data. The two don’t feel separate on a dashboard, so nobody notices for a long time.
Second, your knowledge stops being written down and starts being remembered instead. The warehouse chap knows the printer thing; he has always known the printer thing. It is just not in the knowledge base because he’s never had a way to put it there, and it will walk out of the building the day he does.
Third, and this one takes a good eighteen months to show up, your automation program quietly runs out of candidates. Everyone wants to automate the repetitive work. But you can only ever automate what you can see the shape of. The license model filtered the repetitive work out of your data set long before anybody went looking for it. Hence, the automation team goes hunting for high-volume low-complexity patterns, finds surprisingly few of them, and concludes that the IT service desk must already be fairly efficient, which is not remotely what is happening.
Fourth, and this is the worst of the lot, you end up making a headcount decision based on it. Somebody eventually looks at ticket volumes, sees them flat or gently falling, and quite reasonably suggests the team is already right-sized or could even shrink a bit next year. The real workload hasn’t fallen anywhere; only the recorded workload has.
The Honest License Model Bit: Per-Agent Pricing Is Not Actually The Villain
Now let me argue against myself for a minute, because I have watched people take this argument too far.
Unlimited access isn’t an automatically better license model, and I have watched it go wrong more than once. If you throw the ITSM tool open to absolutely everybody without thinking it through, you get a different set of problems entirely, mainly duplicate records, half-finished tickets sitting there for weeks, four people picking up the same thing on the same morning, and a queue that nobody really feels any ownership of. Constraint isn’t always the enemy here; sometimes a small licensed team is exactly what a small, tidy process needs and bolting thirty casual users onto it would make the data considerably worse rather than better.
There is also a version of this where the shadow queue is a symptom and not a cause. If your logging experience takes four minutes and eleven mandatory fields, people will avoid it whether they have a license or not, and no amount of pricing reform will fix that. I have seen organizations move to an all-you-can-eat license model and get almost no change in behavior, because the friction was never the license; it was the form.
So it is not a rule; it is a question, and you have to answer it for your own organization rather than sit there and assume.
What To Actually Do About It
Right, the practical bit. Here is roughly the sequence I would run, and none of it is difficult; it is mostly just a little bit uncomfortable.
Start by counting the people rather than the seats. Get yourself a list of every single human who resolves an IT issue for somebody else in a normal month, whatever their job title happens to say on the org chart, so that is field engineers, super-users, the departmental fixers, the developers who take escalations, all of them. You will nearly always find the real number lands somewhere between two and three times your licensed number, and just seeing that gap written down on one page tends to change the conversation all on its own.
Then go and find the shadow queue, and do it gently. Ask three or four of those unlicensed people to keep a tally for two weeks, not a ticket, just a tally, a note on a bit of paper, whatever is easiest for them. What did you fix? Roughly how long did it take? Two weeks of that is genuinely enough to work with. You are not building a case against anybody here, and it is very much worth saying that out loud to them before you start, because otherwise you will get nothing useful back.
Now price the invisible work. Take the tally, annualize it and cost it at a sensible internal rate. That figure is what you take back to finance, and it is usually the first time anybody has been able to put a number against the missing data. It is a lot more persuasive than “We would like more seats, please.”
Then, and this is the part most people skip entirely, go back to your ITSM tool vendor and ask specifically about the tiers rather than the total. Most ITSM tool vendors do have some sort of lighter contributor or collaborator level sitting there, some of them free, some at a fraction of the full agent price, and in my experience it is very often not printed on the public price list. The account manager won’t mention it until you ask directly. Ask what a read-and-update-only user costs. Ask what a two-tickets-a-week user costs. You will be surprised how often something exists.
And if the answer genuinely is that every human who touches the queue must be a full-price agent, then treat that as a real evaluation criterion at renewal, weighted properly, alongside the feature grid. It is definitely as important as most of the things that do get scored.
A small but growing group of vendors is now building IT helpdesk tools without per-agent licensing at all. It is worth including one of them in your next RFP as a price anchor, even if you have no intention of switching.
Last thing: whatever you end up doing about licensing, cut the logging friction anyway. Fewer mandatory fields, a proper email-in route, a way to raise something in thirty seconds from a phone in a plant room. Do that even if the seat count never changes, because the friction and the license model are two separate taps feeding the same shadow queue, and closing one while leaving the other wide open will not get you very far.
One Last Thought on License Models
We spend an enormous amount of care on our processes. We map them out properly, we get them assessed by somebody external, we argue for weeks about practice names, we run improvement cycles on them year after year, and then we go and buy the ITSM tool in a completely different room on a completely different set of criteria, and the ITSM tool quietly overrules the whole lot of it by deciding who is allowed to use it.
The engineer at that manufacturer wasn’t breaking the process at all; he was following the real one, and the real process is only ever whatever the tooling makes easy. The license model matters far more than most of us care to admit.
It’s worth counting your people before your next renewal, anyway.
Note – the provider of this article is Jay of Maxdesk.ai, but no author details have been provided yet.
ITSM License Model FAQs
Because the number of licensed seats decides who is allowed to touch the queue. The whole incident and problem management process assumes that whoever does the work records it, so when people who resolve issues regularly don’t get a license, their work stops appearing in the data.
They keep doing the work, just not in the ITSM tool. It moves into email, Microsoft Teams messages, corridor conversations, or a shared mailbox nobody reports on, so tickets that used to be visible disappear from the numbers entirely.
Not automatically. Opening the tool to everyone without changing the process can create duplicate records, half-finished tickets, and a queue nobody owns. Sometimes the real barrier is the logging experience itself, several mandatory fields and a slow form, and no pricing change will fix that on its own.
Start by counting every person who resolves an IT issue in a normal month, not just the licensed agents. Then ask a handful of unlicensed people to keep a simple two-week tally of what they fixed and how long it took, and cost that against an internal rate before taking it back to finance.
Some vendors offer lighter contributor or collaborator tiers that aren’t listed on the public price sheet, and a smaller group of vendors now sell ITSM tools with no per-agent pricing at all. Both are worth raising directly with an account manager or including in a renewal RFP as a price anchor.
Stephen Mann
Principal Analyst and Content Director at the ITSM-focused industry analyst firm ITSM.tools. Also an independent IT and IT service management marketing content creator, and a frequent blogger, writer, and presenter on the challenges and opportunities for IT service management professionals.
Previously held positions in IT research and analysis (at IT industry analyst firms Ovum and Forrester and the UK Post Office), IT service management consultancy, enterprise IT service desk and IT service management, IT asset management, innovation and creativity facilitation, project management, finance consultancy, internal audit, and product marketing for a SaaS IT service management technology vendor.
