A priority matrix only earns its place if two different agents classify the same ticket the same way. This one defines impact and urgency as countable things (how many people, and whether work has already stopped), so the grid produces one answer instead of a conversation.
Define impact by headcount, not by adjective. "High impact" means nothing consistent. "More than 50 people, or any whole team" does. Put real numbers against your own organisation's size: a 40-person company and a 4,000-person one cannot share thresholds.
Define urgency by whether work has already stopped. Urgency is not how loudly someone asked. The useful question is whether the person can do their job right now, and whether a deadline passes if this waits. A VP who is merely annoyed is not urgent; a payroll run at 16:00 is.
Set targets you already hit about 90% of the time. Targets copied from a vendor's sample sheet get breached in week two, and then everybody stops trusting the whole system. Measure what you currently do, set the target slightly tighter, and move it in later.
Write the override rules down. Priority will sometimes be raised by hand, and that is fine. What kills a matrix is undocumented overrides. Name who can override, and require a reason in the ticket, then review overrides monthly to find the thresholds that are actually wrong.
Here's a preview. Unlock the free download to get all 6 sections (5 more below).
Read impact down, urgency across. The cell is the priority. This grid is the whole decision. If an agent needs anything else, the definitions below are too vague.
| Impact \ Urgency | High (work stopped now) | Medium (work impaired) | Low (can wait) |
|---|---|---|---|
| High (org-wide or whole team) | P1 | P2 | P3 |
| Medium (a department or 10+ people) | P2 | P3 | P3 |
More free templates IT teams use alongside this one.
Most internal IT SLAs are copied from a managed-service contract and then quietly abandoned, because they promise things the team was never staffed to deliver. This one starts from what you measurably do today and makes the exclusions explicit, so the document survives contact with a bad month.
Knowledge bases fail because articles are written for the author. The reader is stuck, mildly annoyed, and scanning, which means the fix belongs at the top and the explanation, if any, at the bottom.
Most severity matrices fail in the one moment they matter: at 02:00, when a tired engineer has to decide whether to wake anyone. This one is written so the level is readable off customer impact alone: no judgement call about root cause, no guessing how bad it might get.
A grid that combines the impact of an issue with its urgency to produce a single priority, usually P1 to P4. Each priority then carries a response and resolution target. Its purpose is to make two different agents classify the same ticket identically.
Impact is how many people or how much of the business is affected. Urgency is how soon it has to be fixed: whether work has already stopped, or a deadline passes if it waits. A single user locked out before a board presentation is low impact and high urgency.
Severity measures impact from the user's side. Priority decides what gets worked on first and also accounts for effort, risk, and commitments. Keeping them as separate fields lets you escalate work without misreporting how bad the underlying issue was.
Only if you genuinely staff 24/7. A P1 target measured against a clock nobody is watching produces breach reports that everyone learns to ignore. If you are business-hours only, say so on the matrix and set the expectation honestly.
