Incident Priority Levels: P1–P4 Matrix For Small IT Teams

Incident priority levels are the ranks, usually P1 to P4, that tell a helpdesk what to work first and how fast. You set a ticket's level from two answers: how many people are stopped (impact) and how soon it hurts (urgency).

Below: four definitions, our example grid, two published sets of targets, and worked examples. They come from the team behind SherpaDesk, a helpdesk and PSA (professional services automation) tool a small IT team can run alone.

What Are Incident Priority Levels?

An incident priority level is a label on the ticket that sets its place in the queue and the clock it runs on. Most organizations prioritize incidents in a ticketing system, and IT staff respond to each incident according to its level.

Definition

Impact is the effect of the incident on the organization: how many people it stops and which business function it blocks. Urgency is how quickly it needs to be resolved: a fixed deadline, no workaround, or a problem getting worse.

The two don't always move together. Boston University gives the textbook case: a high-impact incident can have low urgency if the impact won't land until the end of the financial year.

Why Priority Levels Matter On A Small Team

On a small team, the loudest email usually wins the next hour. Written levels replace that with a rule. The UK Cabinet Office requires every incident to be classified by impact and urgency because it "ensures a consistent response".

The level also decides more than order:

The clock. Response and resolution targets hang on the level, so a wrong level sets a wrong deadline.
Who gets told. At Boston University the cell in the grid also names the channel. It runs from a ticket notification for one person to status-page posts and possible broadcast mail for a campus-wide outage.
What happens after. McGill treats priority 1 and 2 as major incidents with their own process. The Cabinet Office requires a post-incident review for every P1 and P2.

One r/sysadmin thread put it in its title: "If everything is a 'Critical' priority, then nothing is".

P1 To P4: What Each Level Means

These are our four levels for a small MSP or internal IT team. Name each one by who is stopped, not by an adjective like "high", because two technicians read "high" two ways. Each covers cells of the grid below.

Four levels for a small IT team
Level	Covers	Example
P1 Company stopped	The whole company or a site can't do required work	Internet down at a 30-person office
P2 Team stopped	A team or one user can't do required work; or the whole company slowed but working	Front office phones dead at one school
P3 Workaround exists	A team or one user slowed but able to work	One projector out; a spare cart is free
P4 Request	Nobody affected: a request, a question, or one redundant part failed with no data at risk	Access to a shared folder; one of two power supplies failed

The Impact And Urgency Priority Matrix

This is our example grid for a small team, not a standard. Ask who is affected: the whole company or site, a team, or one user. Then ask whether people can't do required work, can work but slowly, or aren't affected. The cell where the answers meet is the level.

Example Priority Matrix For A Small IT Team
Urgency ↓ · Impact →	Whole company or site	A team	One user
Can't do required work	P1	P2	P2
Slowed but workable, with or without a workaround	P2	P3	P3
Nobody affected (request, question, redundant part failed, no data at risk)	P4	P4	P4

One rule adjusts the grid: a fixed deadline raises urgency. A workaround stops counting when it can't meet the deadline. Say a bookkeeper's laptop is slow but works: P3. On payroll day, with the run due at noon, the slow laptop can't get payroll out, so treat the user as stopped: P2.

Planned requests keep their own date. A laptop for Monday's new hire is P4, with the due date agreed separately. Priority sets the order; the due date sets when it's done.

Public grids vary in size. McGill runs four by four and puts one person whose work is completely halted at priority 3. Our grid makes that user a P2, because at a small client one bookkeeper can be the whole finance function.

Severity Vs Priority

Severity is the scale of the impact. Priority is the order of handling. The ISTQB testing glossary draws the same line for defects: severity is "the degree of impact", priority "the level of importance assigned to a task".

Severity

How large the impact is.

Judged from what broke and who it hits
Grows or shrinks as the scope becomes clear
Feeds reporting and review

Priority

When the team works on it.

Judged from impact and urgency
Changes when deadlines or workarounds change
Sets the queue order and the clock

Example: two separate tickets, each from one user who can't open the accounting app but can limp along on a shared PC. Same severity. One has payroll due at noon, so the workaround can't meet the deadline: P2. The other is closing next week's invoices: P3.

If you don't use severity for routing, escalation, or reporting, one priority field is enough. Keep the technical detail in the notes.

Response And Resolution Targets For Each Level

Each level gets up to three clocks. Response is the first reply. Restoration means the user can work again, maybe on a workaround. Resolution means the fault is fixed. As one r/msp member put it, "A response is different than a resolution."

We've published two examples. Both are starting points to agree with each client, not a standard.

Two example target sets: our SOP and our SLA template
Level	SOP: first reply	SOP: resolve	SLA: response	SLA: restoration	SLA: resolution
P1	15 minutes	4 hours	30 minutes, any time	4 hours, any time	3 business days
P2	1 hour	1 business day	1 business hour	1 business day	3 business days
P3	4 hours	3 business days	4 business hours	Not used	5 business days
P4	1 business day	5 business days	1 business day	Not used	10 business days

The SOP set comes from the triage step in our Helpdesk SOPs; the SLA set is the filled-in example in our SLA Template. In the SLA example, a business day is 9 coverage hours: 8 a.m. to 5 p.m. Mountain, weekdays, excluding U.S. federal holidays. For the SOP set, you and the client agree the calendar. One setup option: agree the client's targets first, then give your team internal targets at or inside them, so a busy morning doesn't become a miss.

Three organizations publish theirs. These are their policies, not an industry norm. The Cabinet Office counts an incident resolved when the incident lead agrees the service is restored.

Published targets at three organizations
Level	UK Cabinet Office, in-hours: response · resolved (service restored)	Boston University, hours 24/7, business hours 9–5 weekdays: initial assignment · resolution	Emory default, 8–5 weekdays, excluding holidays: response · resolution
P1	20 minutes · 1 hour	15 minutes · 2 hours	1 hour · 8 hours
P2	1 hour · 4–8 hours	1 business hour · 4 business hours	6 hours · 48 hours
P3	2 hours · 1–2 business days	2 business hours · 1 business day	12 hours · 96 hours
P4	4 hours · 3–5 business days	4 business hours · 3 business days	18 hours · 384 hours

Checked October 2026.

Worked Examples From A Small Team's Queue

Our grid, applied to tickets from an MSP, an internal IT team, and a school:

Example tickets, run through the matrix
Ticket	Impact	Urgency	Level	Why
Internet down at a client's office	Whole company	Stopped	P1	Nobody can work; phone the contact
Copier asks for SharePoint credentials; nobody can scan	A team	Stopped, needed today	P2	No workaround, fixed deadline
Sales team's shared drive offline	A team	Stopped	P2	Quotes can't go out
One classroom's Chromebook cart won't join Wi-Fi	A team	Spare cart in the library	P3	Workaround exists
Laptop for a hire starting Monday	Nobody yet	Request	P4	Due date agreed separately
User clicked a link in a phishing email	Unknown	Unknown	Security process	Escalate at once; that process classifies it

The copier row is a real r/msp case: no one could scan to SharePoint, and the client needed it done by the end of the day. The poster judged it "a medium- or high-priority issue" on a 3×3 impact-urgency matrix. Our grid makes it P2.

Security events go straight to your security process, and normal triage must not delay that escalation. The Cabinet Office keeps cyber security incidents and data breaches on separate, formal processes, and its P1 includes ongoing unauthorized access. Our triage SOP tells the technician to skip the grid and hand over at once.

Subscribe to the SherpaDesk Blog.
Get Tips for Running IT With a Small Team.

Loading form…

Common Mistakes With Incident Priority

Name each level by who is stopped and give a client example
Re-rate a ticket when the impact spreads or a workaround appears
Keep requests on P4 with their own due dates
Write a one-line reason when you set or change a level

Don't

Let the subject line or the sender's title set the level
Mark tickets P1 just in case
Add a fifth or sixth level before four work
Hold a phishing report in the normal queue

Inflation. When every ticket is P1, the real outage waits behind a printer. One r/sysadmin commenter remembered a technician's rule: you can have exactly one "#1 Priority".

Seniority by accident. The Cabinet Office lists seniority as an impact factor, alongside scope, the business function blocked, and data at risk. If the owner's laptop gets faster service, write that into the grid.

A level that never moves. Urgency includes the rate of degradation: is the problem getting worse? A slow file server at 9 a.m. can be a stopped office by 10.

How To Roll Out Incident Priority Levels

Four steps, with the helpdesk you already have:

Write the four definitions

Use the level table above and swap in examples from your own clients or buildings.
Agree targets with each client

Start from one of the example sets and agree response, restoration, and resolution times. Our SLA Template has the fields.
Put the levels in your helpdesk, not a wiki

The tool needs a priority field, a target per priority, your business hours, and a report by priority. Targets that live in a document don't start a clock.
Test on last month's tickets, then review monthly

Have two technicians rate 20 closed tickets on their own. Where they disagree, rewrite that definition. Then review on-time results per level once a month.

Example: Emory notifies the assignee at 50% and 75% of the target, and the group manager at a breach.

To formalize more than priorities, see our Helpdesk Vs Service Desk guide.

Set It Up In SherpaDesk

How this works in SherpaDesk

Each Priority Carries Its Own Clock

You can give each priority two SLA goals, response and completion, and define your business hours and holidays. On the ticket, your technicians see the SLA Due By, Waited, and Completion times. Business-rules routing can assign tickets by issue type, user organization, or severity, to one agent or a group. Technicians can also act on a ticket by replying to its email; the commands include cmd priority.

For the monthly review, Reports > SLA & Priority gives you an On-Time Report and a Goal vs. Actual Report on closed tickets, by response or completion.

A helpdesk and PSA a small IT team can run alone. SherpaDesk itself has no contract. No implementation project. No dedicated admin. Base Camp is $45 per agent per month ($40 billed annually), the first agent is free, forever, and the trial is 14 days free with no card.

See SherpaDesk Pricing

Who this isn't for

Software teams that page an on-call engineer around the clock need a severity scale tied to their alerting, not a helpdesk grid.

Frequently Asked Questions

What is the ITIL incident priority matrix and how is it used?

It's an impact and urgency grid like the ones the UK Cabinet Office and Emory publish. In TechTarget's account of the ITIL workflow, prioritization comes after logging and categorization, by urgency and importance. Grid size varies: Emory uses three by three, McGill four by four.

What is a P1, P2, P3, P4 SLA?

It's an SLA with a target per priority; the agreement sets the times. Our levels: P1, a company or site can't do required work. P2, a team or one user can't work, or the company slowed. P3, a team or one user slowed but working. P4, a request, question, or redundant part failure, no data at risk.

Which category has the highest severity: 1, 2, 3, or 4?

Category 1, on the UK National Cyber Security Centre's scale. It grades cyber incidents on six levels of severity, from Category 1, a national cyber emergency, down to Category 6, "Localised incident". Check each scale's legend before you compare two of them.

What are the 5 key areas of incident management?

TechTarget's description of the ITIL incident workflow starts with five steps: identification, logging, categorization, prioritization, and response. Diagnosis, escalation, resolution and recovery, and closure follow. Priority levels do their work in the fourth step, where they set the order and the targets for everything after it.

Should the client or the technician set the priority?

The technician sets it at triage, from the client's answers about who is stopped and whether there's a workaround. The client says how urgent it feels; the grid turns that into a level. In our SLA Template example, clients report P1 issues by phone and everything else by portal or email.

About the author

Patrick Clements Co-founder & CEO, SherpaDesk

Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.

All Articles

Published Oct 29, 2026 by Patrick Clements

Incident Priority Levels: The P1–P4 Matrix For Small IT Teams