Ticketing
Part of Ticket management systems
Designing ticket statuses around resolution work
Define ticket statuses by the next action, waiting party and return event, then check how your system handles each transition.
Design ticket statuses around the next action. An agent should see whether a case needs work now, is waiting on the customer, is waiting elsewhere, or has a proposed resolution. Every waiting state also needs an owner and a path back to active work.
Define the meaning before the label
For each proposed status, answer two questions: who owes the next action, and what event returns the ticket to active work? If neither is clear, the status is likely to become a holding place.
| Work state | Meaning to agree | Return event to define |
|---|---|---|
| Ready for support | An agent can take the next action | Assignment or agent action |
| Waiting for customer | A specific customer answer is needed | Customer reply or an agreed follow-up review |
| Waiting for another party | A specialist or external party owes a result | Result received or an agreed check-in |
| Resolution proposed | The team has sent or completed its answer | Customer reply or the closure process |
These meanings are suggestions, not product defaults. Where possible, keep issue type, priority and owner in their own fields. “Refund” describes the matter; “urgent” describes its queue order. Neither identifies who must act next.
Four work states defined by who owes the next action
- Ready for supportAn agent can take the next action. Returns to active work on assignment or agent action.
- Waiting for customerA specific customer answer is needed. Returns on a customer reply or an agreed follow-up review.
- Waiting for another partyA specialist or external party owes a result. Returns when the result arrives or at an agreed check-in.
- Resolution proposedThe team has sent or completed its answer. Returns on a customer reply or through the closure process.
Check the actual transitions
Status names can hide different behaviour. In Zendesk's standard lifecycle, Pending means waiting for the requester, and a requester reply returns the ticket to Open. Its optional On-hold status means waiting for someone else. A Closed ticket cannot be reopened by the requester. Configured business rules can affect the path.
Freshdesk documents an automation rule that can reopen resolved tickets when customers respond. That rule can be changed or disabled, so check the account's settings before relying on a reply to move a case into an active view.
Map the transitions the team expects: intake to active work; active work to each waiting state; waiting back to active; active to resolution; and resolution back to assessment if the customer replies. Decide who notices a reply that challenges a proposed solution.
Closure needs its own rule. A resolved or solved state expresses the team's conclusion; a closed state may restrict later changes. Do not mark unfinished work complete just to clear a queue. Keep its next action on a live case.
Transition map to define for every status
- Intake → active work
- Active work → each waiting state
- Each waiting state → back to active work
- Active work → resolution
- Resolution → back to assessment if the customer replies
- Closure ruleunfinished work stays on a live status
Check how your platform actually moves a ticket
- Zendesk Pending means waiting for the requester, and a requester reply returns the ticket to Open
- Zendesk On-hold (an optional status) means waiting for someone else
- A Closed ticket in Zendesk cannot be reopened by the requester
- Zendesk's customer portal shows On-hold to customers as Open, so agent-facing and customer-facing wording can differ
- Freshdesk documents an automation rule that can reopen resolved tickets when customers respond, and that rule can be changed or disabled
- Activating custom statuses in Zendesk turns standard statuses into status categories and updates status-based rules and views
Keep the set small
Add a custom status when it changes a decision: who acts, what appears in a view, what the customer sees or when the team checks back. “Investigating”, “checking” and “working” may be one actionable state if the same person owns all three. Separate waiting on a customer from waiting on a specialist when the team follows them differently.
Product constraints matter. When Zendesk custom statuses are activated, standard statuses become status categories. Activation also updates status-based rules and views, which then need review. Customer-facing wording may differ from the agent-facing label: Zendesk's customer portal, for example, shows On-hold as Open.
Walk through sample requests with no real customer details. For each status, ask an agent to identify the next actor and a supervisor to find cases that have waited too long. Revise any status whose meaning is unclear in the working view.
