How do I compare help desk tool pricing before rolling it out across several departments?
· 4 min read
Compare help desk tools on a full year's cost for your real agents, approvers and requesters in every department, not on the headline monthly price.
In brief
Help desk tools are priced in very different ways. Some charge per agent, some per organisation, some per end user, and some add per seat fees to a base price. That matters most when a tool spreads beyond IT to HR, facilities, finance or legal, because the number of people who need to work or approve tickets can grow quickly. The practical answer is to compare tools on what a full year will cost for your real users rather than on the headline monthly figure. Start by mapping who will use the tool in each department: agents who resolve tickets, people who only approve, requesters and administrators. Write a short statement of requirements first, using the MoSCoW approach John Sansbury recommends in The Journey to Service Excellence, and include whether occasional users can take part without a paid licence. Then ask every vendor the same written questions about how they count users, what limits apply and which features sit in higher tiers. Price the whole life of the tool, including transition, implementation, customisation and maintenance, and model a second year as more departments join. An illustrative example shows how a tool that looks cheapest on its pricing page can cost more once approvers and contractors are charged as full agents. The article closes with common mistakes, such as letting a polished demo or a low list price decide.
Compare help desk tools on what a full year will cost you for the people who will actually use them, not on the headline monthly figure. Before you roll a tool out across several departments, write down how many agents, approvers and requesters each department will have, then make every vendor price that same picture in writing.
Why the headline price misleads
A low monthly price on a pricing page rarely tells you the whole story. Some tools charge per agent, some per organisation, some per end user, and some combine a base fee with per seat charges. When IT is the only department, the difference may be small. When HR, facilities, finance and legal join, the number of people who need to work tickets can multiply, and so can the bill.
John Sansbury lists "the tool with the most favourable pricing" among the arbitrary ways he has seen tools chosen, alongside "the cheapest" and "the most expensive". His advice in The Journey to Service Excellence is to choose against your requirements first and price second.
Practical steps
- Map who will use the tool, by department and role. Separate four groups: agents who resolve tickets, people who only approve or comment, requesters who raise tickets and check status, and administrators. Departments outside IT often have many occasional resolvers, such as a payroll officer who handles a few queries a week.
- Write a short statement of requirements before you look at prices. John recommends the MoSCoW approach (Must have, Should have, Could have, Won't have) built from stakeholder interviews. One of his example should haves is the "Ability for users to update records without needing to pay a licence fee". For a multi department rollout, that line alone can change which tool is affordable.
- Ask every vendor the same written questions. Is the price per agent, per organisation or per end user? Are approvers and occasional resolvers charged as full agents? Are there limits on tickets, workspaces, portals or automations? Which features in your must haves sit in a higher tier? Ask for the answers in the quote, not just in a sales call.
- Price the whole life, not the first month. John's list for total cost of ownership covers the one off purchase price, recurring licence fees, transition costs from your current tool, implementation and configuration fees, customisation fees, and ongoing maintenance. He also warns that "Some providers include a certain number of support days within their price and others include free maintenance, so it is not always easy to compare."
- Model growth. Price year one with IT and HR, then year two with every department you expect to join. A tool that is cheap for ten agents can become expensive at sixty.
- Plan for the move itself. John notes that records rarely transfer cleanly between service management toolsets, so you may run old and new tools side by side for a while. Budget for that time.
A short worked example
This is an illustrative example, not a client case. An organisation plans to run IT, HR and facilities on one help desk. IT has eight agents. HR has four full time advisers and six managers who approve requests. Facilities has three coordinators and a dozen contractors who update jobs.
Tool A looks cheapest on its pricing page, but charges every approver and contractor as a full agent, so the team is paying for thirty three seats. Tool B costs more per seat but gives approvers and contractors who only update their own jobs a free collaborator role, so it charges for fifteen agents. Tool B also includes the self service portal that Tool A sells as an add on. Once the team builds a year two model with finance joining, Tool B is the lower total cost, and it meets every must have.
Common mistakes
Comparing list prices instead of quotes built on your own user numbers.
Counting only IT. Each new department brings its own pattern of agents, approvers and requesters.
Letting the demo decide. As John puts it, "Consider the MoSCoW approach, which will ensure that you select a provider based on a definition of your requirements rather than either a compelling pitch or an attractive price."
Ignoring tier boundaries. A key feature such as approvals, a portal or reporting may only be in a higher plan.
Forgetting the people who will run it. Configuration, administration and change control take effort in every department, whatever the licence model.
Where the standards fit
Frameworks will not tell you which pricing model to choose, but they help you set the requirements. ITIL, now owned by PeopleCert, and ISO/IEC 20000-1, the international standard for service management systems, both treat service management as something an organisation runs consistently across its services. That is a useful reminder that a multi department help desk is a shared service, and its costs and ownership should be agreed as one.
Next step
For more on choosing and sourcing tools, browse the tools and sourcing articles on ESM's Exchange.
If this helped, John Sansbury's The Journey to Service Excellence covers tool selection, MoSCoW and total cost of ownership in depth, and is available to Exchange members.
Tags: esm-questions, tools-and-sourcing, service-desk, total-cost-of-ownership, enterprise-service-management
Sources
Join the Exchange free
Join free to unlock the complete knowledge library.
Founder membership is free for life
More from Esm
How should the service desk handle a Microsoft 365 outage it cannot fix?
4 min read
Deploying AI is the easy part: who runs it once it goes live?
5 min read
Turning 'not helpful' into a fix
1 min read
When the author leaves, who owns the article?
2 min read
Test after every change, or find out from users
1 min read
Designing a knowledge portal people want to use
1 min read
Related articles
How should the service desk handle a Microsoft 365 outage it cannot fix?
Treat a supplier cloud outage as your own major incident: log it once, tell people early on a channel that still works, update on a rhythm and review your dependency afterwards.

Deploying AI is the easy part: who runs it once it goes live?
Only a third of large enterprises have met the business case for their main AI programme. New research points to a gap in who runs AI after launch, and what leaders can do.
Turning 'not helpful' into a fix
'Not helpful' is free, honest feedback, and most of it goes nowhere. Turn that click into a fix.
When the author leaves, who owns the article?
Articles keep being read after their authors move on. Make sure the care for them does not leave too.
Test after every change, or find out from users
Knowledge changes fail quietly. A short, repeatable test after every change finds the problem before your users do.
Designing a knowledge portal people want to use
Most knowledge portals are built for the people who run them, not the people who arrive with a problem.
