Emerging Tech

Never undervalue your experienced support technicians

Perhaps the biggest IT management oversight in the solar system is the undervaluation of experienced technicians.

Malcolm Gladwell begins his book Blink with a story of an art dealer, Gianfranco Becchina. In 1983, Becchina offered the J. Paul Getty Museum a marble statue he claimed dated from the 6th century BC. The sculpture, known as a Kouros, was of a nude male youth standing with his left leg forward and his arms at his sides.

Becchina's asking price was, in essence, a ten-million dollar question: "Is the statue legitimate or a superb forgery?" The Getty museum kept the statue on loan and spent 14 months trying to answer that expensive question.

The Getty brought in a geologist from the University of California, who examined the statue over two days with a stereomicroscope. He believed the statue was very old and made of dolomite marble from the Cape Vathy quarry on the island of Thasos.

Stereomicroscopes, apparently, can be deceiving. Gladwell explained,

The Kouros had a problem. It didn't look right. The first to point this out was an Italian art historian named Federico Zeri. When Zeri was taken down to the museum's restoration studio to see the Kouros, he found himself staring at the sculpture's fingernails. In a way he couldn't immediately articulate, they seemed wrong to him.

Thomas Hoving, the former director of the Metropolitan Museum in New York looked at it. His first thought was "fresh."  "And fresh," Gladwell notes, "is not the right reaction to a 2,000-year old statue." Having turned to the Getty's curator and asking if he had paid for it, Hoving then said, "If you haven't, don't; if you have, try to get your money back."

In the end, the letters Becchina supplied to the Getty tracing the sculpture's previous ownership turned out to be fake. The sculpture was a forgery. Very similar to a fragment produced by a forger in Rome in the early 1980s.

The adaptive unconscious in technical support

Gladwell believes the art historians took a look at the statue and did a series of instant calculations. The part of the brain that constructs these quick conclusions from a large storehouse of data is called the adaptive unconscious. I believe the use of the adaptive unconscious is common in people with a lot of experience in technical support. (This definition of the "unconscious" is distinct from the "unconscious" defined by Freud. Don't even go there.)

Rarely do experienced troubleshooters consciously think about what they're doing (the process) when diagnosing a user's problem because they've done it so many times. We ask general, but essential, questions first. After four or five general questions, we start asking specific questions.

We're not following a script. Our questions are dynamic and are formed based on the answers the users give to the previous questions as well as our experience, which places their answers in a larger context.

Without even knowing it, we filter potential problems through our large "experiences" database and rank suspected causes on a scale of probability. Then, by process of elimination, we go after the issue, checking the most likely cause first. The effectiveness of our unconscious is directly related to the amount of relevant data stored there. There has to be a significant sample size of pertinent experiences to draw from, which we then adapt to our current problem.

When we use the term "gut feeling," we're talking about the adaptive unconscious. But my point is our unconscious also contains a ton of loosely cataloged, objective information as Gladwell's story illustrates.

Of course, some problems are so simple we just use conscious memory. We're like a blindfolded passenger in a car driven by a lost user. In our memory is an excellent map of the town. Our job is to ask the user questions to give us some landmarks so we can tell them where to turn to get home.

The two key factors affecting productivity: Personnel and processes

So what you ask? Perhaps the biggest IT management oversight in the solar system is the undervaluation of these experienced technicians. An expert has been described as anyone with a briefcase over 50 miles from home. While that may not be the beginning of your story of the worst experience you've had with consultants, we all agree it does not an expert make. Daniel Levitin in his book, This Is Your Brain on Music, gives a more accurate definition of an expert: "Someone who has reached a high degree of accomplishment relative to other people."

Are experts made or born? Levitan says studies have shown that "ten thousand hours of practice is required to achieve the level of mastery associated with being a world-class expert -- in anything. In study after study of composers, basketball players, fiction writers, ice skaters, master criminals, and what have you, this number comes up again and again."

The belief that one can pull together a fine service desk (level 1 and 2) with lightly experienced techs is ludicrous, whether in-house or offshore. Try it and the result will be disgusted users whose expectations are so low they feel, for some strange reason, they are fortunate when they are told their problem is going to be "escalated." The word "escalated" is not synonymous in any dictionary with the word "resolved." Inexperienced technicians, if that is all you have, are a significant personnel problem.

Another very common occurrence in technical support is having too much distance between the person with a problem and the person with the solution. Putting the person with the answer within one phone call of the end user 80% of the time is pricey, but it is less than the cost of separating them. Because that distance, measured in time, equals lost productivity, which equals cost. A gatekeeper between the user and experienced technicians is a significant process problem.

End users know when they need their problem fixed. It is pretty much "now." That's why they're calling. "Now" should be a reasonable expectation the majority of the time. Put end users and real tech support pros in immediate contact and watch customer satisfaction and productivity skyrocket.

On the other hand, providing users a technician to fix their computer problems who can't fix 80% of a caller's issues is claiming to have a genuine asset when, in fact, you don't. And that doesn't take 14 months to figure out.

Kent Blake works to create higher standards of customer support in a technical environment. He is a consultant and can be contacted for golf at kent@blakenow.com. He combines a journalism degree from Ole Miss with 15 years experience in various capacities in technical support and management.

14 comments
kblake44
kblake44

Thank you for the feedback, pro and con. Here are a few thoughts/clarifications: To rfolden: You Amen'd the article 3 times and had the most votes with that one comment. That is good enough for me. Thank you and thanks for kind comments and thoughts from derek, random2010 and rtoni. To ourITlady. An adequately staffed department is assumed. I once worked in a company where we had a dream team in IT but at times we looked like bumbling idiots because we were understaffed. Sounds like that may be your case. Generally, most users I have dealt with are sympathetic to my work load, they know I want to help "now" but rarely give me a hard time if I can't get to them. It's ironic for employees to care more about getting back to work than companies care about providing quality technical support to get them back to work. To spdragoo: Your comment is longer than my blog. Good thoughts on telecom support. I read it twice because I've been through an incredible 1.5 year ordeal with my ISP/Phone/Cable TV provider, Comcast. I had Comcast for years in Connecticut and they were great. I am in the Southeast now and I am convinced they are the worst company in the United States. Twenty service calls to the house or the neighborhood to check the cable signal and three separate trenches to the house from the tap in my back yard. Their very best people can't figure it out. Like someone who weighs 500 lbs, they have totally given up. (phone signal/internet goes dead for 2 plus hours every day at random times.) Uverse is running lines around our town but we are just a little too far from a major switch for them to provide us service. Does anyone know an executive at ATT Uverse who has suction? If they will run the line I will personally get them four customers on my street. Please contact me. My email is kent@blakenow.com. Thanks.

austindayo
austindayo

A comment here is really typical of users, you keep calling a support personnel USELESS anytime you don???t get instant support \miracle solution ( Also you hardly praise them when they even fix issues instantly). Whereas am sure you don???t deliver in your job instantly or per sec every time. Give the IT support personnel a break!!! They are not God???.

OurITLady
OurITLady

but have one major disagreement with one particular comment: '???Now??? should be a reasonable expectation the majority of the time.' - that comment is exactly why I'm considering leaving IT permanently. I work in IT support and every user I deal with has that exact expectation, however no-one considers the fact that the same team has to deal with 1st, 2nd and 3rd line support. Over the years I've had users expecting instant response on a print problem during site outages, knocking on the server room door while the server is down to tell me they forgot their password, and so on. While the ideal is instant response and fix, the reality is that most departments are so overworked it just isn't possible, and the user expectation needs to be set accordingly. Otherwise you are going to burn out and ultimately lose the very people you need to provide the responses detailed above.

rfolden
rfolden

"The belief one can pull together a fine service desk, (level 1 and 2), with lightly experienced techs is ludicrous, whether in-house or offshore. Try it and the result will be disgusted users whose expectations are so low they feel, for some strange reason, they are fortunate when they are told their problem is going to be ???escalated.??? The word ???escalated??? in not synonymous in any dictionary with the word ???resolved.??? Inexperienced technicians, if that is all you have, are a significant personnel problem." 3 times "Amen."

spdragoo
spdragoo

That does sound bad. Although I had co-workers that said Comcast was one of those companies notorious for dragging their heels on getting technicians out...even when there hadn't been, say, storm issues in an area. Which, of course, made it very hard not to laugh out loud when a particularly obnoxious caller would swear up & down that Comcast would have dispatched a truck to them "immediately & for free", even when they were calling in after 8pm on an issue that tended to sound more like user error and/or customer hardware issues. BTW, since I left that particular employer 8 months ago (and actually switched from the tech-support project to the billing support project 4 months before that), I think I'm safe in saying now that my employer's "client" was Verizon -- specifically, their FiOS department.

random2010
random2010

Austindayo: I think you are refring to my long post above. I used the word 'useless' because the service I received from these people was of no use in solving the problem. It seems an apt word! Please note that it took 40+ phone calls and two months of pain to get a useFUL service from the company so I your observation that I expected instant support \miracle solution seems wrong to me. I showed an inordinate amount of patience.

spdragoo
spdragoo

Having worked in a 3rd-party call center that provided Level 1 & 2 tech support for a client, I'll agree that the level of training may not be "ideal" -- coming from an IT background, most of what I learned during the "training" class had more to do with procedures & reporting requirements (i.e. what we could & couldn't support, what tools to use to diagnose the issue as quickly as possible, etc.). However, in my experience, the majority of customers that call in to tech support are *not* experienced users. They've performed few, if any, troubleshooting on their own before calling in. Most of the time, they haven't even performed the very basic steps -- power-cycle router/reboot PC for data, power-cycle STB [Set-Top Box]/reseat cables for TV, reseat phone cord for phone, etc. -- before calling in. And all too often, their technical expertise is the equivalent of "C-A-T spells cat". For these people, having a highly experienced & trained technician spend the 30-40 minutes walking them through basic troubleshooting steps is a waste of time & money for the company, especially when a lower-level tech/agent can do the same thing. Sure, it might involve them reading from a script... but as long as the scripts are well-designed that shouldn't matter. And yes, companies are of course obsessed with the bottom-line, but consider: if a company uses only technicians that can command a $20-30/hour pay, to avoid cutting into the bottom line the company will make up the difference somewhere else: cut-rate installers, cut-rate equipment, or simply raising customer rates. None of those are exactly "optimal" results for the customer, either. Take, for example, an IP address. Given that it will take about the same length of time to perform the procedure, which costs the company (& ultimately the *consumer*) more: having a $25/hour certified technician walk them through "Click on Start; click on Control Panel; click on ...", or a $10/hour tech/agent? Both are going to follow the same "script", both will be able to tell the customer when they ask why, "This will tell us if your computer is talking to our router", & both will be able to tell what step to follow next depending on the result. Perhaps to put it into better perspective, consider dining out. If you want a fancy meal that showcases elegant cuisine with artistic flourishes, specialty meats & vegetables, & depends quite heavily on the presentation of the dish as well as the food on the dish itself, you don't go to McDonald's & have your order prepared by high-school & college students paid minimum wage. On the other hand, if you just want a plain burger & fries with a pop, you don't go to the fancy French bistro with the highly-paid, Paris-trained chef backed up a small army of experienced sous-chefs, & plunk down $50 or more per plate. The average customer calling in to tech support may think they're looking for the fancy French cuisine experience, but they *usually* need the fast-food restaurant experience first...& if it turns out that their needs can't be met at the fast-food level, then they can be redirected towards the casual-dining level, then on up to fine-dining, as needed.

watsonderekj
watsonderekj

We had a recent restructuring and all of the level 1 techs are now located in the India offices. I have never had so many end users come up or call me directly and complain about the length of time it takes these guys to diagnose and resolve something that is not specifically written down in a script.

random2010
random2010

Sorry spdragoo, but I have to agree with the author Kent. I base this on experience, a prime example being when my employer put a DSL line into my home not just so I could telework but so I could pilot the service of the ISP (one of the big ISPs) prior to rolling out company paid DSL lines to the homes of 150 home based workers. All worked fine for a while then it stopped working. It took the ISP 2 months to solve the fault, and I went through the hell of useless first and second line technicians going through all the same scripts over and over with me. I kept a log of 40+ phone calls to tech support, all of which were useless. Twice they told me (as per their scripts) that a home visit was needed by an engineer, but I would have to pay ??60 if they did not find a problem. Both engineers were decent chaps, both could see the problem happening but neither could understand it. Both times I ended up having to call tech support and start all over again with clueless script readers. Eventually I got it solved when one of the 1st line support people took pity on me and called 3rd line support (against the rules) so I could speak with them. The guy was excellent, diagnised it in 2 minutes. The ISP had switched off the DNS servers associated with my account, so all they had to do was change my account settings to use the new DNS servers and all worked fine. It was not the DNS error but the 40+ wasted calls to useless Ist and 2nd line support techs which stopped us from using this ISP for the 150 colleagues. No way would I subject them to this level of service. The DNS problem could and should have been resolved quickly, but the customer service I experienced was unforgivable.

watsonderekj
watsonderekj

I have gotten the experience from trial and error, not reading from a ready made script that was passed down to me. If anyone wants to really learn the troubleshooting issues toss the script and get into the trenches. These level ones have no troubleshooting skills other than what was written down for them. That is their downfall and they will never be as capable of diagnosing an issue as someone who was told to hit the ground running. Being in tech support requires some irregular thought processes sometimes. We all have been on both sides of the phone from time to time. It takes understanding not just a hollow scripted response.

The Great Gazoo
The Great Gazoo

Perhaps my previous comment (or others) are a bit knee-jerk, or percieved as a bit of a wide brush stroke. To be clear, there are some great support people out there. And it's gotta be frustraring from either side of the call. But consider this - Spdragoo states: a) "...if you don't have a record of what was done on the prior calls, your agents are going to end up repeating themselves." b) "...a number of customers will simply lie to technical support" c) "...If the problem isn't with our hardware, you *must* agree to accept the charges that *will* be put on your account". d) "it's not enough to tell the agents "I've already done that". You have to tell them, "This is the problem, I did steps A-D to try to fix it, here's what happened when I tried each step". From my perspective (as the customer) this is what I will experience: a) you weren't listening to me the first time around b) in spite of (a), you probably assume that I'm lying to you the second time around c) as a result (a) and (b), you are threatening me with financial penalties d) in the end, you expect me, the customer, to mitigate your broken process by capturing, then repeating the troubleshooting steps for the benefit and assurance of your support personel. I don't think that was the intent, and I do think (Spradoo) that you're a passionate and honest decent individual trying to balance out your own experiences, from the support agent / centre perspective. There is always a balance. The (huge) gap, IMHO is that the customer you describe is not me. It's not my process that's broken, it's your product or service. I'm not at all a liar, and I am most willing to cooperate and even go beyond to help. But I refuse to be put under pressure of penalty when I've done nothing wrong. And I'm not in any way responsible for fixing your process problems. I'm not sure you realize it, but I am the person that finds all of the above completely unacceptable, and the irony I suppose is that all of those points you made above are the reason I would walk away. It may not be you, or any of your staff specifically. As you say, you might have the best agents on the planet. IMHO this all just smacks of that same old backwards philosphy of "blame the customer". You have support problems and you want me to fix them. I've had enough of that on so many fronts. I've been on the other side of the fence too. I do realize it's not easy for you, and I think your heart is in the right place, but you have to understand that as a good customer, I refuse to be treated like a bad one by default. I appreciate the chance to rant a bit, and I do hope you all consider some of this, fwiw...

spdragoo
spdragoo

As per my response above, part of what makes a good implementation is the tracking. You can have the best agents on the planet manning your phones... but if you don't have a record of what was done on the prior calls, your agents are going to end up repeating themselves. And unfortunately, companies have found that a number of customers will simply lie to technical support because they "trust" a field tech more... even if the tech doesn't have the skill set. Although not the majority (luckily), we had enough customers call in that either refused to perform troubleshooting before a dispatch, or ended up flat-out lying over the phone about peforming certain troubleshooting steps, that a policy was strictly enforced that either certain troubleshooting steps had to be documented -- complete with actual test results -- in a ticket before they would dispatch a technician. They started even changed our script for the customers that were insisting on dispatches, from "You may be charged for the dispatch if the problem isn't with our hardware" to "If the problem isn't with our hardware, you *must* agree to accept the charges that *will* be put on your account". Because of that, it's not enough to tell the agents "I've already done that". You have to tell them, "This is the problem, I did steps A-D to try to fix it, here's what happened when I tried each step". Then the agent can not only look over his 'script', he can look at the appropriate example screenshots & go from there. One thing that can also help, however, is line testing. Our client had a testing system that could send test signals all the way through the network to the end user's equipment -- it could read the wireless security key from the client-branded router, check both for dialtone & for connected phones on the phone lines, & detect if the STBs were hooked up. Obviously, for connectivity issues, being able to connect externally to the customer's equipment helped to determine where to start diagnosing the problem. By the same token, of course, when the agents ask the right questions it helps solve the problem more quickly. I don't know how many customers called in & said, "I can't connect to the Internet", but after prying a few details out of them it turns out the *real* question was "My laptop isn't connecting wirelessly to the router", or "I can't access a particular website I like to visit, but other sites come up just fine". Although the calls we dreaded were "The Internet connection is *sooooo* slow"... which, aside from the difficulty of pinning down one particular issue that could be causing it for them, could also turn out to mean, "It takes the *browswer* so long to open up to my homepage, & all of my other, non-Internet programs are also taking a long time to start up". Or, "I'm trying to access this popular website that has this really important news story my buddy said was just posted, but I haven't tried other websites to see if they're loading up slowly". Would I be frustrated if I had to call into tech support & had to jump through hoops & redo troubleshooting I'd already done? Of course. But then, I'm lucky, in that I have 3 devices to check connectivity on: PC, phone (VoIP, & the VoIP device connects between my cable modem & router), & Netflix on Wii (PC & Wii share the same router). If my phone has no dialtone, the Internet is probably down; if my PC can't connect, but Netflix comes up on the Wii, then the problem's with my PC. Thus, my few calls into tech support have been primarily to confirm outages in my area... & not much I can do about that.

spdragoo
spdragoo

I can understand that kind of frustration as well. My brother-in-law had trouble with the cable Internet to his house. He's not a "techie" by training, but we share an interest in technology & computers, & he's picked up a lot of hands-on experience over the years. The ISP sent a line tech out... who told him the cable line into his router was screwed on too loose. This, of course, was after his initial tech support call, which was *preceded* by him already checking the line to the router. The problem still wasn't fixed, so after the 2nd call, a 2nd tech came out... who then told him the cable line was screwed on too *tight*. Again, didn't fix the issue, so on his 3rd call he started off, "Look, this is the problem, this is what I've already done to troubleshoot it, you've already had 2 techs out here, just send me a new d*** router". Although thrown slightly thrown off their usual script, they were more than happy to send a tech back out -- apparently they had a script for how to handle customers with multiple calls on an issue with multiple dispatches... & this time, the tech that came out not only stepped out of his van holding the new router, but apologized for the previous techs' mistakes. However, what it kind of sounds like to me, though, is that the company in question may have had issues with the way they tracked their tickets. One of the things that they had to start beating into everyone's heads was ticket reporting & tracking -- not only customer's reported issues, but the steps taken to resolve the issue. Part of that was because some of the troubleshooting steps could cause the customer' phone call to drop &/or lose phone service for a few minutes; having a record of the steps taken, though, meant that with the next call the next agent could start from that point, rather than from scratch. We also had to make sure we used proper coding for ticket issues -- for example, a "CCON" [Cannot Connect] was the correct trouble code for a customer that was unable to connect to the Internet at all, but *not* the correct code for a customer that was having trouble setting up their laptop to connect to the router's wireless signal; the first indicated an actual problem existed (whether in the customer's hardware/software or on the ISP's side), but the second was a settings & setup issue (i.e. the wireless signal was there, they just didn't know how to connect to it), & neither one was considered to be the same as a "slow Internet connection" issue. They could also better track customers that would be calling in for repeat issues, & put a "priority" flag on accounts that had repeat calls in a month over the threshold...provided, of course, that the prior tickets were correctly coded (& they added sections to our QA forms that took off points if we didn't code correctly). Another part of our implementation, though, also included in-house chats. Obviously, if your agents are restricted to only using phone calls, then each Level 2 agent can only assist 1 person at a time. But our Level 2s were required to be able to handle 3 or more open chats with Level 1 agents, in addition to being available to take a phone call, the latter being reserved for the "difficult" customers (i.e. refused to troubleshoot, demanded a field tech dispatch even if it wasn't a job for the tech, insisted on speaking to a "supervisor" or "someone higher up", etc.), business-class customers that had called our center by mistake & needed help with more advanced options like setting up their mail server or setting up a static IP address in their router (as our center was geared towards helping customers, who used dynamic IP addresses), or those customers identified as priority because of the number of prior call-ins (as noted above). We also had "floorwalkers" available -- experienced Level 1 agents who primarily went around to the stations identified as being on "long calls" (technically anything over 15min was considered a "long call", but they usually were more concerned about the ones lasting over 20 minutes) to find out why it was taking so long (i.e. walking an elderly person through programming their TV remote) & make suggestions on how to proceed (i.e. contact Level 2 on chat, if you haven't already done so), but would also answer questions from agents as they passed by. I did quite a bit of that during my last few months at that job (could have moved up to Level 2, but my average call time was "too high", & I tended to skip the script about the "automatic email with valuable links to other products & services"). With that methodology, your case would have either been flagged for higher-level assistance due to the business-class nature (assuming your employer opted for business-class DSL service), or because of the call frequency. No guarantee, of course, that it would have been solved in a truly reasonable timeframe, but hopefully a lot sooner than 40+ calls (IIRC, our threshold was 4 calls in a month for the same trouble type).

The Great Gazoo
The Great Gazoo

"Both times I ended up having to call tech support and start all over again with clueless script readers." "If anyone wants to really learn the troubleshooting issues toss the script and get into the trenches." Amen. There is nothing more infuriating during a loss of service, be it IT related or otherwise, than suffering through this mindless repetition. I'm not a rocket scientist, but yes, I checked the power cord. Yes, I checked the power cord. Yes, I checked the power cord. Yes, I checked the power cord. Yes, I checked the power cord. Yes, I checked the power cord. Yes, I checked the power cord. Yes, I checked the power cord. Yes, I checked the power cord. Yes, I checked the power cord. Gladwell's presentation at a recent RSA conference was based on "Blink" and the Kouros story. It's a fascinating account - and he's right. That "gut feeling" that comes from lots of experience will save you and your customer(s) a ton of pain. The front line folks need to be the sort who can toss the scripts and make some judgement calls. Good judgement, according to Gladwell, has (among other things) a "mysterious" quality. The person with the right answer can't even really explain how they came up with it, they just "know" its right, based on their subconscious experiences (their days in the trenches). Put me in touch with one of these folks when I have a problem - and I'm a happy camper who likely won't "bother" you again. Run me around the horn 3 times with a script kiddie, and given the opportunity, I'll write you off and not look back.

Editor's Picks