Incident Priority Matrix: Set Ticket Urgency and Ownership

Why Do Tickets Feel Random?

When priority is decided by whoever happens to open the ticket, it's decided by mood, workload, and how well that tech knows the client. One tech reads "email down for one user" and thinks P3. Another thinks "controller" and jumps it. Same ticket, two outcomes.

An intake rule gives different technicians a consistent way to assess the same request. Write down the questions and how the answers determine priority and ownership.

What Are the Four Questions?

Ask these four questions on every ticket, at creation, before anyone touches it:

• What is broken?
• Who is affected?
• How many users are impacted?
• Is there a workaround?

Build the questions into the portal form or ask them during intake calls. Take the email example: one user, the controller, and they can use webmail while the desktop client is broken. Workaround exists, so the ticket is P3 and it goes to the L1 on the incident rotation.

Without the workaround question, you'd have guessed wrong. With it, you have a defensible priority in under two minutes.

How Do I Set Priority in Two Factors?

Two factors, and only two: impact and urgency. Impact is how many users are affected and whether work stops. Urgency is whether a workaround exists. Cross them and you get a priority that never depends on who's looking at the ticket.

The rule that trips people up: a single user with no workaround is P2, not P3. The controller with no webmail access cannot do their job, so it's high impact even though it's one person. Your email ticket has a workaround, so it drops to P3. Every combination has an answer, and none of them depend on a tech's gut.

P1s are different. My recommendation: a genuine P1 gets phoned in and judged by a person, an L1 or the service manager. Emailed tickets default to P3; a claimed P1 has to be phoned in. The point is verification. My reasoning: a person on the phone can ask what is actually down before anyone drops their work.

If you have a client who emails "URGENT" on every ticket, the phone rule forces a call to verify. It takes time, but it's the cost of a system that doesn't reward the loudest flag.

Who Owns This Ticket?

Priority tells you how fast to work. Ownership tells you who works. Every ticket category gets a named owner, assigned at creation, with a named backup. No owner means no accountability, and no backup means one sick day stalls the board.

In a PSA that supports auto-assignment, set rules that route by category and priority, and have the service manager review triage volume and tech time to catch misassignments. One MSP owner reports using Autotask workflow rules to route selected tickets, while a service manager raised higher-priority tickets and reviewed triage volume and technician time. If your PSA cannot auto-assign, the owner list is still the answer: the intake questions determine the category, the category determines the owner, and the owner gets the ticket the moment it's created.

If you don't have a dedicated service manager, share the owner list and cross-train so at least two techs can own each category. The list should not rest on one person's availability.

When Does This Fall Apart?

No system survives a team with no backup plan or a client who cannot adapt to structured intake. Here's where this approach breaks, and what to do about it.

• A client who emails "urgent" on everything: make P1s phone-only and have the L1 verify. Another owner reports setting email tickets to P3, allowing P2 through P5 through the portal, and requiring genuine P1s by phone for an L1 technician to judge.
• The named owner is on leave: every category needs a backup, identified in advance. Cross-train before someone's out, not after.
• The rule is too rigid for a VIP password reset: that's low impact but time-sensitive. Give it an exception path: it stays P3 by the rule, but the service manager can flag it for immediate action. One rule, one override, owned by one person.
• Email-only clients make scripted intake hard: you can't ask four questions over email without annoying them. Send the intake questions back once, then call if they don't answer. This is a real constraint, and it may mean some tickets take longer to classify.
• Clients used to free-form urgency flags may need coaching on how to use fixed priority options in the portal. Another owner reports offering fixed priority choices in the ticket portal instead of a free-form urgent flag.
• No one's available to answer the phone for a P1 off-hours: if you take after-hours calls, someone has to own that line, or you're accepting P1s you can't act on.

The service manager, or whoever owns triage, reviews misclassifications weekly. Not to punish, to tune the rule and the owner list. The first month is where you find out which clients need coaching and which categories need a different owner.

What Should I Do on Monday?

Three things, this week:

1. Print the four questions and the priority table. Post them at the service desk and add them to your PSA's intake form if it supports custom fields.
2. Write the category-to-owner list, with backups, and put it in the PSA's assignment notes.
3. Schedule a 30-minute team meeting. Pilot the questions on the next ten tickets and adjust the owner list based on where tickets stalled.

Review bounced tickets, status inquiries and response times after introducing the intake rules. Adjust the questions where the team still lacks enough information to assign priority.