Written by the Infronest Product & IT Operations Team, who build and operate the ticketing, SLA and approval workflows used by live customer IT teams. Terminology follows ITIL 4 definitions for incident, service request, problem and change.
IT Operations
What Is a Ticketing System? How IT Tickets Work (2026)
How a ticket moves through statuses, what each field is for, priority versus severity, how SLA timers actually run, and where IT ticketing differs from customer-support ticketing.
Most IT teams do not decide to buy a ticketing system. They reach a point where an urgent request is sitting unread in someone's inbox, nobody can say who owns it, and there is no way to prove when it arrived. A ticketing system makes those three questions answerable at any moment. This guide covers what the software actually does — statuses, fields, SLA clocks and routing rules — rather than the helpdesk function around it.
Definition
What is a ticketing system?
A ticketing system is software that turns every incoming request — an outage, a password reset, a new-laptop request — into a numbered, owned record called a ticket, and tracks that record through a defined set of statuses until it is resolved and closed. It is the system of record for support work: who asked, what was asked, who owns it, what has been done, when it is due, and what finally fixed it.
Two words get used interchangeably here. The helpdesk is the function — the team, the process and the single point of contact users deal with. The ticketing system is the software that enforces that process and stores its history.
The minimum such a system must provide is a unique identifier per request, exactly one accountable owner at any moment, an explicit status, immutable timestamps and a full update history on the record. If a tool cannot answer 'who owns this and when is it due' without asking a colleague, it is a shared mailbox with extra steps.
Lifecycle
How a ticket flows through statuses
A ticket is a state machine. Statuses are not decoration: SLA clocks start, pause and stop on status changes, and every backlog report is a count of tickets grouped by status. Six to eight statuses covers almost every internal IT team, and each should mean something distinct to a reporting query.
- New / unassigned — created, not yet picked up, response clock already running. A growing count here is a triage problem, not a capacity problem.
- Open / assigned — the ticket has a named owner. Ownership is the whole point: a queue with no owner is a list of things nobody has agreed to do.
- In progress — someone is actively working. This separates real motion from a ticket that has an owner and no activity, which is how work stalls invisibly.
- Pending / awaiting requester — blocked on information from the user. Most systems pause the resolution clock here, which is fair, but audit it: pending is where inconvenient tickets go to hide.
- On hold / awaiting third party — blocked on a vendor, an RMA or a change window. Keep it separate from pending so you can report how much of the backlog is genuinely external.
- Resolved — the fix is applied and the requester has been asked to confirm. Resolved is not closed: it gives the user a defined window, typically three to five days, to say the problem persists.
- Closed — confirmed by the user, or auto-closed when the window expires. Closed records should be effectively immutable; corrections belong on a reopen or a new ticket.
- Reopened — the user came back inside the window. Reopen rate is one of the most honest quality metrics you have; a high one means tickets are being closed rather than causes fixed.
Anatomy
Ticket fields and why each one exists
Every mandatory field costs the requester time and raises the chance they route around your portal entirely. The test for keeping one is simple: does routing, prioritisation, resolution or reporting actually consume it? These usually pass.
- Ticket ID — an immutable reference used in emails, chat, change records and audits. Never reused, never renumbered.
- Requester and affected user — often different people, such as a manager raising a request for a team member. Notifications, approvals and VIP handling all depend on knowing which is which.
- Type — incident, service request, change or problem. An incident is something broken; a request is something wanted. They carry different targets and approval paths, and merging them makes volume reporting meaningless.
- Category and subcategory — a controlled two-level taxonomy owned by IT. Routing rules and trend reports read this field, which is why it must be a fixed list rather than free text.
- Priority, derived from impact and urgency — the field that selects the SLA target. Store impact and urgency separately so priority can be recalculated consistently rather than argued about.
- Assignment group and assignee — group first, individual second. A ticket assigned only to someone on leave is invisible; a ticket in a group queue is still someone's problem.
- Linked asset or configuration item — which laptop, server, service or licence the ticket concerns. This turns 'laptop is slow' into a record showing the machine's age, warranty, patch level and previous tickets.
- Timestamps and resolution notes — created, first response, resolved and closed timestamps are the raw material for every SLA metric, so they should be system-set and non-editable. The resolution note and code are what later become knowledge-base articles.
Prioritisation
Priority vs severity — and how SLA timers use them
Severity describes how badly something is broken, judged from the technical side. Priority describes the order in which you will work on it, which is a business decision. They are usually set in the same two-minute conversation and they are still not the same field: a cosmetic defect on the checkout page during a sales campaign is low severity and high priority, while a crashed test server is high severity and low priority.
The standard way to derive priority is an impact-by-urgency matrix. Impact answers how much of the business is affected — one user, one department, one site, everyone. Urgency answers how fast the situation is degrading or how close a deadline is. A three-by-three matrix produces the priority automatically, which removes the negotiation: the requester describes the situation, the matrix decides the queue position.
- Two clocks, not one — response time measures how long until a human meaningfully replies; resolution time measures how long until it is fixed. Users judge you far more on the first.
- Targets per priority — a workable structure is P1 respond 15 minutes / resolve 4 hours, P2 1 hour / 1 day, P3 4 hours / 3 days, P4 1 day / 5 days. Publish them so users know what to expect.
- A business-hours calendar — a four-hour target means four working hours if your service window is 09:00 to 18:00, Monday to Friday. Match the calendar to the actual support contract, local public holidays included, or the figures will be wrong in both directions.
- Deliberate pause conditions — decide explicitly whether the clock stops in pending and on-hold states, then report paused time alongside elapsed time so pausing cannot manufacture compliance.
- Escalation thresholds — notify at roughly 50%, 75% and 100% of target, and escalate to a group rather than one manager who may be in a meeting. An escalation that fires after the breach is a report.
- Honest breach handling — reassigning or re-prioritising must not restart the original clock. If timers silently reset on reassignment, your SLA percentage is fiction.
Automation
Routing rules, automation, categories and tags
Routing rules are conditional statements the system evaluates when a ticket is created or updated: if category is 'Network' and site is 'Gurugram', assign to the network group and set priority P2. What they buy is time-to-owner — most of the delay users complain about is not repair time, it is the hours a ticket belongs to nobody.
Categories and tags solve different problems and should not be merged. A category is a controlled, hierarchical value, one per ticket, owned by IT and consumed by routing rules, SLA policies and trend reporting; it should fit on one screen, usually eight to twelve top-level entries. A tag is free-form, additive and disposable — several per ticket, grouping work for a temporary reason such as an office move or a Windows 11 rollout. The usual failure is letting everyone create categories until there are sixty, half unused and none routing anywhere.
- Assignment rules — route on category, site, requester's department, asset type or subject keywords, and always fall back to a triage queue rather than a named individual.
- Automatic prioritisation — derive priority from impact and urgency, or from the criticality of the affected service. A production database outage should not depend on the requester ticking the right box.
- Notification rules — acknowledge on creation, notify on assignment, resolution and closure, then stop. Over-notifying trains people to filter your ticketing system into a folder they never open.
- Auto-close — close resolved tickets after a fixed window, with a warning message first. Without it, 'resolved' quietly becomes a second backlog.
- Knowledge-base suggestions at intake — showing likely articles while the user types is the only automation that reduces ticket volume instead of moving it between queues.
- Integration triggers — a monitoring alert opening a ticket against the affected server, or an approval decision advancing a request, keeps the ticket the single record of what happened.
Scope
IT ticketing vs customer-support ticketing
The mechanics are close to identical — both create tickets, route them, run SLA clocks and report. The difference is the model around the ticket. Internal IT ticketing assumes a known, authenticated population with an organisational structure, assigned devices, entitlements and approval chains. That is why IT tools link tickets to assets and configuration items, carry approvals for access and purchases, and use ITIL types such as incident, request, change and problem.
Customer-support ticketing assumes the opposite: an unknown external contact who may write from three email addresses and a chat widget. Those products invest in identity resolution, conversation threading across channels, macros and satisfaction surveys. They generally have no CMDB and no approval workflow, because their users have no assets you manage and no manager who signs off.
Practically, this drives the shortlist. Customer-support platforms are excellent externally but ITSM-light internally; IT-native tools handle incidents, changes and assets properly but are weaker at high-volume external conversations. If you serve both audiences, keep separate workspaces, or at minimum separate taxonomies and SLA policies — one shared queue produces reporting neither team trusts.
Infronest
Conclusion
Infronest includes helpdesk and ticketing — SLA-aware routing, approvals and a knowledge base — as one of 16 modules inside a single tenant-isolated workspace. Because IT assets, MDM-managed endpoints, patching and server, network and website monitoring live in that same workspace, a ticket can be linked to the exact asset it concerns, and a monitoring alert can open a ticket against the affected server rather than an email nobody owns.
To be straightforward about fit: this is built for internal IT ticketing. If your priority is high-volume external customer support with satisfaction surveys and social channels, a dedicated customer-support platform will serve you better. If it is IT requests, incidents, approvals and knowing which device a ticket concerns, keeping ticketing and asset records in one system removes the manual copying that separate tools create.
Start a 14-day free trial at infronest.com — no credit card required.
Pitfalls
Where ticketing systems go wrong in practice
- Too many priorities — four levels is enough. Beyond that, everything drifts to the middle and the distinctions stop meaning anything.
- Letting the requester set priority alone — every ticket becomes urgent within a month. Derive it from impact and urgency, or from the criticality of the affected service.
- A taxonomy nobody maintains — categories accumulate, most go unused, routing quietly stops matching. Review the list quarterly and merge the long tail.
- Treating pending as a parking space — if the clock pauses there, report paused time as a first-class metric or it will be used to hide old work.
- Closing without a resolution note — no knowledge base results, and the same incident is diagnosed from scratch next month.
- No reporting cadence — review SLA compliance, backlog age, reopen rate and the top five recurring categories weekly. Targets nobody reports on change nobody's behaviour.
Frequently Asked Questions
- What is a ticketing system in simple terms?
- It is software that records each support request as a numbered ticket with one accountable owner, then tracks it through statuses until it is resolved and closed. It stores who asked, what was done, when it happened and what fixed it. That record is what makes support work measurable rather than a matter of memory.
- What is the difference between a ticketing system and a helpdesk?
- The helpdesk is the function — the team and the process users contact for support. The ticketing system is the software that enforces that process and holds the history. In everyday conversation the terms get used interchangeably, but when you are buying, you are buying the ticketing system.
- What is the difference between priority and severity in a ticket?
- Severity is a technical judgement about how badly something is broken; priority is a business decision about the order in which you will work on it. Priority is normally derived from impact multiplied by urgency. A cosmetic bug on a payment page during a campaign is low severity and high priority, which is exactly why the two fields cannot be merged.
- What statuses does a ticket go through?
- A typical flow is new, assigned, in progress, pending or on hold, resolved and closed, with reopened as a possible return path. Resolved and closed are deliberately separate: resolved means the fix is applied and awaiting user confirmation, while closed means the window has passed or the user has confirmed.
- Can I use a customer-support ticketing tool for internal IT?
- You can, and many small teams do, but you will usually miss asset and configuration item links, approval workflows and ITIL change and problem handling. Conversely, IT-native tools are weaker at high-volume external conversations and satisfaction surveys. If you serve both audiences, keep separate workspaces, taxonomies and SLA policies.