Tickets — single problem, single resolution
Tickets work for short-lived, single-actor interactions. A wifi outage, a forgotten password, a missing invoice. Open, action, close — most tickets resolve inside a working day and don't need a longer history. The data model is flat: requester, subject, description, resolution, closed date. The audit story is 'we got the request, we resolved it, we closed it'. Ticketing systems are optimised for throughput; the goal is to clear the queue.
Cases — multi-step, multi-actor, audit-bearing
Cases work for regulated workflows: complaints, safeguarding, claims, disciplinaries. They have stages, decision points, deadlines and an audit trail that survives staff turnover. Forcing this into a ticketing model loses the audit story — the ticket closes when the action is done, but the case must remain open through appeals, reviews and statutory retention periods. The data model is richer: stages, sub-tasks, associated documents, audit log of every change, named decision-makers at each stage.
Mixed environments
Most real helpdesks need both. The trick is keeping the two surfaces distinct without doubling the licence count. Modern platforms let you run tickets and cases in one workspace with different lifecycles — a ticket is a lightweight workflow with closure on resolution; a case is a heavyweight workflow with closure on completion of statutory or regulatory requirements. The user sees one inbox; the data model behind it knows the difference.
Examples — IT helpdesk
Most IT requests are tickets: password resets, software installs, hardware swaps, access requests. A small minority are cases: a long-running access investigation, a data-loss incident with regulatory implications, a major change with multiple stages of approval and rollback. The same team can handle both, but the system needs to distinguish them or the case workflow gets squeezed into the ticket model and the audit story is lost.
Examples — HR and people operations
HR queries are mostly tickets: a payslip question, a leave-balance query, a benefits enrolment. The case workflows — grievances, disciplinaries, formal complaints, occupational-health referrals — are heavyweight, multi-stage, audit-bearing and often statutory. The legal exposure on a case mishandled because it was treated as a ticket can be material; the productivity loss from treating tickets as cases is a slower but real cost.
Examples — regulated industries
Complaints handling in financial services, safeguarding in education and care, clinical incidents in healthcare — all of these are case workflows with statutory timelines and audit obligations. The regulator's primary check is whether the workflow was followed and the audit log is complete. A ticketing model fails this check; a case-management model is designed for it.
How to choose at the start
Two questions: (1) does this work have stages and decision points beyond 'open' and 'closed'? (2) does the work need to survive staff turnover, audit or legal scrutiny? If yes to either, it is a case. If no to both, it is a ticket. Build the right workflow for each at the start, and the team never has to migrate.
Tickets and cases are different products in the same toolbox. Pick the right one for the work and the team thanks you — pick the wrong one and the workaround becomes the second system.