Routing & Automation
Part of Ticket management systems
Comparing priority rules with simple first-in queues
Compare first-in, priority and due-time ticket queues, including the exceptions and ageing checks each approach needs.
Use a first-in queue when eligible tickets are broadly comparable and the team can work them in arrival order. Add priority rules when a later case needs attention sooner for a clear reason. Under either approach, check the age of ordinary work so exceptions do not leave it waiting indefinitely.
Define the order
First-in means the oldest eligible ticket is offered or worked first. Decide which time counts: ticket creation, entry into the current queue or the latest customer reply. Those choices can produce different orders after a transfer or reopening. A product may use its own routing-eligibility time rather than the timestamp an agent expects.
Priority order puts a stated exception ahead of an older case. A service commitment, widespread interruption or inability to use a critical function might qualify. Define the evidence required and who may change the priority. A customer's use of the word “urgent” alone is not enough to set a reliable queue rule.
Due-time order uses the nearest response or resolution target. It depends on accurate targets and a clear rule for tickets without them. It also differs from sorting a visible ticket list: a list's display order does not necessarily control automatic assignment.
Compare the trade-offs
| Rule | Advantage | Failure to watch |
|---|---|---|
| First-in among eligible tickets | Clear order with little triage | A later, time-sensitive case waits behind routine work |
| Priority, then age within each level | Explicit exceptions move forward | Lower-priority cases accumulate if exceptions are too broad |
| Nearest due time | Follows configured targets | Missing or incorrect targets give a misleading order |
A workable starting rule is first-in with a small, reviewed exception path. Record who may mark an exception, why it qualifies and when the case returns to ordinary order. If the team has response commitments, include them in the decision and check how the selected system calculates due times.
Check vendor behaviour before adopting a rule
Zendesk says omnichannel routing can be configured to consider factors such as agent capacity, skills, priority and statuses; availability of some factors, including SLA targets, depends on plan. Zendesk also offers sorting by proximity to an SLA breach, subject to plan and configuration.
If using SLA-based ordering, define what happens to tickets without a target rather than assuming they fall before or after older tickets. Zendesk SLA policies can set response and resolution targets based on ticket priority.
Freshdesk Omniroute documents assignment by ticket creation time, response due time or resolution due time for groups with advanced automatic routing. Freshdesk's group-routing guide describes advanced automatic routing (Omniroute) as a routing method.
Changing the assignment preference applies to newly incoming tickets or later reassignments, rather than retroactively reordering all existing work. Freshdesk SLA options also vary by plan and account age.
Vendor Support for Routing Rules in Australia
- Zendesk Omnichannel Routing FeaturesSupports routing by priority, skills, agent capacity, and SLA proximity (plan-dependent)
- Freshdesk Omniroute Assignment OptionsSorts by creation time, response due time, or resolution due time (advanced automatic routing)
- SLA Target HandlingTickets without targets must be explicitly handled—system does not assume placement in queue order
Compare cases in the working queue
Use an illustrative set: an older routine enquiry, a newer service interruption, a transferred case and a customer reply on an existing ticket. Write down the order each rule would produce, including any case without a due time. Check whether agents can explain the order and correct an erroneous priority or target.
Then inspect the oldest ordinary case, unassigned work and tickets repeatedly passed over. Document the timestamp, eligibility conditions and tie-breaker. If exceptions require frequent manual correction, simplify the rule or improve the information captured when tickets enter the queue.
