What is the ticket lifecycle?

The ticket lifecycle is the sequence of states a support ticket passes through, from creation to closure, together with the rules for moving between them. If a ticket is the noun, the lifecycle is the verb: it describes what happens to a request over time, not just what it is.

Every support request has a beginning, a middle and an end. The lifecycle gives each of those a name. When a customer first emails, a ticket is created and starts in a New state. As your team picks it up, works on it and waits on the customer, the ticket moves through a handful of clearly named states until it is answered and finally put to rest. The value is not the labels themselves but what they reveal: a single state on a ticket tells you, without reading the thread, whether it needs you, needs the customer, or needs nobody.

A useful way to think about it is that the lifecycle is a small, shared map. Everyone agrees what New means, what Waiting for Customer means and what Closed means. Because the meanings are shared, the queue stays readable when three people are working it at once, and reports can count how long tickets sit in each state.

New	The request has just arrived and has no owner yet. It is the freshest work in the queue, waiting for someone to pick it up. Triage starts here.
Open	The ticket is owned and in progress, with one person responsible for the next move. The ball is in your court, and any response-time clock is running.
Waiting for Customer	You have replied and the ball is now with the customer (or sometimes a supplier or another team). Your next-action clock should pause here, so you are not penalised for time you cannot control.
Snoozed	The ticket is parked out of the active queue while it is genuinely on hold, with a note of when you expect to need it again. Snoozing keeps on-hold work from cluttering the active view, while leaving it easy to find in its own Snoozed view when you are ready to pick it up.
Resolved	You have answered and treat the request as done. It is a soft finish: the customer can still reply, which reopens the ticket if they need more help.
Closed	The request is finished and settled, and the ticket has left the working queue for good. The full history is kept against the contact for reporting and future reference.

New and Open are both active states that need your attention; the difference is ownership. Waiting for Customer and Snoozed are both paused states; the difference is who you are waiting on and whether there is a set time to come back. Resolved and Closed are both finishes; the difference is whether a final customer reply is still expected. Holding those three pairs in mind makes the whole lifecycle easy to reason about.

1. New to Open. A teammate takes ownership of a new request, or it is assigned to the right person or team. The ticket now has someone accountable for the next reply.
2. Open to Waiting for Customer. The owner sends a public reply that needs a response, so the ticket moves to waiting and the next-action clock pauses while the customer reads and replies.
3. Waiting for Customer to Open. The customer replies. The ticket comes back into the active queue, the clock resumes, and the unread flag draws the owner back to it.
4. Any active state to Snoozed. The owner parks a ticket that is genuinely on hold and notes when it is expected to need attention again. The ticket drops out of the active view into its own Snoozed view, ready to pick back up when the time comes.
5. Open or Waiting to Resolved. Once the request is answered, the owner marks it resolved. It leaves the active queue but stays easy to reopen.
6. Resolved or Closed back to Open. If the customer replies to a resolved or closed ticket, it reopens automatically rather than starting a brand-new thread, so the history stays in one place.
7. Resolved to Closed. After a settled, quiet period, or once a final reply confirms the customer is happy, the ticket is closed. The record is kept; the work is done.

The two transitions worth dwelling on are the automatic ones. Moving to Waiting for Customer when you reply, and reopening when the customer comes back, keep a clock honest: the timer counts time you could act on, not the days a customer spends thinking it over. The automatic reopen stops a resolved request quietly vanishing when the customer still needs help.

For a small team, a clear lifecycle is the difference between a calm queue and a stressful one. A flat shared inbox treats a brand-new question, a reply you are still waiting on, and a request you have already answered as identical lines in a list. Nobody can answer the simplest planning question, which is what still needs a reply today. States answer it instantly, because the queue can be filtered to exactly the work that needs you.

The lifecycle is also what makes measurement possible. Because a tool knows when a ticket entered each state, it can tell you how long requests sit in New before someone takes them, how long Open tickets wait for a first reply, and how much time is genuinely spent Waiting for Customer rather than waiting on you. None of that is available from an inbox where every message looks the same.

• Triage is obvious, because New tickets are the ones with no owner yet.
• Targets stay fair, because the clock pauses while a ticket is Waiting for Customer.
• On-hold work is safe, because Snoozed tickets sit in their own view rather than getting lost in the active queue.
• Nothing closes too early, because a customer reply reopens a Resolved ticket automatically.
• Reports mean something, because time spent in each state is recorded against the contact.

Resolving to clear the queue, not because it is done

The most common mistake is treating Resolved as a tidy-up button. Marking a ticket resolved to get it off the screen, while the customer is still mid-conversation, makes the queue look calmer than it is and inflates your resolution figures. Resolve when you have genuinely answered, and trust the automatic reopen to bring the ticket back if the customer replies.

Leaving tickets Open when they are really waiting

The opposite error is leaving everything Open. A queue stuffed with Open tickets that are actually waiting on customers makes a team look swamped and lets the real, due work hide among requests where the ball is not even in your court. Moving a ticket to Waiting for Customer the moment you reply keeps the Open view to genuine workload, and keeps the clock honest.

Snoozing instead of resolving, or the other way round

Snoozed and Resolved both clear a ticket from the active view, but they mean different things. Snooze a ticket that is on hold and that you will pick back up yourself. Resolve a ticket that is answered and only needs the customer. Mixing them up means either on-hold work gets treated as finished, or finished work keeps coming back when the customer replies.

Support ticket	The single tracked record of one customer request. The ticket is the thing that travels through the lifecycle, carrying its owner, state and history with it.
Ticket state	One named position in the lifecycle, such as Open or Waiting for Customer. A state is a snapshot; the lifecycle is the whole film.
Triage	The first pass over new tickets, where they are read, prioritised, tagged and assigned. Triage is what moves a ticket out of New and gives it an owner.
SLA	A service level agreement, the promised response or resolution time a ticket is measured against. SLA clocks usually pause during Waiting for Customer.