Ticket Priority Best Practices for IT Support
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 – Priorities. Since 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
For INCIDENTS: ITIL also promotes an Urgency vs Impact matrix to further define incidents into the four priority levels of Critical, High, Medium, 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: Uniqueness 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 Tickets: Problems represent two special types of Incidents, covered below.
The same Issue/Sub-Issue is randomly reoccurring over a period of time for one or a few Customers
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
Stephen Buyze is a Resource Planning Analyst who is “Empowering Service Managers to increase profit.”
For more about Stephen Buyze: www.SBuyze.com
To follow me, Stephen Buyze: www.SBuyze.com/Blog/