Most help desks use four priority levels, P1 (critical) through P4 (low), and each level should carry a written response time and a written resolution time. Priority comes from two questions: how many people and processes are affected (impact), and how soon the damage grows (urgency). If your IT provider cannot show you that table, "urgent" means whatever the loudest person says it means. We are Collett Systems, and this guide gives you the levels, the matrix and real SLA numbers you can hold a provider to.
TL;DR
- Use four levels: P1 Critical, P2 High, P3 Medium, P4 Low. Five levels work too, but more than that rarely helps a small business.
- Priority equals impact combined with urgency. Severity describes how bad the problem is, and priority sets the order of work.
- Published SLAs for P1 commonly promise a 15-minute response and a 4-hour restore target. P4 usually gets several business days.
- A good SLA also states hours of coverage, escalation rules and when the clock pauses.
- Ask any IT provider for the priority table in writing before you sign.
Table of Contents
- What ticket priority means (and how it differs from severity)
- The standard ticket priority levels
- How impact and urgency set the priority
- Sev 1 vs Sev 2
- Help desk SLA examples by priority
- What a help desk SLA should specify
- Setting up your own priority levels
- Why priority levels matter more with a managed provider
- Perspective: what priority levels reveal about an IT provider
- How Collett Systems handles this
- FAQ
- Sources
What ticket priority means (and how it differs from severity)
A ticket's priority is its place in line. It tells the help desk how fast to act compared with everything else open right now. Severity is a different measure: how seriously the problem damages a service, a group of users or a business process. One vendor glossary puts it neatly: severity describes consequence, and priority describes sequence.
The two usually line up, but not always. Severity is how badly an incident degrades service and how many users it hits, while priority is how urgently the team responds. A broken label printer might be low severity, yet a shipping deadline in two hours makes it a high priority. A serious fault with a working workaround can be high severity and still sit lower in the queue.
Four terms get mixed up constantly:
- Impact: how many people or business functions are affected.
- Urgency: how soon the issue must be fixed before real damage occurs.
- Severity: how technically serious the fault is.
- Priority: the final ranking that combines impact and urgency.
Atlassian's incident team treats priority as the more actionable measure, with severity as a key factor that drives it. That is a sound rule for a small business too: customers and staff report symptoms, and the help desk converts them into a priority using fixed criteria.
The standard ticket priority levels
There is no single legal standard. In practice, most organizations land on a four-tier model. Here is the version we find easiest to explain to a business owner.
| Level | Name | What it looks like | Typical examples |
|---|---|---|---|
| P1 | Critical | A major business service is down, many users are blocked, or a security incident is active | Server or network outage, ransomware, production line system offline |
| P2 | High | An important service is degraded or a group of users is blocked | Email down for a department, line-of-business app crawling |
| P3 | Medium | Limited user impact, and a workaround exists | One user cannot print, a shared drive is slow for one team |
| P4 | Low | Minor inconvenience, information request or cosmetic issue | New-hire setup scheduled next week, a software how-to question |
This mirrors a common four-tier model in which P1 covers widespread outages and active security incidents, and P4 covers minor inconveniences and information requests.
The naming differs by tool. Jira Service Management's default priorities run from Lowest to Highest, based on impact and urgency. Another vendor's model uses P1 Critical through P4 Low, with a workaround as the dividing line between the middle tiers. The labels do not matter much. What matters is that each level has a definition a non-technical person can apply and a clock attached to it.
How impact and urgency set the priority
The usual method is a matrix. Incident priority is built from urgency and impact: impact is the effect on business processes, and urgency is how long until the business feels significant damage.
The University of Minnesota uses four impact levels (Extensive, Significant, Moderate, Minor) and four urgency levels (Critical, High, Medium, Low). Many teams simplify to three of each, which gives a 3x3 grid:
| Urgency: High | Urgency: Medium | Urgency: Low | |
|---|---|---|---|
| Impact: High (whole company or site) | P1 | P2 | P3 |
| Impact: Medium (a department) | P2 | P3 | P3 |
| Impact: Low (one person) | P3 | P3 | P4 |
The logic matches what a published matrix guide describes: both high gives you P1 or P2, both low gives you P4 or P5, and the middle is P3.
Questions that score impact and urgency
A practical way to score impact is to ask four things: how productivity is affected, how many users and what type, how many systems or services, and how critical those systems are. Add urgency questions of your own:
- Is money, product or a customer commitment at risk in the next hour?
- Is there a workaround that keeps people working?
- Could this be a security event, such as unusual logins or encrypted files?
- Is a regulatory or contractual deadline attached?
For a manufacturer, "how critical is the system" should be written down in advance. A business impact analysis is the cleanest way to decide which systems sit at the top of the matrix before an outage forces the conversation.
Keep the criteria observable
Priority should not depend on who reported the problem or how annoyed they sound. Severity definitions work best when tied to observable criteria rather than gut feel, because the level triggers real actions: who is called, who is told, how often updates go out. Written definitions and examples for each level also keep assignment consistent across the team. If you are intake-sorting at volume, automating customer service with AI is one way to apply the same definitions to every incoming request.
Sev 1 vs Sev 2
Severity labels (SEV 1, SEV 2, SEV 3) come from software and operations teams, but the idea is the same. At Atlassian, a SEV 1 is a critical incident with very high impact, such as a customer-facing service down for everyone, data loss or a security breach. A SEV 2 is a major incident with significant impact, such as a service unavailable for a subset of customers or a critical function failing. Both trigger an alert to on-call staff at any hour, while SEV 3 can wait for working hours.
Translated to a small business:
- Sev 1 / P1: the whole office or plant cannot work, data is at risk, or an attacker may be inside the network.
- Sev 2 / P2: a department or a critical function is down, but the business still operates in part.
PagerDuty adds a rule worth copying: anything above SEV-3 is a major incident with a more intensive response, and when you are unsure between two levels, treat it as the higher one. Downgrading later costs minutes. Under-reacting to a real P1 can cost a day of production.
Help desk SLA examples by priority
A priority level without a clock is only a label. The SLA attaches two numbers to each level: response time (how soon a person engages) and resolution or restore time (how soon service is back). Here are published examples from public institutions, so you can see the range.
| Priority | University of Minnesota IT | Boston University | UCSF IT |
|---|---|---|---|
| P1 | 15 min response, 4 hr resolution (24/7) | 15 min assignment, 2 hr resolution | 15 min response, 80% resolved under 4 hr |
| P2 | 30 min response, 8 hr resolution | 1 business hr, 4 business hr | 1 hr response, 80% under 8 hr |
| P3 | 1 hr response, 16 hr resolution | 2 business hr, 1 business day | 2 business hr, 80% under 3 business days |
| P4 | 2 hr response, 32 hr resolution | 4 business hr, 3 business days | 1 business day, 80% under 5 business days |
Sources: University of Minnesota (P2 to P4 hours run 8 to 5, Monday to Friday, excluding pending time), Boston University and UCSF IT.
A government example shows how coverage changes the number. The Oklahoma OMES service desk sets P1 at a 15-minute response with a 4-hour restore for local sites, or 8 hours for remote ones. Priority 2 gets a 2-hour response and restore by the end of the next business day. Priority 3 gets an 8-hour response and 3 business days. Priority 4 gets an 8-hour response and 5 business days.
A broader industry benchmark puts P1 at 15 to 30 minutes response and 2 to 4 hours resolution, P2 at 1 to 2 hours and 4 to 8 hours, P3 at 4 to 8 hours and 1 to 2 business days, and P4 at one business day and 3 to 5 business days.
Three patterns stand out:
- P1 response is nearly always 15 minutes, and restore targets cluster around 4 hours.
- Only P1 is 24/7 in most of these tables. Lower levels run on business hours.
- Several use "80% resolved within" language rather than a promise for every ticket. Read that wording closely.
What a help desk SLA should specify
The tables above are only part of a contract. A solid help desk SLA should spell out first response time, resolution time, priority levels, operational hours, escalation rules and pause conditions, such as waiting on a customer reply. Use this as a review checklist for any IT support agreement:
- Definitions for each priority, with examples from your own business, not generic ones.
- Who sets the priority. At UCSF, the customer states urgency and IT personnel judge impact. That split is sensible.
- Response versus resolution. A fast acknowledgment that solves nothing is not service.
- Hours of coverage. Is P1 truly 24/7, including weekends and holiday shifts?
- Escalation path. Who is called when a P1 clock is half used?
- Clock pauses. What stops the timer, and who decides?
- Reporting. Monthly numbers on response and resolution by priority, so you can see whether targets are met.
- Security incidents. Confirm an active attack is automatically P1.
Tie each level to an expectation. For example, a P1 should bring immediate acknowledgment, escalation, frequent updates and continuous ownership, while a P4 can allow a longer window. If you want to see how this reads in a real contract, our example IT service level agreement lays out the structure.
Setting up your own priority levels
If you run a small internal IT function or manage a provider, a workable setup takes an afternoon.
- List your critical systems. Production, ERP, file shares, phones, email, line-of-business apps. Rank them by what an hour of downtime costs.
- Pick four levels. Fewer levels mean fewer arguments.
- Write one-sentence definitions with two real examples each. Examples from your own shop settle disputes faster than adjectives.
- Attach clocks. Start from the ranges above and adjust to your hours of operation.
- Name an override rule. Active security incidents and safety issues jump to P1 regardless of the matrix.
- Review quarterly. If everything is P2, the definitions are too loose.
That last point is the common failure. When every ticket is marked urgent, the fix is a shared definition of urgent that agents and requesters both use, not a lecture. Tie the definitions to what the business loses, and the queue sorts itself.
Security deserves its own line in the table. Ransomware or a suspected account takeover is not a P3 because only one laptop shows symptoms. A written incident response plan states who declares the incident and who is called first, so the help desk is not improvising at 2 a.m.
Why priority levels matter more with a managed provider
With an in-house person, priority is negotiated in the hallway. With an outside provider, it is a contract term. Vague wording like "timely response" gives you nothing to enforce. A defined table, with clocks and coverage hours, turns support into something measurable.
It also changes how a provider is built. A provider that bills hourly earns more when problems last longer. A fixed per-user model aligns the other way: the fewer P1s you have, the better the arrangement works for both sides. That is why we run managed IT as a standardized, fully loaded stack with 24/7 monitoring and proactive support, so many issues are caught before they reach your help desk queue. Our guide on choosing the right managed service provider walks through the other questions to ask.
Perspective: what priority levels reveal about an IT provider
We read a lot of IT contracts from companies that come to us after a bad outage. The pattern is consistent. The agreement says "priority support" and defines nothing. No levels, no clocks, no coverage hours. When something breaks, the customer and the provider argue about whether it was urgent.
We believe priority levels should be boring and written down. Four levels, plain definitions, a response time and a restore target for each, and a clear statement that an active security incident is a P1. Our clients get a standardized stack and defined SLAs, with the same fixed per-user cost, so there is no tier to upgrade to when something serious happens.
Proactive work matters as much as fast response. 24/7 monitoring, security management, backup and disaster recovery are there to keep P1s rare. When one does happen, you should know who calls you, how fast and what the next update looks like.
Dustin Collett
How Collett Systems handles this
We provide managed IT for small and mid-sized businesses in West Bend and Southeastern Wisconsin, with a fixed cost per user, 24/7 monitoring, an unlimited help desk and emergency IT support. If you are not sure how your current setup would perform in a P1, our IT & Security Assessment is the place to start, and our managed IT services page shows what the fixed per-user model covers.
If a system is down right now, our emergency IT services page is the fastest way to reach us.
FAQ
What are the standard ticket priority levels?
Most help desks use four or five levels. A common set is P1 Critical, P2 High, P3 Medium and P4 Low, with an optional P5 for planned or informational work. Each level should have a written definition and a response and resolution target.
What is the difference between a Sev 1 and a Sev 2 incident?
A Sev 1 is a critical incident with very high impact, such as a total outage, data loss or a security breach. A Sev 2 is a major incident with significant but narrower impact, such as one function or a subset of users down. Both usually trigger an immediate alert at any hour, as described in Atlassian's severity guide.
What response times should an IT support SLA include?
Published examples commonly set P1 at a 15-minute response with a 2 to 4 hour restore target. P2 runs roughly 30 minutes to 2 hours for response and 4 to 8 hours for resolution. P3 and P4 stretch to business days. Your SLA should also state coverage hours and what pauses the clock.
How is ticket priority different from severity?
Severity measures how serious the problem is. Priority decides the order of work, using impact, urgency and business deadlines. A serious issue with a workaround can rank below a minor one that blocks a deadline.
Who decides a ticket's priority?
Ideally both sides contribute. The requester states how urgent the problem is for their work, and the help desk judges the wider impact using written criteria. That keeps the level tied to business effect rather than to who sounds most worried.
Sources
- Ticket Severity vs Priority Comparison (ONES)
- Incident Severity vs Priority (Rootly)
- Understanding incident severity levels (Atlassian)
- When Everything Is Urgent: Fixing Ticket Priority Problems (Apps365)
- What are priority levels in Jira Service Management
- IT Incident Criteria (University of Reading)
- University of Minnesota IT incident process
- Incident Priority Matrix (FireHydrant)
- ITIL Priority Matrix (TOPdesk)
- Severity Levels (PagerDuty Docs)
- Priority Matrix (Boston University)
- IT Enterprise SLA (UCSF IT)
- OMES Service Desk Methodology (Oklahoma)
- What's a Good SLA Response Time? (Email Meter)
- Help desk Service Level Agreements (Freshworks)
- How to Automate Customer Service With AI (Naya)