Tech & Work

Not all IT incidents are created equal: How to manage escalations

IT requests range in severity and priority, but sometimes support incidents must be escalated for the sake of the user and the company.

hero

Image: Ant Pruitt/TechRepublic

One of your users is frustrated with IT because their sticky S key is making the morning data entry difficult and nobody has shown up to fix it. Another user needs to send a proposal to a prospect and Excel refuses to save the formulas. Frustrating, ill-timed moments like these will happen in everyone's day-to-day enterprise computing, and it's up to the IT support staff to prioritize just how soon each issue can be addressed and resolved. The IT incident management hierarchy may not be the most popular in your organization, but it can definitely aid in optimal information systems performance.

All IT incidents are important

Yes, all IT incidents are important—to a certain extent. Enterprise IT does a good job of creating service level agreements (SLAs) that set expectations on when and how IT support incidents and requests are handled. Typically, there's a rating decision tree that relates to the level of severity. For example, priority-1 is the most severe and priority-5 is the least. Incidents affecting the whole enterprise or that are publicly facing are definitely the highest priority. Anything below these high priority incidents or requests are defined in the SLAs.

The problems come when end users demand that their issues to be escalated to a higher priority.

SEE: How to go beyond the reboot to provide topnotch tech support

My IT incident Is REALLY important

An escalation request happens when someone asks that a logged IT incident is granted a higher priority to gain a quicker resolution. Sure, a user's IT incident may be super important to them, but it may not warrant escalation above other incidents being worked by IT. The discussion of escalations can bring about tension between the IT department and users. It may even bring tension within the IT department because of workloads.

The escalation process can turn into a battle of egos if you're not careful. Everyone feels their problem is more important than anyone else's. Sometimes, IT has to be the bad guy and challenge those egos for the sake of efficiency and for the enterprise. Let's take a look at a few typical support incidents submitted each day.

Image A

Image: iStockphoto.com/Minerva Studio

The broken mouse incident

A requester is having issues with the mouse tracking successfully on their screen. This is making it difficult to drill into cells on a spreadsheet. Frustration is high and the requester demands the mouse be replaced immediately—insisting on escalation.

IT support sees this request and can empathize. But there is protocol to address before issuing a new mouse. Is the mouse properly connected to the computer? Is the mouse on a fancy wood grained desk pattern not allowing the light to properly sense position? Has the computer been rebooted?

Most of the time, the mouse issue can be resolved by following those troubleshooting steps. No need to stop a technician from what they're doing and force them to run up four flights of stairs and hand deliver a mouse.

"But Ant, this is the CEO of the company who needs a new mouse."

In that case, you might escalate the incident because of the corporate hierarchy. Yeah, I know that the CEO is just another human who puts their trousers on one leg at a time like the rest of us. But there comes an inherent amount of respect for the company's fearless leader that says, "We better keep the CEO happy."

See: Support when you don't really have a help desk

I hate the printer

Sometimes, low priority incidents can be escalated. It all depends upon the situation at hand. For example, printer maintenance. Printers are not the favorite items in any office. They jam more often than actually printing, they make a lot of noise and sometimes they take up a lot of space. A user sends a print job to the printer closest to their cubicle, and the printer jams. They clear the jam, resend the print job and the printer jams again. Frustrated, the user notifies IT and prints at a different printer in the interim. Several hours pass and the printer is still out of order. By now, the user and other users are unhappy with IT as no one has attempted to resolve the issue and inconvenienced several colleagues.

Is this an escalation? Yes. Sure the colleagues can easily print to a different printer, but IT should have at least acknowledged the original request to let users know when or if the issue could be resolved soon. This is probably mentioned in the SLA anyway.

The automatic escalation

There are times when a request for IT support comes in and it's a "Stop what you're doing" request. Clients report an HTTP 500 status error on the website, the corporate payroll system goes offline, the phone system fails. All of these are examples of immediate escalation requests. No one across the enterprise will argue against support for related issues of this magnitude. But even though these incidents may seem obvious, they should still be a part of the documented SLAs for the company.

Also read...

Your take

Though the escalation process can sting an ego or two, it puts the interest of the company and the user first. It allows IT to resolve incidents more efficiently and keep the end users happy.

Do you have an escalation procedure in place? Share your thoughts in the comments below.

About Ant Pruitt

Ant Pruitt is an IT Support Professional with a passion for showing the non-geek how great technology can be. He writes for a variety of tech publications and hosts his own podcast. Ant is also an avid photographer and weight lifter.

Editor's Picks

Free Newsletters, In your Inbox