Ticketing
Ticket management systems
Set up ticket records, statuses, ownership and queue order so support requests have a clear next action.
A ticket management system gives a support team a shared record of each request and a way to decide who acts next. A useful setup clarifies four things: what enters the queue, who owns each ticket, what its status means and which eligible case receives attention first.
What a ticket needs to show
The next agent should understand the customer's request, the conversation so far and the action still required. Keep customer-facing replies distinct from internal notes. Record the contact channel and a reliable reply route, especially when a request moves between people.
Decide which contacts become tickets. An email enquiry may enter automatically; a phone conversation may need an agent to create a record. If the same issue arrives twice, link or merge the records where appropriate. Two contacts from the same person do not necessarily concern the same issue.
Treat the ticket as a lifecycle record
A ticket progresses through a lifecycle from creation to closure. Zendesk describes its stages as represented by ticket statuses, which an agent or a configured business rule may update; a status change both moves the ticket to another stage and communicates progress to the requester.
For the operating model, define what the team needs to know at each lifecycle point: whether work is progressing, waiting, resolved or closed, and who can act next. Keep lifecycle completion distinct from removing a case from an active queue; the system's closure rules determine what happens after resolution.
Ticket Lifecycle Stages in a Support System
- Creation
- Ticket is logged from email, phone, or web form
- Triage
- Agent reviews and assigns to appropriate group or person
- In Progress
- Assigned agent works on the request; status updated as needed
- Waiting on Customer
- Request paused due to need for customer input (e.g., missing info)
- Resolved
- Action completed; customer notified but ticket not yet closed
- Closed
- Case finalised; no further action required unless reopened
Separate the controls that move work
Control / Question it should answer
- Status
- What is happening, and whose action is needed next?
- Group
- Which team handles this type of work?
- Assignee
- Which person takes the next action or coordinates it?
- Priority or due time
- Which eligible ticket receives attention first?
A ticket in the correct group may still lack an individual assignee. An urgent ticket may be waiting for the customer, and a solved ticket may receive another reply. Review the resulting queue rather than treating one field as proof that work is covered.
Use groups to make team ownership legible
A group can represent a shared purpose or scope of work: a business function, region, channel specialisation or customer segment. Freshdesk notes that an agent may belong to multiple groups, so group membership can express team capability without implying that one person owns every ticket in that group.
Group-level configuration can also shape how work is handled across its members. Freshdesk lists settings such as business hours and agent access to tickets assigned to the group, so teams should understand how group membership affects queue visibility.
Give waiting work a return path
Distinguish work an agent can do now from work waiting on someone else. Make the reason for waiting and the route back to active work visible.
Define resolution separately: has the requested action been completed, or has the case merely left an active view? Customer replies after resolution need a clear route back to someone who can assess them.
Make unowned and ageing work visible
Where the system allows it, create a view for tickets with no individual assignee, including tickets already in a group. Name the person who checks it and the review frequency. Separate active work, waiting work and returned replies when those distinctions help agents act. A view is useful only when its conditions match the team's actual status and assignment rules.
Choose a queue order deliberately. First-in order is easy to explain when requests are comparable. Priority or approaching due times can bring time-sensitive cases forward, but older ordinary cases still need attention. Keep the rule simple enough for an agent to explain why a ticket came next.
Make views reflect the work people must pick up
A view is a list of tickets grouped by criteria, not a separate ticket or lifecycle stage. Zendesk gives examples such as unsolved tickets assigned to an agent and new tickets needing triage; criteria can make particular work visible without agents searching the entire ticket pool.
Views can be personal or shared with all agents or a particular group. They can mirror a team's support structure, including service levels or escalation tiers, so the same ticket record can appear in the list relevant to the people expected to act on it.
A team can also use views to express the intended order of work: Zendesk notes that some teams require agents to address one view before moving to others. Treat that as an operating rule, not a guarantee that every ticket in the view is equally urgent; agents still need the team's agreed queue-order criteria.
Check the operating path
Walk through sample cases without real customer information: an ordinary enquiry, a ticket waiting for a customer, one waiting for a specialist, a transfer and a reply after resolution. For each, have an agent find the owner and next action, and a supervisor locate unassigned and ageing cases. Record any step that relies on a particular plan, configuration or manual review.
In this guide
- Designing ticket statuses around resolution workDefine ticket statuses by the next action, waiting party and return event, then check how your system handles each transition.
- Assigning tickets without losing ownershipKeep a clear customer-facing owner through group queues, specialist input, transfers and returned replies.
- Comparing priority rules with simple first-in queuesCompare first-in, priority and due-time ticket queues, including the exceptions and ageing checks each approach needs.
