Ticket status is one of the simplest concepts in customer support, and one of the most consistently mishandled. In principle, it is just a label that tells everyone in the team where a ticket currently stands. In practice, the set of statuses a team uses, how clearly they are defined, and how consistently agents apply them determines whether the support queue is a reliable operational tool or a misleading one.
Get the status structure right, and the queue tells a true story at a glance. Managers can see what is moving and what is stalled. Agents can prioritize their work accurately. Customers have a reference point for their request. Get it wrong, and tickets sit in statuses that do not reflect reality, the queue becomes untrustworthy, and operational decisions get made on inaccurate information.
This article covers what customer support ticket statuses are for, which ones most support operations need, how to define them clearly, and what to watch out for when designing or reviewing your status structure.
What Ticket Statuses Are Actually For
Before deciding which statuses to use, it is worth being clear about what they are supposed to accomplish.
Ticket statuses serve three distinct purposes simultaneously.
The first is progress visibility. Status tells anyone looking at a ticket where it currently sits in the workflow. A manager reviewing the queue does not need to open every ticket and read its conversation history to understand which requests are new, which are being worked, which are waiting on something, and which are resolved. Status makes that visible at the queue level.
The second is coordination. When multiple agents work from the same queue, status is part of how they coordinate without constant verbal communication. An agent who can see that a ticket is already being actively worked by a colleague does not need to check whether they should pick it up. A team lead who can see that a high-priority ticket has not moved from new status in several hours knows they need to intervene.
The third is data. Status history is part of what analytics are built on. How long tickets spend in each status, how often they move backward through the workflow, how resolution rates vary across different status paths: these are all insights that become available when status is used consistently and accurately. When it is not, the data derived from it is unreliable.
The Core Statuses Most Support Operations Need
There is no universal standard for ticket status naming. Different platforms use different terminology, and different organizations have different operational needs. But the underlying states that statuses need to represent are fairly consistent across most customer support operations.
New
A ticket in new status has entered the system but has not yet been picked up by an agent. It is sitting in the queue waiting for triage and assignment.
New is the entry point for the ticket workflow. Every ticket starts here. The goal of the support operation is to move tickets out of new status and into active handling as quickly as the priority structure warrants.
New status has a practical secondary function: it makes unaddressed tickets visible. A queue showing a large number of tickets in new status is a queue that has not been triaged recently. That visibility is useful for managers monitoring queue health.
Open
An open ticket is one that has been picked up by an agent and is being actively worked. The ticket has moved past triage and assignment and is now in the hands of the person responsible for resolving it.
Open is often the broadest status in the workflow because it covers a range of actual states: the agent is investigating, the agent is preparing a response, the agent is waiting on an internal answer before replying to the customer. Some organizations choose to leave all of that under the single open label. Others break it into more granular statuses depending on how much operational detail they need at the queue level.
The key distinction that open needs to capture is that the ticket is in active motion. An agent has it. Work is happening. It is different from a ticket that is genuinely stalled.
Pending
Pending covers tickets that are in progress but are waiting on something before they can move forward. The most common variant is waiting on the customer: the agent has asked a clarifying question or proposed a resolution that needs confirmation, and the ball is now in the customer’s court.
Pending is one of the most operationally important statuses because it separates tickets that agents can act on right now from tickets where forward progress depends on external input. A queue view that distinguishes pending tickets from open ones gives agents a much clearer picture of where they should focus their attention.
Without a pending status, agents have to open each ticket individually to determine whether they are waiting on the customer or whether they need to take action. That is unnecessary overhead, and it often results in pending tickets getting worked past their natural pause point or genuinely open tickets being missed because they were not distinguishable from waiting ones.
Some organizations use multiple pending variants: pending customer response, pending internal review, pending third-party action. Whether that level of granularity is useful depends on how much detail managers need at the queue level and whether agents will maintain that distinction consistently.
Escalated
An escalated ticket is one that has been moved from one team or agent to another because the original handler was unable to resolve it. The ticket is still open and active, but its ownership has changed.
Whether escalated deserves its own status or is simply a property of the ticket alongside its current open or pending status is a design decision. Some organizations use a dedicated escalated status to make escalated tickets immediately visible in the queue. Others track escalation separately through assignment history and audit records without a distinct status.
The case for a dedicated escalated status is visibility. Managers who want to monitor how many tickets are currently escalated, how long they have been in that state, and whether the receiving teams are handling them promptly need a way to surface escalated tickets without manually reviewing assignment histories. A status makes that easy. Without one, it requires more involved queue filtering or analytics.
Resolved
A resolved ticket is one where the customer’s request has been addressed and the agent considers the issue handled. The ticket is at the end of its active workflow.
Resolved is often distinct from closed in support ticket systems, and the distinction matters. A resolved ticket may still receive a customer follow-up. If the platform handles that correctly, a customer response to a resolved ticket will reopen it and notify the assigned agent, bringing it back into the active workflow.
This behavior makes resolved a soft end state rather than a hard one. The ticket has been handled, but it remains associated with the assigned agent and is capable of being reopened if the customer needs to continue the conversation.
Closed
Closed is the terminal state. A closed ticket is definitively finished. It is no longer expected to receive activity, and in most systems it does not reopen automatically on customer contact in the same way a resolved ticket does.
The distinction between resolved and closed reflects a practical workflow reality. After a ticket is resolved, there is a period during which a customer response is reasonably expected and should be handled within the same ticket record. Once that window has passed and the ticket is truly concluded, closing it removes it from the active queue and moves it into the historical record.
Not all support platforms make this distinction. Some use resolved and closed interchangeably. Whether the distinction is useful depends on how the organization handles the post-resolution period and whether it wants a formal separation between tickets that are finished and tickets that are finished and confirmed.
Statuses That Are Sometimes Useful
Beyond the core set, some support operations use additional statuses for specific operational needs. These are worth considering, but only if they reflect genuine workflow states that agents will maintain consistently.
On hold. Distinct from pending, on hold indicates that a ticket is paused for a reason other than waiting on the customer. An internal dependency, a third-party process, or a scheduled follow-up at a future date. On hold keeps these tickets visible in the queue without them appearing as actively open work.
In review. Some organizations use an in review status to indicate that a proposed resolution is being reviewed internally before being communicated to the customer. This is useful when quality review is a formal part of the workflow for certain ticket types.
Reopened. Some platforms use a distinct reopened status to identify tickets that were resolved and then came back into the workflow. This makes it easy to track how often resolutions do not stick and identify patterns in which types of requests tend to return.
The Risk of Too Many Statuses
There is a temptation when designing a status structure to create a status for every nuance of the workflow. The result is usually a status list that is too granular to maintain consistently.
When agents have to make fine distinctions between similar statuses on every ticket they handle, status accuracy degrades. Agents start defaulting to whichever status seems roughly right rather than the one that precisely describes the ticket’s state. The granular status structure that was supposed to provide operational clarity produces a queue full of imprecisely applied labels that cannot be trusted.
The test for any proposed status is whether agents will apply it consistently without needing to deliberate each time. If the distinction between two statuses requires judgment that agents will make differently depending on their experience or mood, the two statuses will not stay meaningfully distinct in practice. Collapsing them into one is usually the better choice.
Defining Statuses Clearly
Naming a status is not the same as defining it. A status called pending means different things to different agents unless the organization has been explicit about what it means.
For each status in the set, the definition should answer three questions: what does this status mean, what conditions put a ticket into this status, and what action takes the ticket out of this status and into the next one.
Clear definitions turn status from a label agents apply loosely into a mechanism that accurately reflects the state of the workflow. They also make it easier to onboard new agents, because the status structure is documented rather than absorbed informally over time.
Keeping Status Accurate
A well-designed status structure only works if agents keep it current. A ticket whose status was set to open three days ago and has not been updated since may or may not still be in active work. Without a status update, nobody can tell from the queue.
Status accuracy is a team practice as much as a system design question. Agents who treat status updates as part of doing the work, updating status whenever something meaningful changes on a ticket, produce queues that can be trusted. Agents who treat status as an administrative overhead they manage occasionally produce queues that mislead.
Managers who review queue status regularly and follow up on tickets whose status appears stale reinforce the habit. So do clear team expectations about status maintenance that are established from the start rather than retrofitted after accuracy has already degraded.
How Monesize Desk Approaches This
Monesize Desk supports customer support ticket statuses as a core part of its ticket management workflow.
Tickets in Monesize Desk carry a status field that reflects where the ticket currently sits in the workflow, alongside priority, assignment, category, and the full conversation record. Status is visible at the queue level, giving agents and managers a clear picture of what is open, what is in progress, what is waiting, and what has been resolved without needing to open individual tickets.
The full ticket lifecycle is supported across creation, assignment, active work, escalation, resolution, and reopening. When a customer responds to a resolved ticket, it reopens automatically and notifies the assigned agent, bringing it back into the active queue without any manual intervention. Audit history records every status change on every ticket, giving managers a complete timeline of how each request moved through the workflow.
Customer records give agents persistent context across interactions. Conversations on tickets keep the full communication history in one place. Analytics give support managers visibility across the queue, including how tickets are distributed by status across agents and teams.
The knowledge base allows organizations to publish support articles through a customer self-service portal, reducing ticket volume for requests that customers can resolve without agent involvement.
Monesize Desk is free. You can get started at desk.monesize.com.