A Guide to Ticket Prioritisation: Urgent, High, Normal, and Low
When every ticket in your queue feels equally important, nothing gets the right attention. Your team bounces between password resets and system outages as if they're the same thing. Critical issues pile up while simple requests consume more brainpower than they deserve. The result is buried SLAs, frustrated customers, and burnt-out agents.
Ticket prioritisation — the practice of classifying support requests by impact and urgency — is how you break that cycle. It's not complicated, but it does require clear definitions, consistent criteria, and a system that makes the rules automatic instead of a guessing game every time a ticket lands in the queue.
Why prioritisation matters more than raw speed
Most support teams obsess over first response time. Responding in five minutes is nice. But responding to the right tickets in five minutes while genuinely critical issues sit for hours? That's just noise.
The real measure is resolution quality paired with speed. A team that replies to every ticket within five minutes but takes three days to resolve a customer-impacting outage is not winning — no matter what the response-time dashboard says. Deloitte's research on contact centre performance consistently shows that quality and speed together drive customer satisfaction, not speed alone. Quality assurance in customer support ensures that your prioritisation framework actually translates to better outcomes for customers.
Prioritisation gives your team a repeatable decision-making framework. When the queue is overflowing and everyone is busy, agents should not have to guess which ticket to pick up next. The priority level should tell them. You make faster, more accurate decisions under pressure, and your customers feel heard because the issues that matter to their business actually move first.
Without prioritisation, several predictable things happen:
- Critical issues get buried because they look like everything else
- Simple requests get over-serviced (first in, first out becomes the default rule)
- Escalations spike because customers with urgent problems lose patience
- SLA breaches become routine because there's no mechanism to flag what's actually due
The four standard priority levels
Most helpdesks use a four-tier system. Names vary, but the structure is the same across the industry.
Urgent (P1)
Urgent tickets are incidents, not inconveniences. The core business function is down and there's no workaround.
Examples:
- Your entire platform is unavailable and customers can't log in
- A data breach has been discovered (triggering UK GDPR's 72-hour personal data breach notification requirement)
- Payment processing is failing across all transactions
- A regulatory deadline is at risk due to system failure
Response target: Immediate — ideally within 15 to 30 minutes. Someone should be actively working on this, not queued behind normal requests.
Resolution: As fast as possible. P1 tickets usually pull in senior engineers and trigger escalation.
High (P2)
High-priority issues have significant impact but aren't a total outage. There's likely a workaround, or it affects a subset of users rather than everyone.
Examples:
- A major feature is broken for a specific customer segment
- Performance is severely degraded but the system still works
- A key integration has stopped syncing
- A VIP customer can't complete an important workflow
Response target: Within one to two business hours. High-priority tickets should be picked up before normal and low-priority items.
Resolution: Same business day when possible, or next business day if it arrives late.
Normal (P3)
Normal priority covers the bulk of daily support work. Single users or small groups affected, with a workaround or non-critical feature involved.
Examples:
- A user can't figure out how to export a report
- A minor display issue on one browser
- A feature request causing friction
- Questions about billing or account settings
Response target: Within four to eight business hours.
Resolution: One to three business days, depending on complexity.
Low (P4)
Low-priority tickets are cosmetic, feedback, or time-insensitive requests.
Examples:
- A typo in help documentation
- A feature suggestion
- A cosmetic issue that doesn't affect functionality
- A question about a feature not currently in use
Response target: Within one to two business days.
Resolution: Up to five business days, or moved to a backlog.
Impact and urgency: the decision framework
The most reliable way to assign priority is a matrix that weighs two factors: impact (how many people are affected and how severely) and urgency (how time-sensitive it is).
A system-wide outage has high impact. One user unable to change their profile picture has low impact.
A tax filing deadline tomorrow creates high urgency. A request for a nice-to-have feature has low urgency.
Combine them and the priority falls into place:
| High Urgency | Low Urgency | |
|---|---|---|
| High Impact | Urgent (P1) | High (P2) |
| Low Impact | High (P2) | Normal (P3) or Low (P4) |
This gives agents a repeatable tool instead of relying on intuition or panic. Skills-based routing can then assign each ticket to the right person based on expertise.
Automating priority assignment
Manual prioritisation works at small volumes. At scale, it breaks down. Agents spend time evaluating priority instead of solving problems, and consistency evaporates.
Modern helpdesks automate priority based on rules and triggers:
Keyword rules: Words like "down," "outage," or "data loss" in the subject or body trigger urgent or high priority automatically. Not foolproof, but it catches the obvious stuff.
Customer tier rules: Enterprise customers on premium plans get automatically elevated to high priority. Your most valuable relationships get the attention they're paying for.
Channel rules: Phone calls might default to high priority (customers who call are usually dealing with something more urgent than email). Tickets from a dedicated "report an outage" form could auto-flag as urgent.
AI-assisted classification: Advanced platforms use natural language processing to estimate priority based on sentiment and context. This is increasingly common and more accurate than keyword matching alone.
Helpdesk automation rules and triggers can evaluate incoming tickets against multiple criteria and assign priority before an agent opens the queue.
Building SLAs around priority levels
Once you've defined your four tiers, attach service level agreements to each one. An SLA sets the maximum acceptable time for response and resolution.
Here's a typical structure for a business-hours team:
| Priority | First Response | Resolution Target |
|---|---|---|
| Urgent (P1) | 30 minutes | 4 hours |
| High (P2) | 2 hours | 8 hours |
| Normal (P3) | 8 hours | 24 hours |
| Low (P4) | 24 hours | 72 hours |
These vary by industry and team size. The important thing is that targets exist and are tracked. Set them too tight and you'll breach them constantly. Too loose and they're meaningless.
A real-time support dashboard should alert agents when a ticket approaches its SLA deadline. A ticket sitting at 90% of its response time budget should trigger an alert so someone acts before breach happens. Workflow automation can also set up automatic escalations when SLAs are at risk.
Common pitfalls to avoid
Everything becomes urgent. If customers can set their own priority, many will mark everything as urgent. If agents default to high priority "to be safe," the system becomes meaningless. In a healthy system, urgent tickets should represent fewer than 5% of volume. Everything else is just noise.
Setting and forgetting priority. Initial priority is based on incomplete information. An agent might discover that what looked normal is actually a symptom of a larger problem. Allow priority adjustments as the agent learns more.
Ignoring low-priority tickets indefinitely. Low priority doesn't mean no priority. If low-priority tickets languish for weeks, you damage customer trust. Set reasonable targets even for your lowest tier.
Using priority as a band-aid for capacity. Priority helps with ordering, not staffing. If your team can't meet SLA targets across all tiers, the issue is capacity, not classification.
Forgetting escalation procedures. When a ticket moves from low to high priority, your team should know what that means and who gets notified. Understanding escalation without frustrating customers is worth developing.
Frequently Asked Questions
What if a customer insists their ticket is urgent when it's not? You're in charge of the classification. Explain your prioritisation criteria upfront and help them understand where their issue lands. If they're a VIP, you can elevate it as a courtesy. For most customers, clarity beats appeasement.
How often should we review priority levels? Review quarterly. Look at how many tickets land in each tier and whether criteria still match your product. If urgent is creeping toward 10%, your definition is too broad. If nothing ever hits high priority, it's too narrow.
Can a ticket's priority change during its lifecycle? Absolutely. If the agent discovers the issue is more complex or affects more users than initially reported, bump the priority. Your system should make this easy, not require manager approval.
What percentage of volume should be urgent? Aim for fewer than 5%. If you're consistently running 8–10% urgent, you either have a product quality problem or your definitions need tightening. More than 10% means the system is broken — everything can't be urgent.
Should we let customers select their own priority? No. You'll get a skewed distribution instantly. Ask them to describe urgency in a form field and use that as input for automation rules. But don't let them choose the label themselves.
How do we communicate SLA targets to customers? Be transparent. Include response and resolution targets in your onboarding documentation and support portal. Customers plan better when they know what to expect.
What's the difference between urgent and high priority? Urgent = core business function completely unavailable with no workaround. High = significant impact but users can still work around it, or it affects a subset of your customer base. If users can still do their job (even if it's painful), it's usually high, not urgent.
What do we do with two urgent tickets and one person? Start with the one affecting more users or with the tighter deadline. Communicate status to both parties. If urgent tickets pile up regularly, you need more resources or your definitions are wrong.