The best way to sort support tickets is by priority, calculated from impact (how many users or services are affected) and urgency (how long it can wait). Within the same priority, the ticket whose SLA is closest to expiring is handled first. Other criteria, such as customer type or category, help refine that order, not replace it. The sections below explain each criterion, with a ready-to-use priority matrix and an example of a sorted ticket queue.

way order support tickets

Why isn’t first come, first served enough?

Handling tickets in order of arrival seems fair, but it does not reflect what the business needs. For example, a routine query logged ten hours ago cannot go ahead of a newly detected incident that leaves the entire organization without service. The order of work has to be based on the consequences of not resolving each ticket, not on when it was opened.

What criteria are used to prioritize a ticket?

  • Impact: how many users, services or processes are affected. An incident that brings a service down for the whole company is not the same as one that prevents a team from completing a critical task, or one that does not disrupt operations.
  • Urgency: how long it can wait before the business is affected. For example, a failure in the payroll software is more urgent on the 28th, if payroll is issued that day, than at the beginning of the month.
  • Customer or contract type: some organizations handle certain customers first, such as those with a Premium contract, due to contractual commitments or loyalty policies.
  • Category: certain types of incident take priority at specific times. For example, a travel agency launching new destinations in Asia will prioritize incidents related to that campaign.
  • SLA: the time remaining to respond or resolve under the service level agreement. It is mainly used to order tickets that have the same priority.

Impact and urgency determine the priority; the other criteria adjust it or decide the order within each level.

How is priority calculated with an impact and urgency matrix?

The impact and urgency matrix assigns a priority to each combination of the two values. This is an example matrix with four priority levels, which each organization can adjust:

Urgency/Impact High Medium Low
High Critical High Medium
Medium High Medium Low
Low Medium Low Low

Once the matrix is defined, priority no longer depends on who reports the incident or how they describe it: it is calculated the same way for every ticket. The tutorial priority based on impact and urgency explains how to configure it in ServiceTonic.

In what order are tickets with the same priority handled?

Within the same priority level, the ticket whose SLA is closest to expiring is handled first. If two tickets have the same deadline, the older one goes first. This reduces the risk of missing deadlines without changing the general priority criteria.

Example: a sorted ticket queue

A support team’s queue on a Monday at 9:00 a.m.:

Ticket Impact Urgency Priority SLA remaining Order
Email server down for the whole company High High Critical 45 min 1st
Payroll manager cannot access the payroll software on closing day Medium High High 2 h 2nd
New user account for an employee starting on Wednesday Low Medium Low 4 h 3rd
Second-floor printer out of order (another one is available) Medium Low Low 6 h 4th
One user’s laptop running slowly Low Medium Low 1 day 5th

The last three tickets have the same priority (low), so they are ordered by the SLA time remaining. The new user account goes before the printer, even though it was logged later.

How should tickets be prioritized when there is a large backlog?

When the queue grows faster than the team can resolve it, these steps help:

  1. Group tickets for the same problem. If many users report the same outage, their tickets are linked to a single main incident and resolved together.
  2. Handle critical and high priorities first, even if there are older low-priority tickets.
  3. Order the rest by SLA deadline to reduce breaches.
  4. Inform affected users, for example with a notice on the portal, to prevent duplicate tickets.
  5. Redistribute the workload among technicians or temporarily reinforce the first level.
  6. Analyze the cause once the peak is over: if it keeps happening, it is a problem that should be handled through problem management.

How can ticket prioritization be automated?

A ticketing system means priority does not depend on manually reviewing the queue:

  • Priority is calculated when the ticket is logged, based on the impact and urgency matrix.
  • Business rules adjust priority or assignment based on the customer, category or source of the ticket.
  • Queue views are sorted by priority and SLA deadline, so each technician knows what to handle next.
  • Automatic alerts and escalations warn before a deadline expires.

The article on ticket management automation includes practical examples of these rules. To see how a ticket’s status changes in each phase, from logging to closure, see the journey of an incident ticket.

What sets ServiceTonic apart in ticket prioritization?

ServiceTonic is ticketing software in which the impact and urgency matrix, SLAs, and assignment and escalation rules are configured without programming, adapted to each organization’s criteria. Tickets arriving through any channel (web, email, phone, chat or WhatsApp) are prioritized with the same rules. SLAs can vary according to each customer’s contract, and dashboards show in real time which tickets are close to their deadline. All of this is aligned with ITIL best practices.

Frequently asked questions

What is the difference between impact and urgency?

Impact measures the scope of an incident: how many users, services or processes are affected. Urgency measures time: how long the resolution can wait before the business is affected. An incident can have high impact and low urgency, or the other way around.

Can the priority of a ticket be changed after it is logged?

Yes. If the impact or urgency changes, for example because the incident affects more users than expected, the priority is recalculated. The change should be recorded in the ticket history.

Should an important customer get higher priority?

The best approach is to reflect it in their contract, with stricter SLAs, rather than bypassing the priority matrix. That way, preferential treatment is consistent, measurable and does not depend on case-by-case decisions.

How many priority levels should there be?

Four is the usual number: critical, high, medium and low. With fewer levels, it is hard to tell cases apart; with more, technicians hesitate between similar levels and prioritization loses its usefulness.

Who should decide the priority: the user or the technician?

The most reliable option is for the system to calculate it from the ticket data. The user can indicate the impact and urgency they perceive, and the technician can correct them if they do not match the actual situation, recording the change.

Conclusion

A ticket’s priority should not be debated ticket by ticket. It is decided once, when the matrix and SLAs are defined, and then applied the same way to everyone. If the team often has to negotiate what to handle first, the matrix does not reflect what really matters to the business, and that is what needs reviewing, not each individual case.

Would you like to see how tickets are prioritized automatically in ServiceTonic? Request a demo and see how to configure the priority matrix and SLAs based on your own criteria.