From my experience, I’ve seen both internal teams and customers classify and escalate tickets to a P1 level when truthfully, they are not priority one tickets. This blog post will hopefully clear up or explain what a P1 or priority one incident is and what it is not. Traditionally, an inbound incident follows a prioritization process that utilizes a reference table based on impact and urgency which correlates a priority. This reference table (IUP) can follow an ITIL standard or be customized for your Service Desk application and organizational needs. Also, many applications will automatically set the priority based on the table values which can eliminate human error. Reference the table below as an example on how to determine priority.
|1 – High||1 – High||1 – Critical|
|1 – High||2 – Medium||2 – High|
|1 – High||3 – Low||3 – Moderate|
|2 – Medium||1 – High||2 – High|
|2 – Medium||2 – Medium||3 – Moderate|
|2 – Medium||3 – Low||4 – Low|
|3 – Low||1 – High||3 – Moderate|
|3 – Low||2 – Medium||4 – Low|
|3 – Low||3 – Low||5 – Planning|
Using the example above, an organization should define their own business logic to determine how the priority is classified and what the appropriate response and resolution times might be. There is an understanding that every organization’s business logic will slightly differ and that priority can immediately change based on to whom or what service the incident is impacting. There is however, one solid truth involved. A priority one incident should involve a system down, service unavailable, or loss of business situation. That is the key element in my opinion. Far too often incidents are set to a P1 status when the service is still available and partially functioning. It may be slow, partially unresponsive, or some users may not be able to login, but whatever the case may be, the bottom line is the service is available. From there it should be a P2 or lower based on the defined business logic that follows impact and urgency.
P1’s are critical, loss of business type events. Be sure you are not crying wolf with an incident that may not be a true priority one as there are usually many people impacted behind the scenes by this type of alert or event. From individual contributors to managers to executive leadership, anyone and everyone could be involved. If a particular service has been restored, even if it is not 100% of what the service objective specifies, it should most likely not be a priority one ticket. If you have not built an IUP table for your organization, do some research and come up with a standard that makes sense to your service management practice. Save the people who support your service time and money… and some sleep most likely.