Understanding the Incident Priority Matrix

The tickets keep rolling in and they are all over the place. Of course, the blocked printer on floor 7 takes a back seat if all of the company’s internet is under attack by outage monsters. However, situations are rarely that clear-cut. How do you prioritize incidents on a detailed level?

What is Incident Management?

When it comes to Incident Management, you may already know that a task's priority can be determined with the equation 'Impact x Urgency'. But how do we decide in the real world what counts towards these factors? Essentially, there are four things to consider, which will help us map out a priority matrix:

1. How is productivity affected?
2. How many users (and what type of user – perhaps VIP users, or part-time staff) are affected?
3. How many systems or services are affected?
4. How critical are these systems/services to the organization?

To use ourselves as an example (because we know our own organization best): at TOPdesk we work with 5 ‘Impact’ levels: organization, location, department, team and person. "Is this something that risks sinking the entire organization, or something that makes John in Accounting mildly inconvenienced?"

As for ‘Urgency’, we have found that 3 levels are ideal for most organizations: critical, normal, and low. This is the priority matrix we work with (and that is also used in our tool):

By mapping Impact and Urgency on one axis each, it is quite easy to set up a priority matrix that will help the team successfully deal with incidentss in their proper order. As you can understand, it is sometimes called the Impact and Urgency Matrix.

It gives a great overview and means major tasks are dealt with quickly, while more minor tasks are still handled within an acceptable time frame. As a bonus, it also teaches the team the right kind of thinking, so that they can start prioritizing tasks correctly quicker.

Want to know more? Download a template with our Priority Matrix.

Understanding different priority levels

From the formula given above, we can assign any number of priorities. We use up to P7, but this number can differ with the amount of urgency and impact levels you use. Let’s give some real-world examples of what these levels of urgency might correlate to:

Critical priority tasks

A task classed as ‘critical’ (P2 and up) would usually include the following:

• A very important system has gone down;
• There is little to no functionality and there are no workarounds;
• Data has been corrupted;
• The majority of or all users are affected;
• There are potential legal or regulatory ramifications.

Examples of these sorts of failures would be network outages, virus infections, order system failure, or email outages. Of course, there are many more other guises these critical issues could take, but they should usually include most of the above factors.

In context, examples of these kinds of issues would be if a workgroup server crashed, or if a classroom’s technology stops working. Of course, there is a plethora of issues that these factors could encompass, and they are often unique from organization to organization.

Normal priority tasks

‘Normal’ priority tasks usually have priority P3-P5 assigned to them and:

• Basic functionality is available, but with some restrictions;
• Workarounds are available, to some extent;
• Usually more than one user is affected.

These are often standard IT issues, such as non-functioning printers, or when certain vital applications won’t launch on individual machines. Clearly, these issues are still important in allowing your colleagues in other departments to do their day-to-day tasks. However, they are also clearly not as urgent to fix as some of the other examples we have mentioned.

Low importance tasks

Finally, ‘low’ priority tasks ( < P6) consist of minor issues where no functionality is affected and it’s really mostly a cosmetic issue or minor annoyance.

These sorts of issues are most likely to be things like spelling errors or typos on one of the organisation’s web pages. It does need to be fixed, but should not be prioritized above higher impact tasks.

How to act

At this stage, we use SLAs that apply to these priorities. These will vary from organization to organization. But as an example, say we can expect a response to a P1 issue within 15 minutes, and if unresolved, an escalation by the 30-minute mark.

For a P2 issue, we could commit to up to 4 hours as a reasonable fix time, with an escalation in the 5th hour if a solution cannot be found. A P3 task would receive a fix time of 8 hours, with an escalation if unresolved, and P4 would have a full 24 hours, et cetera. But again, these times vary from organization to organization.

Get a full grip with the Incident Priority Matrix

Download our Incident Priority Matrix, along with guides to what kind of incidents receive what priority when, and how to approach Incident Management overall.