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.

Key takeaways

• Priority comes from two questions. Who is stopped, and is there a workaround. See The Matrix
• Four levels are enough for a small team. Name each one by who is stopped. The Four Levels
• Agree the hours with each client. Response, restoration, and resolution are three different clocks. Targets
• Security events go to your security process first. Don't hold them in normal triage. Examples

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.

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.

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.

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".

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.

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.

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:

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.

Common Mistakes With Incident Priority

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:

1. Write the four definitions

   Use the level table above and swap in examples from your own clients or buildings.

2. 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.

3. 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.

4. 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 →

Frequently Asked Questions

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

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

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

What are the 5 key areas of incident management?

Should the client or the technician set the priority?