Prioritizing the Priority of Priorities for the IT Service Manager 

IT Service Managers, Priorities

Typically, when someone announces that a Critical Ticket has been created, everyone is on high alert until someone has engaged, is working through the remediation process, and it’s clear that the Customer is going to be OK.  
What about when something has been sold and the request is to be scheduled? Well, outside of the Customer, Account Manager, and the person responsible for scheduling…no one seems to really notice.   

The Moment We Took a Deeper Look at Prioritization 

“No one seems to notice” may be also be true with Medium and Low Priority Incidents. I still remember the day when Resource Management and Customer Service were called to a conference room to discuss our response times for Medium and Low Priorities.  
The President of the Company had just come back from a series of Customer Satisfaction interviews and had heard how great we were doing with addressing High Priority Incidents. Medium and Low Priorities? Not so well.  
There was one Customer that had a printer issue on the 4th floor, and it was taking us over a month to engage. Yes, there were other printers in the building, but the Employees on the 4th floor were getting pretty tired of walking down to the 2nd floor to retrieve their print jobs. The directive to those of us in the room was to find a way to address Low Priority Incidents in the same way we had with High Priority ones.   
It was at that moment that we sat down and took a deeper look at prioritization 
Priority directly influences: 

  • Internal & External Communication  
  • Ticket flow from cradle to grave  
  • Automation    
  • Tracking Performance  
  • Part of meeting Contractual Obligations  

Incidents & Service Requests: Two Groups of IT Work 

ITIL promotes dividing all IT work into two groups and differentiates by calling them Incidents (Break/Fix, Reactive, etc.) and Service Requests (everything else). An Incident is defined as a network, system, or device that is not working as designed. Therefore, a Service Request is a network, system, or device that is working as designed.   
While the PSA/IMS** software is capable of dividing the work into either Incidents or Service Requests, we use a single data field to further define the characteristics of the requests.  
You guessed it – PrioritiesSince the work is divided at the top level between Incidents and Service Requests, it makes sense to discuss priorities for the two groups separately.  

At the IT Support Center, Treat Priority as a Guideline 

ITIL also promotes an Urgency vs Impact matrix to further define incidents into the four priority levels of CriticalHighMedium, and Low (the matrix is provided below *).   
However, it is in the best interest of the IT Support Center to treat priority as a guideline rather than a hard and fast rule. We all know the “noise” caused when someone wants special treatment and starts making a case as to why the priority needs to be escalated up a level.  
From my experience, it is always easier to make the right decision when the Business Impact is known. All of us want to do our best to relieve the Customer’s pain; the Business Impact helps us to rationalize doing something best for one Customer at the expense of all Customers, or vice versa.  

Let’s Talk About High-Backup 

Besides the four basic Priorities, adding another priority and further defining another type of Incident Ticket merits conversation:   
High-Backup: We have added a priority of High-Backup to ITIL’s list because of its uniqueness and how it is handled in two areas:   
Backups have a different remediation expectation. The average remediation time for resolving a failed backup is less than 2 hours. The notification of a failed backup is usually waiting for you when you come in the next morning and the backup is not scheduled to run again until sometime in the evening or overnight.  
The Impact on liability of missing backups merits a High level of Urgency. Rather than needing to be engaged upon within the High priority first response timeframe, the IT Support Center has until 3pm to engage. Whereas, if the notification of a failed backup comes in from the Customer say at 2 pm, High priority first response timeframe is not soon enough.  

Heads up! Pay attention to these key areas 

  • Area 1: Communication  

Once someone sees the priority is High-Backup either in the ticket or in the notification, they immediately look at the clock on the wall rather than the clock in the ticket to see if this is a high, medium, or low issue.  

  • Area 2: Automation  

With a separate Priority level, the PSA/IMS** software can be set up to automatically set and report on Service Level Agreements and automate the various levels of communications the IT Support Center or Management would like to have in place.  

Problem TicketsProblems represent two special types of Incidents, covered below.  

  1. The same Issue/Sub-Issue is randomly reoccurring over a period of time for one or a few Customers  
  1. A wide area outage effecting multiple Customers within a geographic area       

Once a Problem ticket has been created, or an Incident ticket is escalated to a Problem ticket level, other Incident tickets can be added to the problem ticket. This drives communication to multiple Customers and priority and status can be adjusted from one central location, including ticket completion. The PSA/IMS** software handles Problem tickets quite well in both areas of Communication and Automation.  

  • Is a password reset an Incident or Service Request?   
  • If it is a Service Request, why do we treat it like an Incident?   
  • If it is an Incident, what part of the Password Lockout is not functioning as designed?  

** PSA: Professional Service Automation  
IMS:  Incident Management System   

Based on ITIL’s Urgency and Impact matrix 

Priority Levels  Example 
Critical  Network, Server, Core Application is down 
High  Latency, or other network degradation, key personnel/device 
High – Back Up  Any and All backups 
Medium  Single User with workaround 
Low  Aux equipment with backup 
Sch Event  Non-Incident (Non-Reactive, Non-Breakfix) 
NA/Recurring  Network Administration or other Recurring visit scheduling 
Projects  Uses the Sales Pipeline process 


Stephen Buyze is a Resource Planning Analyst who is “Empowering Service Managers to increase profit.”    


For more about Stephen Buyze:   

To follow me, Stephen Buyze:

Please follow and like us:

Leave a Reply