Likewise for agreeing on urgency, the agreement could take the following shape.Ī. Low impact if the number of users impacted is less than 10 Medium impact if the users affected are more than 10 and not more than 100Ĭ. High impact if more than 100 users are affected, or 50% of a project team are affectedī. The agreement could look something like this.Ī. It is critical that the various levels of impact and urgency are documented in an agreement with the customer and charged accordingly. Remember that the incident prioritization is done by the service desk who are junior staff. A word of caution – don’t complicate matters by having too many than can be handled. You can have any number of levels of impact and urgency as you would like. So, according to the agreement with the customer, if we determine that the impact and urgency is high, we would plug in priority 1 for the incident and incident priority deduction is similar for the remaining elements in the matrix. In the sample incident priority matrix, there are three levels of impact and three levels of urgency considered. So, when you map these two together across a matrix as indicated below, you will be able to determine the priority of an incident. Urgency is how quickly the business expects a resolution. It could be in terms of number of users, financial losses or loss of reputation. Impact is the loss that the business is facing due to the incident. Incident priority is mainly based on two elements – impact and urgency. In this piece, I will provide basic tips that you can leverage on to come up with incident priorities which could be standardized across all service lines and customers. No matter what the basic principles are in terms of mapping priority to incidents, there are always lingering questions whether the chosen priority is indeed the right one.
Tagging incidents with the right priority has been a questionable topic across organizations that are practicing ITIL.