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?
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:
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.
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:
A task classed as ‘critical’ (P2 and up) would usually include the following:
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 usually have priority P3-P5 assigned to them and:
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.
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.
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.
Download our Incident Priority Matrix, along with guides to what kind of incidents receive what priority when, and how to approach Incident Management overall.