Per-agent help desk pricing: when it stops making sense
Per-agent pricing is fair when a help desk is doing a lot for you. It becomes awkward when headcount grows faster than the value you take from the product.
Most help desk products are priced per agent per month. That is a reasonable model: more people using it, more you pay. It also means your bill tracks the size of your support team rather than how much of the product you actually use — and those two can diverge a long way.
The question worth asking is not whether the software is good. It usually is. The question is whether what you use of it is worth what the seats cost you.
A short, honest audit
List the features your team touched in the last month. Not the ones that sold you the product — the ones someone genuinely used. For a lot of teams the list is shorter than expected: a shared inbox, assignment, canned replies, tags, a simple report, and an integration or two.
Then note which of those would be hard to live without. If the honest answer is a shared inbox with assignment and history, you are paying enterprise seat pricing for a workflow that open-source help desks handle well.
Where the commercial product genuinely earns it
There are good reasons to stay, and they are worth being clear-eyed about. Deep integrations you depend on. Compliance or audit requirements the vendor satisfies for you. A large knowledge base with established search behaviour. Routing or automation that is doing real work. Volumes that need serious scale.
If any of those apply, switching is likely to cost more than it saves, and the better investment is to connect the product properly to your other systems so your agents stop retyping what another system already knows.
What the self-hosted route actually involves
Open-source help desks cover the common ground well: shared mailboxes, assignment, notes, tags, canned replies, history, and reasonable reporting. The cost moves from per-seat to a server, which usually means adding people stops changing the bill.
What you take on is operation: the application has to be hosted, kept patched, backed up, and watched — and email deliverability becomes your concern, which deserves respect rather than being discovered later. That is the real work in self-hosting, and it is why we manage it rather than handing over a login.
Migration is the part to plan properly
Moving a help desk is mostly about history. Past conversations need to stay readable and searchable, attachments need to come along, and users need to map correctly, or your team loses the context that makes them effective.
It is a well-trodden project rather than a risky one, but the verification step — checking counts and spot-checking real threads after the move — is the one most worth keeping in scope.
Count the seats you are actually paying for
Before comparing products, it is worth checking who holds a licence. Teams accumulate seats: someone who left, a manager who looks at a report once a quarter, a developer added during a project that finished.
Many products also distinguish between a full agent and a lighter role that can comment internally without a full licence. Moving occasional users onto the cheaper tier, or releasing seats nobody uses, sometimes resolves the whole question without changing anything else. It is the first thing to look at, because it costs nothing to check.
The question underneath all of this
Whichever product you use, the thing that most improves support is rarely the help desk itself. It is whether an agent can see what the customer bought, when, and what went wrong — without opening three other systems.
That is an integration problem, and it is worth solving before changing vendor. Sometimes it turns out to be the only change you needed.