What is the ticket lifecycle?
The ticket lifecycle is the sequence of statuses a support conversation passes through from the customer's first message to the end of the case, together with the rules that move it from one status to the next. In a WhatsApp inbox or helpdesk the usual statuses are new (not yet picked up), open (an agent is working on it), pending (waiting for the customer), on hold (waiting for another team or a third party), resolved (the agent believes it is solved) and closed (final, locked).
Some transitions are made by agents, others by rules. An agent sets pending after asking for a photo of a damaged product; the customer's reply moves it back to open automatically. A resolved chat that receives a new message within a set period reopens; after that period, it is closed automatically and the next message starts a new conversation. Each move is time-stamped, which is what lets the platform calculate resolution time and pause SLA timers while a chat waits on the customer.
Statuses are not tags. Conversation tagging labels what a conversation is about — refund, delivery delay, KYC — while the status says where the work stands. A chat can be tagged "refund" through its whole life while its status changes six times. Keeping the two separate is what makes both reporting by reason and reporting by stage reliable.
Key takeaways
- The ticket lifecycle is the set of statuses a support conversation moves through and the rules that move it between them.
- Common statuses are new, open, pending, on hold, resolved and closed, plus reopened when the customer writes again.
- Pending means waiting on the customer; on hold means waiting on a third party or another team.
- Resolved can still reopen when the customer replies; closed is final, and a new message starts a new conversation.
- Statuses describe where work stands; conversation tags describe what the conversation is about.
How does the ticket lifecycle work?
- Step 1
New → open
A customer's first message creates a new conversation. Assignment to an agent, or the agent's first reply, moves it to open.
- Step 2
Open ↔ pending
When the agent needs something from the customer, they set pending; the SLA resolution timer pauses. The customer's next message returns it to open automatically.
- Step 3
Open ↔ on hold
If another team or a partner must act — finance approval, a courier investigation — the chat goes on hold, so it is excluded from the agent's active queue but stays visible.
- Step 4
Open → resolved
The agent resolves the conversation once the issue is solved, ideally after the customer confirms. Some teams send a CSAT survey at this point.
- Step 5
Resolved → reopened or closed
A customer message within the reopen period (for example, 7 days) reopens the conversation. After the period, an automation closes it; closed conversations are not reopened, and new messages start a new one.
The ticket lifecycle: key facts and limits
- Typical statuses
- New, open, pending, on hold, resolved, closed
- Pending
- Waiting on the customer; resolution timer pauses
- On hold
- Waiting on another team or third party
- Reopen period
- Team-defined, often a few days after resolution
- WhatsApp rule
- After 24 h without a customer message, follow up with a template
Common mix-ups
Common mistakes with the ticket lifecycle
Using pending and on hold interchangeably
If both mean "waiting", nobody knows whether to chase the customer or the finance team. Define pending as customer-owed and on hold as internally or externally owed.
Leaving pending chats forever
Chats waiting on a customer who never replies clog reports. Add an automatic reminder and a rule that resolves the chat after a set silence, with a note.
Closing instead of resolving
Closing immediately means a customer who replies "still broken" starts a new ticket with no history. Resolve first and close only after the reopen period.
Too many custom statuses
Twelve statuses with subtle differences get used inconsistently. Keep the core set and use tags or fields for extra detail.
Example: A Nagpur courier desk cleans up its statuses
A Nagpur courier company's WhatsApp desk used only open and closed. Agents kept chats open while waiting for customers to send address proof, so the backlog showed 900 open chats that were actually idle. It introduces pending (customer owes a reply), on hold (hub investigation) and resolved with a 5-day reopen period. The real backlog drops to about 250, resolution time excludes pending spans, and reopened chats keep their full history instead of arriving as new tickets.
Why the difference matters
Why does the ticket lifecycle matter?
A clear lifecycle tells every agent what to work on next and tells supervisors where work is stuck. Without it, chats waiting on the customer sit in agents' queues, solved chats stay open for weeks, and metrics like backlog and resolution time become meaningless. On WhatsApp, statuses also need to reflect Meta's 24-hour service window: a pending chat that goes quiet for more than a day can only be followed up with a template, so the lifecycle rules should account for it.
Rules of thumb
Best practices for the ticket lifecycle
- Make the customer's reply automatically move pending chats back to open.
- Show the reopen rate per agent; a high rate signals premature resolution.
- Set a reminder template for pending chats that pass the 24-hour window.
- Document each status in one sentence and pin it in the inbox.