Ticket statuses track where IT work stands. This guide covers standard statuses, custom configuration, best practices, and the access request status gap that standard ticketing can't fill.
Ticket statuses are the tracking layer of IT service management. Every ticket in the system carries a status that tells IT teams where the work stands: not yet started, in progress, waiting on something, or done. Without status tracking, a queue of tickets is just a list with no way to distinguish what's being worked on, what's stuck, and what's been resolved.
But status tracking is only as useful as the statuses themselves are meaningful. Generic statuses applied inconsistently produce queues that look organized but don't actually tell IT managers what they need to know. And for one category of IT request, access requests, even a perfectly configured status system tracks the ticket without capturing what actually matters: what access was provisioned, at what level, and whether it's still appropriate.
This guide covers what ticket statuses are, the standard stages every IT team needs, how to design custom statuses for specific request types, best practices for managing statuses effectively, and where the standard status model falls short.
What Is a Ticket Status?
A ticket status is a label indicating the current state of a support request or IT issue within the ticketing system's workflow. It tells both IT teams and the employees who submitted requests where a ticket stands in the resolution process at any given moment.
Statuses serve three functions. For IT teams, they enable queue management: filtering by status shows what needs immediate attention, what's waiting on external input, and what's been resolved. For IT managers, aggregate status data surfaces workload distribution and identifies where tickets are stalling. For employees, status visibility means they don't need to contact IT to find out whether their request is being worked on.
Every status change should represent a meaningful transition in the ticket's lifecycle, not a bookkeeping exercise. A status taxonomy that has too many stages, or stages that aren't consistently applied, produces noise rather than signal. A well-designed status system gives everyone accurate, real-time visibility into the state of IT work with minimal administrative overhead.
Standard Ticket Statuses
Most IT ticketing systems use a core set of statuses that cover the fundamental stages of the ticket lifecycle. These are the statuses every team needs, regardless of how the system is customized beyond them.
Open
A ticket is Open when it has been submitted and logged in the system but not yet assigned or actively worked on. Open is the holding state before the work begins. A ticket that remains Open for longer than its SLA target for first response is the earliest signal of a routing or triage problem: either the assignment rules aren't working correctly or the queue is too large for the team to process in a reasonable timeframe.
Open tickets should be the team's most visible queue. High Open counts relative to team capacity indicate incoming volume that's outpacing the team's ability to triage.
In Progress
A ticket is In Progress when an IT team member has been assigned and is actively working on it. This status spans the full resolution phase: diagnosis, troubleshooting, communication with the requester, and implementation of the fix or fulfillment of the request.
Time in In Progress is the clearest indicator of resolution complexity. Routine requests that spend a long time In Progress usually signal a missing piece of information (requiring back-and-forth with the requester), a skill gap (the assigned agent doesn't have what they need to resolve it), or a bottleneck in a downstream system (the fix requires access or a change that hasn't been authorized yet).
On Hold / Pending
A ticket is On Hold when active work has temporarily paused, typically because the IT team is waiting on something outside their immediate control: a response from the requester, approval from a third party, a vendor action, or a dependency on another ticket being resolved first.
On Hold is important to distinguish from In Progress because tickets in these two states require different actions. An In Progress ticket needs the assigned agent to keep working. An On Hold ticket needs the assigned agent to monitor for the awaited input and resume when it arrives. Without this distinction, On Hold tickets can sit silently in the queue and miss SLA targets while appearing to be actively managed.
Most teams configure automatic reminders on On Hold tickets: if no update is received within a defined period, the ticket triggers a follow-up notification to the requester or the external party being waited on.
Resolved
A ticket is Resolved when the IT team has completed the work and believes the issue is fixed or the request is fulfilled. Resolved is a transitional status, not a final one. It signals to the requester that IT considers the issue addressed and invites them to confirm.
The gap between Resolved and Closed is where reopened tickets originate. If a requester returns to a Resolved ticket and indicates the issue persists, the ticket moves back to In Progress rather than being closed. Teams that skip the Resolved stage and close tickets immediately on completion will see higher rates of new tickets for the same issue, because employees have no opportunity to flag that the resolution didn't hold before the record is closed.
Closed
A ticket is Closed when the resolution has been confirmed, either explicitly by the requester or after a defined confirmation window (typically 48-72 hours) passes without a response. Closed is the terminal state for the ticket's lifecycle in the ticketing system.
This is where the access request problem begins, not ends. For most ticket categories, Closed is genuinely the end: the issue is resolved and the ticket is a historical record. For access request tickets, Closed means the approval was recorded, but what was actually provisioned in the application, at what permission level, for how long, and whether it's still active, is outside the ticket and outside the system. More on this below.
Custom Ticket Statuses
Standard statuses cover the core lifecycle. Custom statuses add granularity where the standard stages don't capture meaningful distinctions for a specific request type or workflow.
When custom statuses add value
Custom statuses are useful when a stage in the workflow produces meaningfully different work depending on the ticket's state, and when that distinction drives different actions for the IT team or different expectations for the requester.
Useful custom statuses for IT ticketing include:
Awaiting Approval: For requests that require manager or security team sign-off before IT can proceed. Distinct from On Hold because the next action is the approver's, not the requester's.
Awaiting Vendor: For issues that require external vendor involvement. Distinct from On Hold because the dependency is external and may have its own SLA or escalation path.
Scheduled: For change requests or maintenance tasks that have been approved and dated but not yet executed. Signals that the work is planned without showing as In Progress prematurely.
Testing: For IT-side validation after a fix has been implemented but before the requester is notified. Useful for software deployments or configuration changes where IT wants to verify the fix before closing.
Escalated: For tickets that have moved from L1 to L2 or L3 support. Tracking escalation as a status (rather than just a queue change) gives managers visibility into escalation volume by ticket category.
When custom statuses create noise
Custom statuses that are too granular, rarely used, or inconsistently applied make the status taxonomy harder to manage without adding useful information. If a status doesn't drive a different action or a different expectation, it doesn't belong in the taxonomy.
The most common custom status mistake is creating statuses that describe who has the ticket rather than what state it's in. "With Tier 2" is a routing status, not a workflow status. Use assignment and queue management for routing; use statuses for workflow state.
Best Practices for Managing Ticket Statuses
Define what each status means operationally, not just conceptually. "In Progress" means the assigned agent is actively working on this ticket today, not that someone looked at it last week. "Resolved" means IT believes the issue is addressed and the requester has been notified, not that the agent marked it done. Document these definitions and enforce them through workflow configuration rather than relying on individual interpretation.
Automate status transitions where the trigger is unambiguous. A ticket should automatically move to In Progress when it's assigned to an agent. It should automatically move to Closed after a defined period in Resolved without requester response. SLA breach alerts should fire automatically when a ticket approaches its target in Open or In Progress status. Manual status updates create inconsistency and administrative overhead; automation creates consistency.
Configure status-based SLA tracking per ticket category. A critical incident has different time targets at each status stage than a low-urgency service request. SLA monitoring that tracks time in Open and In Progress separately (rather than just total resolution time) surfaces where in the workflow time is being lost for each category.
Review On Hold tickets actively, not passively. Tickets in On Hold can silently age past SLA targets while appearing managed. A daily or weekly review of On Hold tickets by age surfaces ones that have been waiting longer than expected for external input and gives IT managers the chance to intervene before a breach.
Make Resolved confirmation visible to employees. Employees who receive a "your request has been resolved" notification without understanding what was done are more likely to re-open the ticket than those who receive a clear confirmation of what was fulfilled and what to do if the issue persists. The transition from Resolved to Closed should be the employee's decision, not just a timeout.
Track reopened ticket rates by category. A high rate of tickets reopening from Resolved indicates either that resolutions aren't holding (a quality problem) or that IT is closing tickets prematurely (a process problem). Both are fixable, but they require different interventions, and tracking by category identifies which categories have the problem.
The Status Gap That Matters for Access Requests
For most ticket categories, the Closed status genuinely ends the ticket's lifecycle. The issue is resolved, the historical record exists, and the ticket can be closed without consequence.
For access request tickets, Closed ends the ticket's lifecycle in the ticketing system but not the access grant's lifecycle in the application. When an access request ticket closes, the access that was provisioned continues to exist in the application with no ongoing connection to the ticket that authorized it. There's no status for "access active," "access expired," or "access revoked" in a standard ticketing system because those states exist in the application, not in the ticket.
This creates a category of invisible status. The ticket is Closed. The access is active. No status in the ticketing system reflects whether the access is still appropriate, whether it's expired as intended, or whether the employee who received it has since changed roles or left the organization.
The downstream consequences are access debt: over-permissioned users accumulate because there's no mechanism in the ticket workflow to review or revoke what was granted after the ticket closed. Former employees retain access because offboarding processes check the identity provider but not the access request tickets. Time-bound access persists because the ticket has no memory of the intended expiry date after it's closed.
Zluri's Access Requests eliminates this gap by treating every access grant as a governed object with its own lifecycle, distinct from the ticket. The request, the approval, the provisioning action, the access duration, and the revocation or expiry event are all part of a single record that persists and remains queryable after the ticket closes. The equivalent of an access request ticket status in Zluri isn't just Open, In Progress, and Closed. It's Request Submitted, Policy Evaluated, Approved, Provisioned, Active, Expiring Soon, and Revoked, each tied to a timestamped action with a complete chain of custody.
For IT teams where access requests represent significant ticket volume, this lifecycle visibility is not a nice-to-have. It's what separates a ticketing system that tracks approvals from an access governance system that governs access. The ticket records that something happened. Zluri records what that meant, in the application, for as long as it continues to matter.
Frequently Asked Questions
What is a ticket status?
A ticket status is a label indicating the current state of a support request or IT issue in the ticketing workflow. It tells IT teams what stage of the resolution process a ticket is in (not started, being worked on, waiting on input, or resolved) and gives employees visibility into where their request stands without needing to contact IT directly.
What are the standard ticket statuses in IT service management?
The standard statuses that cover the core ticket lifecycle are Open (submitted but not yet assigned or worked on), In Progress (actively being worked on by an assigned agent), On Hold or Pending (work paused while waiting on external input), Resolved (IT believes the issue is addressed, awaiting requester confirmation), and Closed (resolution confirmed or confirmation window elapsed). Most teams add custom statuses on top of these for specific request types or workflow stages.
When should you use custom ticket statuses?
Custom statuses add value when a stage in the workflow produces meaningfully different work or different expectations, and when that distinction isn't captured by the standard statuses. Awaiting Approval (for requests needing sign-off before IT can proceed), Awaiting Vendor (for external dependencies), Scheduled (for approved but not yet executed changes), and Escalated (for tickets that have moved to a higher support tier) are the most commonly useful custom statuses for IT teams.
What is the difference between Resolved and Closed?
Resolved means IT has completed the work and believes the issue is addressed. The requester hasn't yet confirmed this. Closed means the resolution has been confirmed, either explicitly by the requester or after a defined waiting period without response. The distinction matters because it gives employees a window to flag that the resolution didn't hold before the record is permanently closed, which reduces the rate of new tickets for the same unresolved issue.
Why don't standard ticket statuses capture the full lifecycle of access requests?
Standard ticket statuses track what happens inside the ticketing system: the request was submitted, assigned, worked on, and closed. They don't track what happens in the application after the ticket closes: whether access was provisioned correctly, whether it's still active, whether it expired as intended, or whether it's still appropriate for the employee's current role. These are access governance states, not ticket workflow states, and they require a platform that tracks access as a governed object with its own lifecycle, not as a ticket that gets closed.
How should ticket statuses be configured for access request workflows?
For access request tickets specifically, the standard status workflow (Open, In Progress, Resolved, Closed) should be supplemented with an Awaiting Approval status that reflects when the ticket is pending approver action, distinct from In Progress (where IT is actively working) and On Hold (where the ticket is waiting on the requester). However, configuring access request statuses more granularly in the ticketing system still doesn't close the fundamental gap: what happens in the application after the approval is recorded remains outside the ticketing system's visibility regardless of how the statuses are configured.
.svg)
