IT ticketing system: what it has to do, counted across 18 real help desks

An IT ticketing system exists to do one thing: make sure nothing gets lost, and everyone can see where it is. Every feature on every vendor's page is downstream of that.

Which means the ticket list — the thing every product leads with and every build produces first — is not what decides whether the system works. What decides it is duller: whether inbound email still arrives in six months, whether an internal note can reach the person it was written about, and whether a missed response deadline is still visible after somebody finally replies.

This is the counted version. We audited 18 real help desk products — 8 open-source (Zammad, FreeScout, osTicket, UVdesk, Frappe Helpdesk, Znuny, RT, OTOBO), 6 SaaS (Zendesk, Freshdesk, Help Scout, Zoho Desk, Front, Intercom) and 4 marketplace scripts — against a 58-item feature inventory. Below is what that found, what each capability has to do to be real, and the failures that are specific to desks you host or build yourself.

The counted core

Ranked by how many of the 18 products ship each capability:

Capability	Products	Share
Ticket lifecycle and statuses	18	100%
Auto-assignment and routing	17	94%
Custom fields	17	94%
Automation / workflow builder	16	89%
REST API	14	78%
SLA policies and breach views	13	72%
Live chat	13	72%
Collision detection	10	56%
Knowledge-base deflection on the portal form	10	56%

Two findings in that table are worth more than the ranking itself.

The tell that separates a serious desk from a cheap script

Split those 18 by source and a pattern appears immediately:

REST API: present in all 14 SaaS and open-source products, and in zero of the four marketplace scripts.
SLA policies: all 6 SaaS products and 7 of 8 open-source, and zero of the four scripts.
Live chat: all four scripts ship it, and 5 of 8 open-source products lack it entirely.

That inversion is the whole story. Cheap scripts ship the capability that demonstrates well in a screenshot and skip the two that only matter once you are operating — the one that lets you get your data out, and the one that tells you when you are about to let somebody down.

It is also, precisely, the failure pattern of a helpdesk built from a bare prompt. A coding agent asked for "a helpdesk" produces the script's feature set, because that is what the shape looks like from the outside.

Collision detection is a pricing anomaly, not a technical one

Collision detection — showing that a colleague is already replying to the ticket you just opened — appears in only 10 of 18. But the distribution is the interesting part: it is free in FreeScout, Zammad and osTicket, and plan-locked at Zendesk, Freshdesk and Zoho.

It is not a hard feature. It is a paywalled one. Worth knowing before you accept a tier upgrade to get it, and worth putting in the specification if you are building, because it costs very little to add and prevents the most annoying failure in a two-person support team.

What each capability has to do to be real

Ticket lifecycle and statuses — 18 of 18. Universal, which means it differentiates nothing — until you look at how status interacts with the SLA clock. The cleanest design we found across all 18 attaches an SLA disposition to every status: does this status run the clock, pause it, or stop it? "Waiting on customer" should pause. "Escalated" should not. Most systems bolt this on as an exception list, and that is where the reporting goes wrong.

Also worth naming an anti-pattern found in the set: a system-enforced close with a hard ceiling — a ticket that closes itself after a fixed period and cannot be reopened. It produces tidy metrics and unhappy customers, who open a second ticket about the same problem.

Auto-assignment and routing — 17 of 18. Test: create a ticket that matches no rule. Where does it go? An unassigned queue nobody owns is where tickets die.

Custom fields — 17 of 18. Test: add a required field and check whether it is required on the customer portal as well as the agent form. It usually is not.

Automation — 16 of 18. Trigger, condition, action. Test: build a rule that fires on a state change and check whether it can loop. A workflow engine without loop protection will eventually send somebody four hundred emails.

REST API — 14 of 18. This is your exit as much as your integration path. Test: pull a ticket with its full conversation and attachments through the API. If attachments are not in there, your export is not an export.

SLA policies and breach views — 13 of 18. Covered in its own section below, because it is the capability most likely to be present and wrong.

Live chat — 13 of 18. The inverted one. Consider carefully whether you want it: chat converts a queue you control into a queue that expects an answer in ninety seconds, and it is a staffing decision far more than a software one.

Knowledge-base deflection — 10 of 18. Article suggestions on the submit form, before the ticket is created. Present in all 6 SaaS products and only 1 of 8 open-source. Cheap to build, measurably reduces volume, and the single most under-implemented capability in the set.

The gap nobody in the market has filled

One finding from the audit is worth stating on its own, because it is unusual: none of the 18 products ships a dedicated supervisor home screen.

Every one of them has a supervisor or team-lead role. In all 18, that role is assembled out of parts — a saved view here, a notification rule there, a report you have to go and run. The person responsible for whether the queue is healthy has no screen that tells them.

Think about what a supervisor actually needs at nine in the morning:

What is about to breach, ordered by how soon.
What has been sitting unassigned.
Who is overloaded and who is idle.
What was reopened, because a reopen is a failure the first-contact metrics will not show.
What is waiting on us versus waiting on the customer, which are completely different problems.

None of that is exotic. All of it is derivable from data every one of these systems already holds. It simply is not assembled anywhere, because it does not sell a subscription — it is not a feature a buyer asks for by name.

That makes it one of the cheapest and highest-value things to specify in a build, and one of the few places where something you build yourself can be straightforwardly better than a product you buy. If you are commissioning a desk, ask for that screen by description rather than by name, because it does not have a standard one.

The three failures specific to desks you run yourself

These are not feature gaps. They are the things that break after go-live, and every one is documented in the wild.

1 · Email intake stops working, quietly

Inbound email is the primary channel for most desks, and it is the most fragile part of the system. The specific failure: an OAuth token rotates, the connection fails, and mail is silently marked as read without creating tickets. Nobody notices, because the absence of tickets looks like a quiet week.

What a correct implementation needs: idempotent fetch, so a retried fetch cannot duplicate or drop a message; no destructive marking until a ticket exists; and an alert when intake stops rather than a dashboard nobody watches. Getting mail out matters too — SPF, DKIM and DMARC set up properly, or your replies land in spam and customers report that you never answered.

Test on any system: send a mail, then deliberately break the credential and send another. What happens to the second message, and does anybody find out?

2 · The public portal fills with spam within days

An open submission form on the public internet will be found by bots within about 72 hours. Self-hosted desks that ship without spam filtering become unusable fast, and the cleanup is manual.

Spam filtering is not an advanced feature here; it is a launch requirement. So is guest submission without forced registration — requiring an account before someone can report a problem is a documented adoption killer, and the two requirements pull against each other, which is exactly why this needs deciding up front rather than discovering later.

3 · The export is metadata only

Every major incumbent in this market either omits attachment binaries from exports, caps the export to metadata, or requires you to raise a support ticket to have the feature switched on at all.

Ask the question before you migrate in, not when you are trying to leave: does a full export include tickets, complete conversation threads, attachments as files, and users? If any of those four is missing, you cannot actually leave, whatever the marketing says about data ownership.

The two things a helpdesk cannot get wrong

We built four working support desks from a single specification using four different coding models, and scored them on the axis a desk lives or dies by: keeping information where it belongs. Two requirements, and they are worth stating as absolutes.

An internal note must never reach the customer

Not "must not be displayed to the customer" — must never reach their browser. The distinction is everything, because the common implementation sends the whole thread to the page and hides the internal parts with a filter in the interface. The note is then sitting in the served HTML, readable by anyone who looks.

The strongest build we audited filtered private notes out in the database query itself, so the note never left the server. Testing this properly means planting a real internal note and reading the served HTML as the customer who owns that ticket — not glancing at the rendered page.

The detail most systems miss: a file attached to an internal note. One build we tested refused that attachment even to the customer whose ticket it was, while staff could still open it. That is correct, and it is rare. Another let a customer attach a file to a different customer's internal note.

One customer must never see another's ticket

Obvious, and it needs proving in both directions. The owning customer must actually see their own ticket, or an empty result for everybody looks identical to working isolation. Use a control.

SLA that survives being answered

This is the failure worth the most attention, because it is invisible and it corrupts the report managers actually use.

A ticket breaches its first-response target. Three hours later an agent finally replies. In one of the desks we audited, the missed deadline was wiped at that moment — so a manager's monthly report could show zero breaches after a month of them. The build's own handover mentioned nothing, because from its point of view nothing had gone wrong.

A breach is an event that happened. Answering afterwards does not un-happen it. If your SLA state is computed from the current ticket rather than recorded when it occurred, your compliance reporting is fiction — and you will believe it, which is worse than having no report.

Test: let a ticket breach, reply to it, then run the breach report. If the breach has vanished, you have a live status dressed up as history.

If you are building one

A coding agent will produce a working support desk in a couple of days. Four of them, built from one specification by four different models, run as live demos.

The audit findings were consistent with everything above, and none of them was a missing feature. One would not compile for production, and once deployed exposed a database path that only worked from its own folder. One could not sign anyone in anywhere except a developer's own machine. One shipped with no sign-in at all — its permission rules were written correctly, and adding a word to the web address granted administrator access, which made every one of those correct rules unenforceable. It was labelled ready for production regardless.

What to put in the specification, because none of it will be inferred:

Private notes filtered at the query, never in the interface.
SLA breach recorded as an event at the moment it occurs, with statuses carrying a run, pause or stop disposition.
Email intake with idempotent fetch, no destructive marking before a ticket exists, and an alarm when intake stops.
Spam filtering and guest submission as launch requirements, together.
Full-fidelity export — tickets, conversations, attachment binaries, users.
Real sign-in with server-enforced roles, specified explicitly. This is the one that belongs to no feature and therefore gets skipped.
Attachment permissions inherit the visibility of the message they hang off.

And the honest economics, which the planner states verbatim rather than hiding: below roughly 8 to 16 agents on low-cost plans, self-hosting does not win on money. The savings become real above about 10 agents on mid-tier plans, where per-seat pricing scales linearly and your infrastructure cost does not.

The evaluation checklist

Plant an internal note. Read the served HTML as the ticket's own customer.
Attach a file to that internal note. Try to fetch it as the customer.
Open a second customer's ticket by its identifier. Then confirm the owner can see their own.
Breach a first-response target, reply, and run the breach report.
Set a status to "waiting on customer". Confirm the clock pauses.
Break the mail credential and send a message. See whether anyone is told.
Export everything. Confirm attachments arrive as files.
Submit from the portal as a guest, with no account.

Six of those eight are about what happens when something goes wrong or somebody leaves — which is the part of a helpdesk nobody demos, and the part you will live in.

Free ticketing system covers where the free tiers stop, and open source ticketing system covers what self-hosting actually costs to run. If you already have an engineering issue tracker and are wondering whether it can double as a support desk, using Jira as a ticketing system works through that specific question.

And if you are building, the Helpdesk Ticketing planner is the specification we hand our own agents — the isolation rules, the SLA model and the email plumbing written in so an agent has to build them rather than produce the ticket list and stop.