An incident priority matrix turns two questions into one answer: how many people are affected (impact) and how soon it hurts (urgency). Cross the two on a 3×3 grid and every ticket gets a priority in about ten seconds, with nobody having to argue about who shouts loudest. The matrix itself is the easy part. The definitions you put in each row and column decide whether it works.
Most help desks start with a single “priority” dropdown that the person logging the ticket fills in by feel. Within a month everything is High, because to the person with the broken thing, it is. A matrix pulls that apart. Impact is a fact about the business (how many users, which service). Urgency is a fact about the clock (can they work around it, and for how long). Priority is just the result.
How do you define impact and urgency so people agree?
Write each level so that two agents reading the same ticket land on the same answer. If the definition needs judgement, it will be argued over. Use things you can count or check:
| Level | Impact (who is affected) | Urgency (how soon it hurts) |
|---|---|---|
| High | A whole site, or a service the business earns money through | Work has stopped and there is no workaround |
| Medium | A department or a group of users | Work is slowed, or a workaround exists |
| Low | One user | Nothing stops, the fix can wait |
Notice that every cell is a question with a yes or no answer. “Is there a workaround?” beats “How important is it?” every time. Cal State East Bay publishes its own impact and urgency definitions using four levels each, and its urgency scale hangs on the same kind of test: whether a user can still work and whether a workaround exists. Four levels gives you a 4×4 grid and a lot more cells to argue about. For a team of fewer than fifty agents I’d stay at three.
The urgency column also needs one rule that surprises people: a high-impact incident can still be low urgency. An outage that only touches a reporting server nobody opens until month end affects many users but doesn’t hurt today. Keep the two questions separate and the grid will say so.
What does the 3×3 matrix look like?
Number the levels 1 (high), 2 (medium) and 3 (low) for both impact and urgency, and the nine cells collapse into four priorities:
| Urgency High | Urgency Medium | Urgency Low | |
|---|---|---|---|
| Impact High | P1 | P2 | P3 |
| Impact Medium | P2 | P3 | P4 |
| Impact Low | P3 | P4 | P4 |
One cell is P1, two are P2, three are P3 and three are P4. That shape is deliberate. Only the corner where everyone is affected and nobody can work should ever page a manager at night. If you can’t point at the single cell that earns a P1, you don’t have a P1 definition yet.
The grid also reduces to one formula, which is handy for a spreadsheet or a help desk system that lets you set a calculated field. With impact in B2 and urgency in C2, both entered as 1, 2 or 3:
=MIN(B2+C2-1,4)
Check it against the grid. High and high is 1+1-1, which gives 1. Medium impact with low urgency is 2+3-1, which is 4. Low and low is 3+3-1, which is 5, and the MIN caps it at 4. That is the whole matrix in one cell, and it takes the priority out of the agent’s hands entirely, so the only judgement left is the two honest questions.
What response targets should each priority get?
Priority only matters if it changes what happens next, so attach a response and a resolution target to each level. These are illustrative numbers for a small desk, and your own should come from what the business can actually bear:
| Priority | First response | Restore or work around |
|---|---|---|
| P1 | 15 minutes | 4 hours |
| P2 | 30 minutes | 8 hours |
| P3 | 4 hours | 3 working days |
| P4 | 1 working day | 5 working days |
The same logic sits behind the tiered SLA matrix I walked through earlier: the tiers only mean something once every ticket is sorted into one. And the P1 row needs an owner on top of a clock, which is what an escalation matrix is for. Decide who gets called, in what order, before the first P1 arrives. Running incident, problem, change and release management in a UK customer-operations role taught me that a P1 goes well when everyone already knows whose phone rings first, whatever tools sit underneath.
How do teams break their own matrix?
Three ways, all quiet.
The first is urgency inflation. Users learn that “urgent” gets a faster answer, so every ticket arrives marked urgent. The fix is to stop asking the user for urgency and have the agent set it from the workaround question. The second is the VIP override: a director’s printer jams and it becomes a P1 because of who raised it. Allow a manual override, but make it need a team lead’s name and a one-line reason, and count the overrides.
The third is drift. Nobody checks whether the distribution still looks right. Here’s a sanity test using an illustrative month of 600 tickets: a healthy mix might be about 2% P1 (12 tickets), 10% P2 (60), 38% P3 (228) and 50% P4 (300). If P1s climb to 10% of volume, 60 tickets, either you’re having a very bad quarter or the definitions have slipped. In Excel, =COUNTIF(D2:D601,1)/COUNTA(D2:D601) gives you the P1 share from a priority column in one cell. Put it on the weekly report and review the matrix every quarter, with the business, because their idea of “critical” moves faster than yours.
A priority matrix is a promise about how you will treat people’s problems, so the best test of yours is the one you can run today: take last week’s ten most heated tickets and see which cell each should have landed in. The ones that surprise you are the ones to fix first.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
