Free ticketing system: where the free tiers stop, and how to test one properly
A free ticketing system is often the right call. Support volume is unpredictable early on, most teams genuinely do not need an enterprise workbench, and the free tiers of serious products are more capable than they were five years ago.
The thing to understand before you commit is that free help desk plans are almost never capped on tickets. They are capped on agents. That distinction decides everything, because ticket volume is the thing you cannot control and agent count is the thing you were going to grow deliberately.
This page covers the four kinds of free IT ticketing system, what the free tiers actually drop, and a test you can run in an afternoon that tells you more than any comparison table.
The four kinds of free
1. The free tier of a commercial help desk
The most common and usually the fastest start. A capped version of a paid product, hosted, working in an hour.
What it costs you: the agent cap, and what sits behind it. Free tiers are priced to be genuinely useful for one to three agents and to become a subscription at four. Since a support team grows by adding people, the cap is aimed precisely at your growth.
Check what the first paid tier costs per agent per month, then multiply by the team you expect in two years. That is the real price of the free plan.
2. Open source, self-hosted
Genuinely free software you run yourself. No agent caps at all, which is the single biggest structural advantage — a free helpdesk ticketing system that does not charge per seat changes how a team behaves, because everyone gets their own login instead of sharing one.
What it costs you: operations, and specifically inbound email, which is harder than it sounds. We have covered this in detail: open source ticketing system.
3. Marketplace scripts
A one-off purchase, source included, sold as a complete help desk. Not free, but cheap enough to sit in the same decision.
What it costs you: the integration ceiling. In our counted set of 18 real help desks, a REST API appeared in all 14 SaaS and open-source products and zero of the four marketplace scripts — and SLA tracking showed the identical pattern. A cheap script will take tickets competently and will never connect to anything else you own.
4. A shared mailbox
Worth naming, because it is what most teams actually use before they adopt anything, and for a very small team it is defensible.
What it costs you: everything the counted list below describes. No assignment, so two people reply to the same customer. No status, so "did anyone deal with this" is a question you ask out loud. No history when someone leaves. The moment those cost more than an hour a week, a free trouble ticketing system is a straight upgrade.
IT service desk or customer support desk — decide first
The most-searched term in this category is a free IT ticketing system, and it is worth separating that from a customer support desk, because the products diverge and the free tiers diverge with them.
An IT ticketing system serves colleagues. The requester is internal, usually identifiable from a directory, and the work is often about a thing — a laptop, an account, an access request. That implies capabilities a customer desk does not need: an asset register, approval steps before an action, a service catalogue of standard requests, and categories that map to infrastructure rather than to products.
A customer support desk serves people outside the company. The requester may be anonymous, the volume is less predictable, and the work is about your product. That implies a public portal, knowledge-base deflection, satisfaction ratings, and often chat.
The overlap is real — both are tickets with statuses and assignment — but the free tiers make different sacrifices. Free IT-oriented tiers usually cap assets and drop approvals. Free customer-oriented tiers usually cap agents and drop deflection and automation.
Choose the wrong side and the cap you hit makes no sense to you. A team doing internal IT on a customer-support free tier finds itself with generous portal features it never uses and no way to record which machine a ticket is about. Write one sentence — our tickets come from X and are about Y — before you look at any product.
What free tiers actually drop
Free plans rarely remove the obvious things. They remove the operational layer. From our counted set of 18 help desks, ranked by prevalence:
| Capability | Found in |
|---|---|
| Ticket lifecycle and statuses | 18 of 18 (100%) |
| Auto-assignment and routing | 17 of 18 (94%) |
| Custom fields | 17 of 18 (94%) |
| Automation — trigger, condition, action | 16 of 18 (89%) |
| REST API | 14 of 18 (78%) |
| SLA tracking with breach views | 13 of 18 (72%) |
| Live chat | 13 of 18 (72%) |
| Collision detection | 10 of 18 (56%) |
| Knowledge-base deflection on the portal form | 10 of 18 (56%) |
Everything takes a ticket. What free tiers typically hold back, in rough order of how much you will miss it:
Automation. Present in 89% of products overall and frequently the first thing gated. Without it, somebody manually routes every ticket to the right person, every day, forever. This is the largest hidden cost of a free plan and it is paid in salary.
SLA tracking. Response and resolution targets with a view of what is about to breach. Nearly three quarters of products implement it; free tiers rarely do. If you have made any promise about response times, you are tracking them in a spreadsheet without it — which is exactly the thing you adopted a ticketing system to stop doing.
The API. Gating integration is the standard upgrade lever. It matters more than it sounds, because it is how tickets get created from your app, your monitoring, and your other systems rather than by a human copying details across.
Collision detection. Interestingly not usually a free-tier casualty in self-hosted desks, but commonly plan-locked in commercial ones. With two agents it does not matter. With five it is the difference between one reply and two contradictory ones.
Testing a free ticketing system in an afternoon
Run these six. They take less time than reading comparison articles and they surface the things that actually hurt.
- Send a ticket in by email, reply, and have the customer reply again. The whole exchange must stay one ticket. If the customer's reply opens a second ticket, threading is broken and every metric you ever produce will be wrong.
- Reply from the desk and check where it lands. Send to a Gmail account and an Outlook account. If replies go to spam, the desk is unusable regardless of its features.
- Have two people open the same ticket. Does either see a warning? Then have both reply. Some systems will happily send two answers to the same customer.
- Add a custom field and filter on it. If you cannot add the one piece of information your business runs on — order number, asset tag, account tier — everything ends up in free text where it cannot be reported on.
- Build one automation rule. Route tickets containing a keyword to a specific person. If the free tier cannot, price the human hours that rule would have saved.
- Close a ticket, then find it three weeks later. Search across closed tickets, by customer and by content. Weak search is the quiet failure that makes people stop trusting the system and go back to the mailbox.
Moving off a shared mailbox without losing anything
Most teams adopting their first free trouble ticketing system are coming from a shared inbox, and the migration has two traps.
History does not come with you, and people need it. Almost no free tier imports years of mail into tickets. The practical approach is to leave the old mailbox in place, read-only, and keep it searchable for a year — but stop it receiving new mail on day one. A mailbox that still receives is a mailbox people still answer from.
Do not migrate mid-conversation. Pick a cut-off and let open threads finish where they started. Trying to move a live exchange into a new system produces a ticket with no context, and the customer gets a reply that reads like nobody remembers them.
Then three things worth doing in the first week:
- Forward, do not redirect. Set support@ to deliver into the desk rather than asking staff to log in somewhere new to check for work. Adoption follows the path of least resistance.
- Create the five statuses you will actually use and delete the rest. Every desk ships with more than any team needs, and unused statuses become a place tickets go to die.
- Agree what closed means. Resolved-and-told-the-customer, or resolved-internally? Two people using one status for two meanings is the fastest way to make reporting worthless.
When free stops being free
The transition is more predictable here than in most categories.
The agent cap arrives first, usually with the third or fourth hire, and it arrives as an immediate subscription for the whole team rather than for the extra person.
Then the manual routing cost, which is invisible on an invoice. If someone spends thirty minutes a day sorting tickets that a rule could route, price that annually and compare it against the paid tier. It usually loses.
Then the integration wall, when you want your own product to raise tickets automatically and the API is gated.
None of that means start with a paid plan. It means know which of the three you are approaching, so the upgrade is a decision rather than a surprise.
The option worth considering at that point
When a free plan runs out, the reflex is to compare paid tiers. There are two other answers worth weighing first. If you already run an engineering issue tracker, using Jira as a ticketing system works through whether it can carry support too and where that stops. And whichever way you go, IT ticketing system has the counted feature list from 18 real help desks with a test for each capability.
The third answer only recently became sensible: build the desk your process actually needs.
Help desks are a strong case for this, because they are unusually workflow-shaped. Every team routes, escalates and closes differently, and most of the friction in adopting any product is bending your process to fit its assumptions. Owning the software removes that permanently — and a coding agent can now produce a working ticket workbench in a couple of days.
Two honest caveats. Inbound email is the hard part, exactly as it is with self-hosting — threading, spam and deliverability are more work than the ticket interface. And left to guess, an agent builds the list and the detail view beautifully, then stops before the automation engine, SLA breach tracking and collision detection — which is to say, before the parts that separate a support desk from a shared inbox with extra steps.
Open source ticketing system covers the self-hosted route in detail, including where open source beats the paid products. And if you are building, the Helpdesk Ticketing planner is the specification we hand our own coding agents — lifecycle, routing, SLA model and the controls that make a desk worth replacing a subscription with.