Getting Escalated Issues Addressed


by Roy Atkinson
January 17, 2017

I hear it again and again: “We escalate a ticket to Level X and then it goes into a black hole or gets bounced back to us. We have trouble getting them to understand that it needs their attention.”

We escalate a ticket to Level X and then it goes into a black hole.
Tweet: We escalate a ticket to Level X and then it goes into a black hole. #techsupport @HDI_Analyst @ThinkHDI

The service desk can’t fix everything, and that should be evident to everyone in your organization. Analysts often don’t have access to the advanced tools it takes to troubleshoot, say, a sticky network issue, and/or may lack the expertise needed. Likewise issues with specific applications such as CRM, ERP and so on. You may already have operational level agreements (OLA’s) in place, but they may not be specific enough or enforceable enough to help you.

During my years as a practitioner on service desk and in desktop support, I had similar experiences, and I learned that there are ways to get this fixed.

Getting the Issue Recognized

Before you can get any issue fixed, it has to be recognized as an issue. (Yes, I’m purposely steering away from the word problem, which has specific meaning in IT service management.) Often, this is where processes start to go wrong. Let’s use that sticky network issue as an example. A customer or end-user calls and says that they are getting intermittent runtime errors from a certain application that only a few people in the organization use. None of the other users have the problem, but they are located in a different building. Your experience tells you to ping the server for that application from the user’s computer (via remote control), and sure enough you see dropped packets. You escalate the ticket to the network administration team with notes about the dropped packets. The next morning, the ticket is back in your assignment queue with the comment “Not a network issue.” Sound familiar?

Do Your Homework

Before passing a ticket along to another group or level, you need to do the work necessary for your assigned role. You also need to document your work. My motto has always been:

If it’s not documented, it’s a rumor.

So, using our example, if you pass that ticket to the network administrator but don’t include the information about the dropped packets, you’re more likely to get the ticket kicked back.

How do you know when you have sufficient information to get their attention? That’s where your OLA’s need to have sufficient detail. If the network admins want a series of pings showing dropped packets over a three-hour period, that information should be documented. You need to find out from them what—exactly—they need from you, what steps you should take and what language they need to see. If you say, for example, “A computer in Building 10” that may not be enough. Do they need the IP address? A traceroute? A switch name? Other information? Do you have access to the information and tools you need to be able to provide the information they are requesting?

Negotiate Now

How do you find these requirements out? You ask. Your manager (if that’s not you) needs to have conversations with the managers of other groups or units to negotiate the terms of your OLA’s, including the language, steps and documentation needed to ensure smooth escalation and response. There should also be clear consequences spelled out for those times when the OLA is breached.

It Matters

However your organization is structured, your support center has a clear role: Keep people working. When cases are delayed, bounced back and forth and argued over, the customer/end-user is the one who is still suffering degradation of service. Customer satisfaction will go down, and the managers of business units will be asking why there’s a service desk if there isn’t any service.


Roy AtkinsonRoy Atkinson is HDI's senior writer/analyst, acting as in-house subject matter expert and chief writer for SupportWorld articles and white papers. In addition to being a member of the HDI International Certification Standards Committee and the HDI Desktop Support Advisory Board, Roy is a popular speaker at HDI conferences and is well known to HDI local chapter audiences. His background is in both service desk and desktop support as well as small-business consulting. Roy is highly rated on social media, especially on the topics of IT service management and customer service. He is a cohost of the very popular #custserv (customer service) chat on Twitter, which celebrated its fifth anniversary on December 9, 2014. He holds a master’s certificate in advanced management strategy from Tulane University’s Freeman School of Business, and he is a certified HDI Support Center Manager. Follow him on Twitter @HDI_Analyst and @RoyAtkinson.


Tag(s): customer experience, customer service, escalation, support center, supportworld

Related:

More from Roy Atkinson


Comments: