Stated in ITIL, priority selection should be dependent on 2 other fields in the ticket: Impact and Urgency. There is never a right or wrong answer for priority grading as it can vary between companies.
Stated in ITIL, priority selection should be dependent on 2 other fields in the ticket: Impact and Urgency. There is never a right or wrong answer for priority grading as it can vary between companies.
In the current era of our IT world where IT Staff is always short-handed, we need to know which incident ticket should be handled first. A faulty mouse ticket vs. a company’s website down ticket is obvious, but when it comes to a SAP system ERP service down incident vs. an online booking portal down incident, which one has a higher priority?
To determine this, one has to be experienced in the company and answer the following questions:
– How many staff/users are affected by this incident?
– How critical is this application?
– Is there a business impact with this service failure?
– Is there other dependant services affected as well?
– Who are the affected users?
Of course you can debate there are lots of overlapping processes/factors to cover this areas as well, such as business continuity plans, Service level agreements, CMDB asset relationships, DR plans, etc. But let’s save these discussions for another day but keep to the topic “priority” for now.
You might also want to keep in mind that “priority” field is not just used as a flag for the resolvers. Commonly, this field will also trigger system generated SLA due dates, different escalation/notification rules in the event of breech, or a high priority ticket can sometimes be used to by-pass a normal change management approval process, triggering an emergency RFC. In monthly report reviews, having a common understanding on the ground rules of priority grading system can lead to better management decisions.
Keep a lookout for my next blog entry on Common ways we can determine a priority!