Properly Using Priorities

Document created by Jason Yeary Employee on Sep 15, 2017
Version 1Show Document
  • View in full screen mode


How do we properly set priorities on our incidents? What does Critical really mean? Should the user have the ability to set these or should we as the support team be responsible for doing that? These are questions facing many customers today and there is no clear answer for them. However, we're here to help you make some sense of it all.


Let's start with what options you have in Samanage.  You have 4 priority levels (Low, Medium, High, and Critical) that can initially be set by the requester or hidden from them altogether. The support team also has the ability to select the priority level or change it if the requester set the priority level initially. If you choose to hide the priority selection from the requester, it would be the support team's responsibility to properly set it.


Now that we know how to set priorities, we're done. Right? Unfortunately, no. We need to understand why we set priorities.


Setting priority levels can help you organize your incidents- that's the most basic benefit. Being able to filter or sort on priority level will allow you to handle incidents in the proper order, as well. There is no reason to handle a Low priority request before a Critical priority one. You will also be able to use these priority levels for reporting. Running a report that shows Average Time to Resolution for Critical incidents for example would allow you to improve on the service you provide your requesters. Our priority levels can also be used to scope SLAs- which is an entirely different conversation (see this Service Level Management Tutorial).


Now for best practices around priorities.


First, who sets the priority level? Best practice is to have your support team set the priority level. Requesters, if given the ability to set priority, will typically set the priority level higher than it needs to be. As a support team, we have our finger on the pulse of the organization and should know where each incident's priority falls in relation to all others.


Second, what do the priority levels really mean? This is the toughest question to answer but probably the most important. With 4 levels of priority, you need to make sure that everyone understands what each priority means and when to use them. Here are some examples of ways you may use each priority level:



   -   Incident is only affecting one person and a workaround is available

   -   Indicates a request that we may not touch for a few days and only if other items are not pressing



   -   Incident is only affecting one person and there is no known workaround

   -   Incident affects multiple people but a workaround is available

   -   Indicates a standard request that will be worked between putting out fires



   -   Incident affects multiple people and there is no known workaround

   -   Incident affects entire organization but a workaround is available

   -   Indicates a request that needs to be addressed right away



   -   Incident affects entire organization and there is no known workaround

   -   Indicates a request that requires immediate attention and could require an all-hands on-deck approach

   -   Should be used sparingly



I know you're thinking to yourself;


That document was fire!!


but if you have any comments or questions, please visit Ask the Community

6 people found this helpful