Reg readers admit to faking it
Poll results: The frustrations of front line support
Steps to Take Before Choosing a Business Continuity Partner
Reg Reader Studies A Reg reader poll looking at power users and their experiences with customer technical support flushed out a lot of opinions.
The exercise focused particularly on support situations in which IT literate users are calling publicly facing help desks as private individuals, rather than on behalf of their company. In all, we received over 1,300 responses and many of the experiences and insights you shared are extremely enlightening.
Not surprisingly, the majority of power users believe that technical support for consumers is worse than support for commercial users (Figure 1).
In the associated freeform comments gathered during the poll, respondents went on to explain many of the issues that frustrate them.
The thing that seems to drive bad experiences for most power users is being forced to go along with the script that level-one technical support is required to use. It’s not that the scripts used are inherently bad – most of the power users who responded are either IT professionals or have worked in tech support themselves and they understand the purpose of them and why businesses use them – it is the process by which they are forced through the script in a plodding, uncreative way that makes everyone miserable. Additional frustration comes when the front-line technicians are unwilling to do anything other than slavishly follow the script when it’s clear from the start that this isn’t going to solve the problem.
In response to this conundrum, two schools of thought have arisen around how to deal with The Script. One approach, the direct one, is to take on the script and get through it as quickly as possible with minimum wasting of time and effort so the call can continue more productively. The other approach – which gets more interesting – is to find a way around the script. We can call this the evasive approach.
Those who take the direct approach freely admit to faking it. In this scenario the script-reader goes through the motions and the power user pretends to follow – "OK, I need you to reboot the system and choose safe mode" – so the faking techie pauses, examines their fingernails, rearranges the little toys on their desk – and then gives the answer they got when they actually performed the task several hours before they called tech support.
There are benefits to the direct route. Sometimes it is the only way past the gatekeepers – some companies or script readers just have no processes for doing things any other way and faking gets everyone through to the next level if not making everyone happy. Additionally, although power users generally do think of most simple solutions before they call tech support (yes, most power users have already checked power cables and lights before picking up the phone), sometimes the script does yield a suggestion that they hadn’t thought of that solves the problem.
However, there are many users who just don’t have either the time, the patience, or the ego to fake it. These users resort to the evasive method, of which there are several variants that all work to a greater or lesser degree.
The most popular is to state one’s credentials up front. Some front-line techies respect these credentials and will escalate the problem to their level-two colleagues or simply go off script if they also have the requisite technical skills. Unfortunately, though, some script-readers take this request as a personal challenge to their prowess, and/or they become deaf to anything other than what they want to hear – which is usually a direct answer to their script questions.
This leads to another variant of the evasive approach, which involves intimidation or surliness, real or imagined. Again, this works with some technicians who cave in to hostility and quickly escalate the call. This can also lead to a perverse standoff, though, in which the tech support person decides they are either going to be hostile themselves or they begin to reprimand the hostile caller for their hostility.
A third variant is to try requesting or demanding to speak to a supervisor or manager, which also sometimes works, although users overwhelmingly warned that service providers in particular seem to have little or no escalation path in their technical support system. ISPs were singled out for their binary mode of fault determination – e.g. if the line appears to be working from their end then it isn’t their problem. Period.
Finally, many power users lean heavily on the fourth variant, which is to call back and start again until they reach an amenable or knowledgeable support person.
As we read through the hundreds of comments and anecdotes received from respondents, it became very clear that the real problem isn’t with the front line technicians per se – it’s the company processes behind them. Organisations have come to view customer support and contact centers as cost centers, and in the process seem to have forgotten that this part of the organisation is the main face of the company to most users. It is ironic that companies who spend millions on marketing, sales, and brand promotion will shave costs in support and hire the least expensive people possible to populate their contact centers. They will give them minimal training, and will construct business models and metrics that reward technicians for short calls in high volumes – regardless of whether or not those calls actually help users. Additionally, many companies have outsourced their contact centers to countries where there simply aren’t enough of the necessary language skills. The result is frustration, anger, and lost revenue.
In their defence, the vendors often say that this is the price users have to pay for, well, lower prices. Undoubtedly there are business pressures here, but as we have said, most of the issues are caused by processes that do not distinguish between those with little knowledge at one extreme and the tech savvy users experiencing all of the frustration at the other, so the problem is not necessarily one of cost. But it is an issue that the industry needs to take more seriously, and for vendors and service providers that doubt this, check out the picture in Figure 2 below.
With personal experience influencing buying decisions in a business environment, perhaps there is a competitive advantage to be gained by those who take notice and address the issues effectively. Then again, perhaps some companies will rise to the challenge simply because it is the right thing to do. We can live in hope.
COMMENTS
Even Worse for Penguin-Shaggers
Tech support can be an even bigger nightmare if you happen to be running GNU/Linux.
I used to get my broadband from a certain cable TV company which was recently taken over by a certain buffoon with a balloon, then stopped showing "The Simpsons". They provided an (absolutely OS-agnostic, provided you had drivers for your own NIC) RJ45 port on the back of my TV receiver. All I needed to know was how to perform the initial provisioning manually, which the handbook was advised was possible if the included Windows software didn't work for you (bear in mind that I had no access to a Windows PC). At one point, they even tried to tell me that Linux was not compatible with the Internet!
Eventually, I managed to speak to an actual GNU/Linux using tech who talked me through the manual set-up process. Why they couldn't just have put this information in the handbook or on the free beermat (aka Windows/Mac installation CD), I don't know.
Later, I discovered problems with my bundled web space: PHP scripts were displaying the source rather than executing. At first, Tech Support tried to blame me for running Linux on my end (as though the absence of those gratuitous \r characters ever hurt anyone!) and insisted for me to try using a Windows machine instead. Not having access to such a thing, I resorted to outright deception -- I was justified, since they had lied to me first. First I called up a friend who knew both Windows and Linux to translate their instructions for me (eg. "Drag the index.php file to the folder representing your website" => send the file to the server => "put index.php" and "Open it in Notepad" => edit it => "Open it in pico"); then I told them I had borrowed a Windows 2000 laptop. Following their translated instructions, which translated exactly to the same procedure I had already done the first time, I achieved exactly the same ends they were aiming at, only by different means. The logs would betray me, of course; but I figured if they knew how to read a logfile they would have known how to sort my problem out. The result was -- rather unsurprisingly, since I had not done anything different than before -- still a screen full of PHP source code. They got me another support assistant.
Three or four support personnel and countless repeats of the same procedure later, someone explained to me that, being a residential customer, my webspace did not actually include any PHP support (server signature notwithstanding) and I would have to pay extra for this since this was a "business-grade" service! To my mind, that's like promising someone a free car, with a brochure showing how they can wash on a Sunday morning and drape fashion models over it for photo-shoots; then telling them that they need to pay extra for the "sports model" if they want one with an engine so they can actually drive it! Their Linux guru helpfully suggested that I could install Apache and PHP at my own end (as though I hadn't already! Where did they think I had developed that stuff I had written?); however, my IP address was dynamically-assigned and subject to change at any time.
I could go on with a story about how a certain large ISP managed to get one of their SMTP servers listed on a spam blacklist, or how a certain other large ISP arbitrarily decided that mail originating via my company's SMTP server was spam. But you get the idea already.
Views from both sides of the fence
As an ntl broadband customer a few years ago I experienced a problem with my machine getting an IP address of 0.0.0.0. I called their technical support in Swansea and spoke to a guy who must have used a one line script which read "buy a new Network Interface Card". I duly spent £20 on a new network card from Maplin Electronics, installed the driver and hardware but the problem remained. As a last resort I re-installed Windows which resolved the problem.
A couple of years later I experienced another problem getting online via ntl broadband and again I called technical support. I spoke to another technician who was also using the "buy a new Network Interface Card" script who refused to try anything else until I did so. He didn't even ask any diagnostic questions, he just simply offered the above as the solution. Re-installing Windows instead resolved the problem. I never called technical support again.
On the other hand I used to work for a technical call centre which supported PCs bought from stores which were part of a large, international organisation. All I can say is that it was another call centre more obsessed with high call stats that satisfied customers. The number of times I dealt with repeat calls caused by someone quickly rattling through the script to get the customer off the line ready for the next call became quite depressing. Oftentimes the "solution" was to advise people to run their recovery software for the umpteenth time. I was frustrated to be constrained by this script, because if I couldn't prove to a technical coach that all steps had been taken - usually because the (obviously IT literate) caller would say "I've tried everything" and would refuse to elaborate - then I wasn't allowed to book an engineer with a part.
I agree that helpdesks should be more flexible and staffed by intelligent people not constrained by scripts or other procedures. Consumers receiving a positive, helpful experience for their supplier's helpdesk are more likely to recommend that supplier to their friends, family and colleagues.
I used to have hair
I'm with Jeremy above with his comments about BT - I could have written his account myself, except in my case it was the abismally cranky BTHomeHub rather than microfilters. I'm on my 4th in 8 months, and like him I'm just waiting for my contract to expire.
I don't mind hardware breaking down - it happens. But I do mind having to spend several hours on the phone trying to get their customer support to accept there is a problem, even when it's screamingly obvious where the problem lies: "I've temporarily replaced the HomeHub with a wired router, and the problem has gone away. In what way can this NOT be a problem with the HomeHub?"
It use to be an effective strategy to just repeatedly point out that you hadn't changed anything on your system until they gave in and moved down the menu to other factors. But the Bangalore Brigade are so shit-scared of losing their jobs in the only game in town that they are absolutely slavish. When a helpdesk monkey is more concerned with preserving his own skin (understandably) than giving the best service to the customer, something has gone hideously wrong.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Cloud based data management
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
