How to Prioritize Customer Support Tickets
A practical method to prioritize customer support tickets using impact and urgency, clear definitions, examples, SLA targets and daily queue rules that avoid 'everything is urgent'.
When the queue is full, the order in which tickets are handled matters as much as the speed of each answer. Without clear priorities, agents tend to pick easy or recent tickets, loud requesters get faster service and truly critical problems wait. A simple, written prioritization method solves this.
Priority is impact × urgency
Two questions decide priority:
- Impact: how many people or how much of the business is affected? One user, a team, all customers?
- Urgency: how quickly does the damage grow? Is there a deadline, a workaround, money being lost now?
Combine them in a matrix:
| Low urgency (workaround / no deadline) | High urgency (blocked / deadline / losing money) | |
|---|---|---|
| High impact (many users, key process) | High | Urgent |
| Medium impact (one team or important customer process) | Normal | High |
| Low impact (one user, minor issue) | Low | Normal |
Write definitions with examples
Definitions only work when people recognize their own cases in them. Write examples from your business:
| Priority | Definition | Examples |
|---|---|---|
| Urgent | Critical service down or many customers blocked | Checkout fails for all customers; login unavailable |
| High | One customer or process blocked without workaround | A customer cannot issue invoices today; payment charged twice |
| Normal | Problem with workaround, or a standard request | Export to CSV fails but PDF works; change of billing address |
| Low | Questions, suggestions, cosmetic issues | How to change the logo; typo on a page; feature idea |
Share the table with the team and keep it in a staff-only knowledge base article.
Who sets the priority?
Requesters can suggest a priority, but they see only their own problem. Common practice:
- The requester chooses a priority (or the portal sets Normal by default).
- During triage, an agent confirms or adjusts it using the definitions.
- If priority changes, the agent explains briefly when relevant ("we set this as High because it blocks your invoicing").
Recording priority changes in the ticket history keeps the process transparent.
Connect priority to SLA targets
Each priority should have its own first-response and resolution targets. This turns priority into concrete deadlines and lets the queue be sorted by what is due first. For example, an Urgent ticket may require a response within an hour, while a Low ticket can wait two business days. See What Is SLA in Customer Support?.
Rules for working the queue
Priority alone does not decide the order; deadlines and age also matter. A practical rule set:
- Urgent first, always, and with immediate notification to whoever is on duty.
- Then tickets closest to their SLA deadline, regardless of priority.
- Then oldest tickets first within the same priority.
- Pending tickets do not compete for attention until the requester or third party replies.
Sorting the queue by SLA deadline puts rules 2 and 3 into practice automatically.
What should not change priority
- Who the requester is, by itself. Important customers may have contractual SLAs; define them explicitly instead of informally bumping priority.
- How angry the message is. Tone matters for how you reply, not for the impact of the problem.
- How many times someone followed up. Follow-ups signal a communication gap; answer them, but assess priority on impact and urgency.
Special cases
- Security and privacy issues should be High or Urgent by default and restricted to the right people.
- Many tickets about the same problem indicate high impact: link them to one main ticket and raise its priority.
- Low-priority tickets that wait too long become a problem of their own. Set a maximum age and review them weekly.
Example: prioritizing a morning queue
Ten tickets arrived overnight in a software company's support queue:
| Ticket | Description | Priority |
|---|---|---|
| #301 | "Nobody in our company can log in" (company with 40 users) | Urgent |
| #305 | "Double charge on my card" | High |
| #302 | "Report export to Excel fails, PDF works" | Normal |
| #307 | "How do I add a new user?" | Low (send the article) |
| #304 | "Your app is terrible!!! Invoice screen is slow" | Normal (after investigating: slow but working) |
The angry message is not automatically urgent; the login outage is. The how-to question gets a fast answer with a knowledge base link, which takes a minute and removes it from the queue.
In Luradesk
Luradesk uses four priorities (Low, Normal, High and Urgent), which requesters can choose in the portal and agents can change. SLA policies define targets per priority, deadlines appear on each ticket and the ticket list can be filtered by priority and status, with overdue tickets highlighted.
Fair, predictable priorities
Define priority by impact and urgency, write definitions with real examples, let agents confirm priority during triage, link priorities to SLA targets and work the queue by priority and deadline. Clear rules make prioritization fair and predictable.