How would you rate your tech support organization? More specifically, how would you rate its transparency? Do you have any idea what's going on behind that tech support door? Do you have any clue what the tech support crew really does to resolve your problem once you call it in? I didn't think so.
That the support organization is notoriously secretive is the subject of a recent blog post by Nathan McNeill, co-founder and vice president of product strategy at Bomgar, a provider of appliance-based remote support technology. McNeill argued that that kind of secretiveness isn't going to fly for too much longer. He cited Gartner's "Top Predictions for IT Organizations and Users, 2011 and Beyond: IT's Growing Transparency," as the theme encapsulated by Gartner managing vice president Darryl Plummer:
With costs still under pressure, growth opportunities limited and the tolerance to bear risk low, IT faces increased levels of scrutiny from stakeholders both internal and external. As organizations plan for the years ahead, our predictions focus on the impact this scrutiny will have on outcomes, operations, users and reporting. All parties expect greater transparency, and meeting this demand will require that IT become more tightly coupled to the levers of business control.
In his blog post, McNeill made several observations about the discrepancy between Gartner's predictions and where most IT support organizations are now, including this one:
For an industry built to solve problems, it's amazing how hard many support organizations work to convince the customer that the problem A) does not exist, B) is not our problem, or C) will take 48 hours to resolve.
I spoke with McNeill last week to find out why that's the case. His response:
Quite frankly, a lot of it is that it takes a lot of work to be transparent, and to have the efficiencies and the processes to produce transparency. A lot of times the support organization itself doesn't have a really good grasp of what actually happens to fix a problem, and the process that requires-a lot of times that's fairly ad hoc, even internally to the support organization. We do it one way today, we may do it a different way tomorrow. Standardizing that to the degree where you could produce transparency is a lot of work. Producing the transparency requires a little bit of process and logistical prowess that a lot of times they just don't have, or it's not easy to attain. So they just assume that the user doesn't need to know.
In many support organizations as well, there's sort of an antagonistic view of the user. Yes, they are the customer, yes, we can't tick them off too badly. But they don't understand, and they wouldn't understand if we explained it to them. So we don't feel obligated to explain the details of how you troubleshoot a system or how their ticket is processed to someone on the outside.
During our conversation, McNeill expressed the view that one of the biggest "cover-ups" perpetrated by support organizations has to do with "hiding behind" service level agreements (SLA):
In many SLAs, [the time constraint agreed upon for incident rectification] is a fairly long period of time. Twenty-four hours is fairly usual, at least for the internal service desk SLA. Within that 24-hour SLA, it's really difficult to ignore a person, but it's incredibly easy to ignore a ticket. So if you're the support organization, and you want to ignore stuff, the best way to do that is to make it into a ticket. Make all the people that call you into tickets, then you can wait until the end of the SLA and address it. There are some things you can do from a time and efficiency standpoint to figure out which tickets you want to do first. But the fact of the matter is a lot of times what happens is you'll open a ticket, and it could have been resolved in the first 15 minutes, but it didn't seem like the right timing, there were other things you wanted to do first, and so you put it in the queue, with a tickler that says an hour or so out from the end of SLA we'll address this. What happens over time is you end up addressing all the ones that are at the end of the SLA period-the ones that are blinking red-and even though the SLA is 24 hours, the actual time working on each incident is maybe 20 or 30 minutes apiece. So one of the biggest cover-ups is that within a 24-hour SLA, they're not working on your incident for 24 hours.
I asked McNeill what a support executive can do to make his organization more transparent. His response:
It starts with having a better understanding yourself of what the support processes are. We talk to support executives routinely, and a lot of them really don't have a great handle on what their support process is, and what it actually takes to resolve the incident. They know at a high level, but once you drill down a little bit deeper, it gets a lot more fuzzy. We sell remote support software, and one of the things we often ask at the beginning of an engagement is, 'How many remote sessions took place yesterday?' For the vast majority of organizations, they don't know-they have no way of finding out. There's no real way to know how many sessions took place. They don't have the metrics; they don't have an audit trail. So getting to the point where you have visibility into the process, into the tools used, and into your reps' performance is the first step. Because unless you know, the user sure as heck is not going to know.
Obviously, McNeill's purpose in raising all this in his blog in the first place is to make an argument for the value of the appliance-based support technology that his company sells. With that understood, I was impressed enough with McNeill's candor and with the merit of the points he made to throw him a bone. I asked him whether there's anything inherent in appliance-based remote support that helps to promote transparency between tech support and the user community. His response:
Absolutely. The appliance serves as a waypoint between the end user and the rep. So all traffic is going to pass through the appliance, and we're going to log what happens. It's going to give you a record of all the sessions that took place, and the duration of those sessions. It gives you a fairly accurate record of the actual time spent troubleshooting, and it acts as a means of controlling what reps have access to what information. It provides a comprehensive audit trail about what happened, which you can use for audit purposes, or for continued quality improvement.