An internal help desk is three different products wearing one name. A portal where people find things, a queue where work gets tracked, and an answering layer that replies directly. Most teams buy one and need another.
TL;DR
- Sort a fortnight of inbound into incidents, requests and questions. The proportions pick the shape for you.
- Incidents and requests need a queue. Questions do not, and a queue makes them look organised rather than fewer.
- A portal only works if people travel to it, and below 15 per cent monthly visitor share they have already decided not to.
- An answering layer replies where people already are, which is the only shape that removes a step rather than adding one.
- Per-agent pricing charges for resolvers, so a queue gets expensive as more people pick up tickets.
- Most teams under 300 people have a question problem and buy a queue, which is the expensive mistake in this category.
The three shapes of an internal help desk
A portal. Somewhere to look things up: how to request a laptop, what the expense limit is, where the VPN instructions live. Solves findability. Does nothing about whether anybody visits.
A ticket queue. Work arrives, gets assigned, gets tracked, gets closed. Solves accountability and visibility. Does nothing about volume, because a tracked question is still a question somebody has to answer.
An answering layer. Trained on your own documentation, replies in the tool people already have open. Solves repeat questions. Does nothing about work that needs doing, because explaining how to request something is not provisioning it.
Those three are complements rather than competitors, which is why vendors can sell any of them as the answer. The question is which one your actual inbound needs first.
The count that decides it
What to do: log every inbound item for two weeks and tag each one as incident, request or question. An incident is something broken. A request is something to be provisioned or approved. A question is somebody wanting to know how something works.
| Dominant type | What it means | Shape to buy first |
|---|---|---|
| Incidents | Things break and need diagnosis | Ticket queue |
| Requests | Provisioning and approvals | Queue with request fulfilment |
| Questions | Documented answers people cannot find | Answering layer |
| Even split | Two problems, usually sequential | Queue first, then answers |
The pattern we see repeatedly in teams under 300 people is that questions dominate and a queue gets bought anyway, because a queue is what the category sells and because tracked volume feels like progress. Six months later the volume is identical and better documented.
Why portals underperform
A portal is a destination, and destinations have a traffic problem that no amount of information architecture fixes.
Measure monthly unique visitors as a share of headcount. Above about 40 per cent you have real adoption and improving the portal is the highest-return work available. Below about 15 per cent your people have effectively decided not to travel, and a redesign will confirm that rather than reverse it.
The usual cause is not bad organisation. It is that forming a search query and opening a tab costs more effort than messaging a colleague, at the exact moment somebody wants an answer. That is a distribution problem rather than a content problem, and it is why delivery beats destination for the question half of the workload.
Checklist for a portal that works:
- A last-reviewed date visible on every page
- One named owner per content area
- Search tested against your employees’ words, not your policy’s words
- Reachable on a phone without a VPN
- An obvious next step when the page does not answer the question
What each shape costs
Every figure below was read from the vendor’s own page on 15 October 2026, and the bases differ more than the numbers.
For a queue, Freshservice publishes Starter at $19, Growth at $49 and Pro at $99 per agent per month, all billed annually, with an AI add-on at $29 per agent per month on top.
Jira Service Management publishes a free tier to three agents, then Standard at $21.50 and Premium at $55.28 per agent per month, which is the cheapest credible queue for a small team.
For an answering layer, Matram publishes $29 Basic, $69 Standard and $199 Pro per month, flat, with unlimited seats and a 30-day trial that takes no card. Disclosure that should shape how you read this: Matram is owned by the same people who publish this site.
Where that shape struggles, stated plainly: there is no free tier; it answers questions but does not action tickets, so nothing gets provisioned or closed; and it is not an ITSM platform, so there is no asset register and no change management. If your count says requests dominate, this is the wrong purchase.
The structural point is that a queue charges per resolver and an answering layer at a flat rate charges per nothing. As more people pick up tickets a queue gets more expensive, while the answering layer does not move. Neither is better; they bill against different things.
Running all three without confusing anybody
Above roughly 400 people most teams end up with all three, and that is a reasonable destination provided the boundaries are clear. What breaks is not the tooling but the labelling.
What to do: give people one place to start and route behind it. If that is not possible, label the doors explicitly and repeat the labels. “Ask the assistant for how things work, raise a ticket for anything that needs doing” is a sentence people can retain.
What does not work is two unlabelled doors, which is what you get when the queue and the assistant are bought by different people in different quarters. Employees form their own theory, guess wrong twice, and go back to messaging a colleague.
Check the published figures yourself before committing: Freshservice, Jira Service Management and Matram all publish openly, and prices in this market move within weeks.
Final thoughts
The decision about an internal help desk is not really a product decision. It is a counting exercise that takes two weeks and tells you which of three problems you have, and it is the step almost everybody skips in favour of comparing features.
If incidents and requests dominate, buy a queue and pick on agent arithmetic. If questions dominate, a queue will file your volume rather than reduce it. And if your portal exists but nobody visits, stop redesigning it and move the answers to where your people already are.
What is an internal help desk?
It is any arrangement for handling requests and questions from your own staff rather than from customers, and in practice the term covers three different products: a self-service portal, a ticket queue, and an answering layer over your documentation. The confusion matters because they solve different problems, and buying the wrong shape produces a system that works exactly as designed while changing nothing about your workload.
Do we need a ticket queue or just better answers?
Log two weeks of inbound and tag each item as an incident, a request or a question. If incidents and requests dominate, you need a queue for accountability and tracking. If questions dominate, which is common below about 300 people, a queue will organise your volume without reducing it, because a tracked question still needs a human answer.
Why does nobody use our self-service portal?
Usually because travelling to it costs more effort than messaging a colleague, not because it is badly organised. Measure monthly unique visitors as a share of headcount: above 40 per cent you have real adoption worth investing in, and below 15 per cent your people have decided against it. At that level a redesign tends to confirm the decision rather than reverse it.
How many agent licences will we need?
Count the people who will close tickets rather than raise them, then add the ones you forgot: whoever handles hardware, whoever approves access, and anybody covering another timezone. Teams underestimate that list by roughly a third, and every per-agent product bills against it. Check separately whether approvers need a paid seat, since vendors differ and it changes the total.
Can one tool do all three jobs?
Some products claim to and most do one well and the others adequately. The practical approach is to buy for the problem your count says dominates, run it properly, and add a second shape when the first is working rather than at the same time. Two half-configured systems serve people worse than one that does its job, and the integration between them is where most of these deployments actually fail.
What if we have all three already?
Then the work is labelling rather than buying. Give people one place to start with routing behind it, or label each door explicitly and repeat the labels until they stick. The failure mode is two unlabelled entry points bought by different people in different quarters, which leaves employees guessing, getting it wrong, and returning to messaging a colleague.
