Getting Escalated Issues Addressed

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.

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.