What “The Chronicles of George” can teach us about technical support

There's bad communication and lots of resentment on BOTH sides of the phone line.

Twelve years ago, while working at my very first real job right out of college, I created a website called The Chronicles of George in order to highlight the grammatically twisted help desk tickets produced by a coworker. I was a much younger and angrier person then, and the idea of putting up a website to ridicule someone else seemed hilarious and appropriate. Besides, it's not like anyone was really going to see the thing, right? It would be a dumb little lark I could share with my friends. That would be that.

More the fool, I. The CoG was noticed by a few USENET groups and within a month, I'd blown through traffic caps on two separate Web hosts. Local morning radio shows started calling. The site ended up as a Screen Savers "Site of the Nite" and a Yahoo Pick, and at its peak of popularity it did about 90,000 pageviews a day. Clearly, George's mangled help desk tickets and his characteristic verb tense—"havening," "receivening," and so on—had struck a collective Internet nerve.

However, the site is more than simply a bunch of screenshots and snarky commentary: there's a lesson to be learned in many of the malformed help desk tickets about the state of technical support. Problems run far deeper than just bad spelling.

A systemic problem

A few weeks ago, Ars asked what you think is wrong with technical support, and boy, did the responses ever roll in. The complaints came from both the folks who call into help desks and from the folks who work on those help desks. Responses were legion, though everyone seemed to be able to agree on an overarching point: whether you're calling for help or providing help, technical support is an awful thing that no one likes. There are shining points of light here and there where an individual has a fabulous, helpful support call. But as a whole, the comments were overwhelmingly negative about both the experience of receiving support and the experience of dispensing it. Whose fault is it, really?

Getting help from jerks

The complaint most often repeated by posters on the customer side involved the near-universal use of "scripts" by help desk techs. These guide the technician down a carefully prepared list of common frontline troubleshooting steps, but they also often enrage customers by forcing them to comply with instructions that often have little or nothing to do with the problem they've called in. ("No, rebooting my computer is not going to fix the toner sense error message flashing on my printer's screen!").

Enlarge/ Customers are often frustrated with being forced to plod through a support script.

Another common complaint was a perceived lack of knowledge and respect on the part of the technicians. There is a hard-to-shake pervasive cultural image of the bored and unskilled phone support person berating a customer for failing to follow ill-described directions. So posters vented no small amount of resentment about often knowing far more than the technician, but still being forced to comply with seemingly capricious basic troubleshooting before being escalated to a more skilled engineering resource (you know, the type with the ability to actually solve problems).

Enlarge/ Unskilled help desk technicians can make bad problems into absolutely nonsensical ones.

This leads to a third complaint: there is generally no way for a skilled customer who has already accomplished a lot of basic troubleshooting to skip the first-tier support people—the "help desk firewall," as one poster cleverly put it. You simply can't directly access the people with the knowledge to address more complex issues. The XKCD Shibboleet strip was mentioned more than once by way of example; such a key phrase would go far to eliminate a tremendous amount of angst-filled wasted time as the seemingly moronic first-level helpdesker plods through seemingly useless troubleshooting steps.

Enlarge/ Skilled users or those who know what they need usually have no way of bypassing the "help desk firewall."

Giving help to idiots

The feelings from the other side of the phone were just as vitriolic. An oft-repeated sentiment was that "all customers are liars." It's a cynical point of view, but much like Dr. Gregory House says, it seems to be true more often than not. The help desk workers overwhelmingly reported torrential abuse at the hands of customers who do anything and everything they possibly can to avoid giving correct information, and who seem to take a perverse pride in their ignorance about how computers function. The goal on the customers' parts is often to get their problem resolved as quickly as possible, without respect for process and sometimes without admitting they've missed basic steps.

Enlarge/ Some customers aren't above fabrication to get what they want.

Beyond that, help desk workers are frustrated to face sometimes frantic and enraged requests for assistance with basic tasks, which tie up time better spent on solving more complex problems. Passwords that were remembered on a Friday are forgotten like clockwork every Monday morning. A laptop won't boot because it isn't fully seated on a docking station. Excel is "broken" because scroll lock is on. When chided for not having even rudimentary computer knowledge in spite of a computer being an integral part of their job, annoyed users often fire back with the tired old saw: "You don't have to know how to fix a car in order to drive one." This is true, but although you don't need to be able to fix the car, you should at least know what the steering wheel does.

The biggest problem reported, though, was that customers simply can't be bothered to provide enough information to correctly diagnose a problem. Techs complained that getting an accurate picture of what might be wrong with a customer's machine is sometimes impossible; a call often starts with a customer saying "My computer's broke," and then responding to requests for more information with an angry "I don't know what's wrong—that's your job! Fix it!" It's hard not to feel frustration when confronted with enraged entitlement.

Enlarge/ The help you receive is only as good as the information you can provide.

Couples counseling

Much like an arguing couple who has been fighting for years, it's difficult for either side to see and acknowledge that the other's points have merit. Stepping back from the heat and looking at the laundry list of complaints, though, it's clear most of the things being complained about are symptoms, not actual causes. There are two things that both sides lack: empathy and trust.

This is easy to see—I should be a doctor! But much like a licensed professional counselor might tell a pair of folks they need to listen to and trust each other more, it's difficult to actually do. Merely being more empathetic and trusting won't automatically fix everything. Unfortunately, there are significant outside factors dogging technical support as well.

Still, it's hard to ignore the basics. The lack of trust by itself is a high hurdle to overcome, and it results in most customers approaching a tech support call with the attitude of "What am I going to have to tell this unhelpful jerk in order to get my problem fixed?" Most corresponding techs answer the phone thinking something like, "What is this idiot liar going to try to pull over on me now?"

Worse, outsourcing—and more specifically off-shoring—is far and away the most damaging thing to happen to the customer/support relationship since its inception. Sadly, even the sagest of technical advice can be rendered useless when filtered through a strong enough accent. I'm as guilty of this as anyone else—when I call a support line and fight my way through the IVR menu only to eventually get a person who is clearly from Mumbai on the line, I feel an immediate sense of despair. My perception, based on a decade of terrible support experiences, is that I need to do everything I can to get past this person and get through to someone who actually can communicate effectively and fix my problem. Like most assumptions, this thinking will make an... well, you know the phrase.

Beyond trust, empathy is another killer. Customers rarely take into account that the seemingly bored and annoyed technician they're dealing with is paid based on the number of calls per hour he closes. Or that the ridiculous script is mandated by his company and deviation from it can skew his metrics, possibly even cost him his job. Conversely, it's difficult for pressured techs to realize the seemingly endless stream of "idiots" they have to assist are real people. The problem they're calling in with, trivial as it might seem to the tech, is of huge importance to the customer.

Lee Hutchinson
Lee is the Senior Technology Editor at Ars and oversees gadget, automotive, IT, and culture content. He also knows stuff about enterprise storage, security, and manned space flight. Lee is based in Houston, TX. Emaillee.hutchinson@arstechnica.com//Twitter@Lee_Ars

159 Reader Comments

The problem is the whole one-stop-shop approach. Customer service should be tiered depending on the level of knowledge of the user and complexity of the problem.

I have no idea how can you implement this idea, but it makes sense to separate high school teachers from college professors. Only then will you be able to feel empathy and trust for the person on the other side of the line.

Helpdesk metrics and tech support offshoring are symptoms of a bigger problem with how corporations are run today. With a short-term focus on quarterly reporting and stock price, leaders inevitably make what they think are cost-saving decisions at the expense of long-term customer relationships, retention, and brand integrity.

When I first joined my former employer the internal Helpdesk did most level-one troubleshooting. When we systems engineers got a ticket escalated to us we knew it was a real problem. And if it wasn't, our relationship with the Helpdesk was such that we could provide constructive feedback ("Hey, the next time soneone calls with this type of problem, just try this or get this piece of information.")

Later they slashed the Helpesk staff and instituted metrics where if a problem couldn't be fixed in five minutes it was automatically escalated to the next level. As a result my team spent a lot more time resolving simple issues, following up with users who didn't call back, and so on. Not only was this a poor use of highly-paid engineers time, but it took time away from infrastructure projects and timelines stretched out. Our relationship with the Helpdesk deteriorated as engineers complained about getting "stupid" tickets.

On paper this may have saved money, but we eventually had to add more systems engineers to keep up. At the same time customer satisfaction with the Helpdesk and IT as a whole dropped dramatically.

There's one huge obstacle to all of this: metrics. Almost every company that offers a help desk, be it for internal or external support, has a method for keeping track of the efficiency and effectiveness of that help desk. This typically involves rating technicians based on the number of calls they handle per hour, or the number of tickets they open per hour, or the ratio of calls per hour to tickets closed per hour, or some other combination of similar statistics designed to quantify work done over time. A prototypical good support experience, with a helpful technician who takes the time to listen and a customer who is willing to work through what might be a long troubleshooting process, is often directly at odds with the types of metrics that help desk managers impose. A great tech who prioritizes customer satisfaction over ticket closure rate won't remain employed for long.

The problem isn't metrics, at least not by themselves.

The problem, as it almost always does, really relates to metrics derived from poor modeling. This is endemic with people who know just enough to be dangerous, but either don't know enough to understand the broader patterns and influences at play or aren't insightful enough to do so without training.

Someone says "our customers want support" followed by "we should offer support, it adds value to our product, no one wants to buy an unsupported product."

Once support is running, someone (else, probably) says "we need to focus on cost cutting measures, we need to be LEAN, how can we apply this to customer support?" "Well the more customers per hour, the better our techs must be doing at solving issues."

The fundamental error here is that customer support, before anything else, is essentially marketing for potential repeat customers, not to mention a form of grass roots PR (even more so with the internet these days and sites with review listings). If you assume that "completed" tickets are your success metric, you've made a flawed judgement.

The true success metric for customer support is more likely to be "Customers who were happier at the end of the call than at the beginning." Nobody who wants things "cut and dried" likes this. It's too "soft." It's qualitative in a way that seems utterly subjective. It sounds like it can't be nailed down with surety and quantitatively the way processing a ticket response script seems to be. But the truth is, it can be, you just need some quality tools to measure customer behavior and feedback and the proper scientific approach to analyzing the situation. You need the appropriate models for what's actually going on rather than just what you ASSUME is going on. You'll need to spend some money and probably even bring in an I/O Psychologist at least as a consultant to form some use case and other studies and to properly analyze the statistics gathered.

But in the end it's the same as paying for quality advertising and the kinds of returns seen with that versus mediocre "hi we used our mom's 1980 camcorder and some sheets" garage advertising. And, granted, some of it can be fairly intuitional, especially if someone sits down and thinks about it for a bit and maybe cracks a few related books. It's still worth hiring someone who's a professional, and in the end is likely to save quite a bit more.

"It's the people, stupid."

In turn it's really just a matter of properly communicating the associated costs and benefits to the people making those decisions.

Heh... I called tech support once to let them know that one of their routers (I knew which one it was and in which city it was located... pretty easy to find out, actually) was on the fritz. It had been doing silly things for about two days until I got tired of it. After getting past the level 1 techs, I told the tech the problem and it was fixed in a couple minutes. The tech was pretty cool about it even though he said it was a little freaky... he said they don't often get calls like that

Sometimes I can't blame companies for attempting to mechanize, automate, or outsource the lower-level troubleshooting. I'm not saying their solutions work most of the time, but from either a business or programming perspective, when the majority of issues begin with having to pry out the same basic facts (beyond "not working"), it's natural to look for ways to stop repeating yourself.

There's some something about computers that prevents many people from thinking of them as machines. Maybe it's just that they're too small and simple looking, but the same person who would describe in detail the sound their car makes when they try to start it and what other things they have tried to make it work, suddenly goes into shock and won't mention the error message on the screen because it worked last time, and now it's not working and we're very busy so please just fix this instead of asking more questions.

Realistically, the burden of change probably falls on the user-facing hardware and software to continue becoming more appliance-like. We can't educate all of the users, and looking for ways to improve a procedure that involves operating a computer remotely through a different person, through a phone, is the very definition of polishing a turd.

The company I used to work for managed to avoid the metrics mistake and the scripts thing in my department. (Which just shows anyone can get _something_ right. )

Our "metric" was based on call resolution, not tickets closed. At the end of the month an audit would be done, and they'd look for repeat problems from a customer; if you had eleventy-gazillion closed tickets, but all of the problems got a second call, _then_ you got raked over the coals. You'd get in considerably less trouble if you had a single ticket each day, but no repeat calls for the issue. Each ticket was looked at individually; if everyone else took 12 calls on a day you took 1, but your call was markedly more difficult or just for whatever (good) reason longer, there was no problem.

We were also encouraged to chat when waiting for something to happen. Instead of an awkward silence while tapes loaded or what have you, we were encouraged to ask about the weather, other problems, sports, etc. It's amazing how much that warms up the conversation. It's also interesting how much it reduced the stress of calls on both sides of the phone to humanize the other guy. Some of our clients would recognize you when they called in, and most didn't treat us as interchangeable drones.

Some of the other departments fell into the metric trap, and while it was managerially easier (they make nice, pretty reports), they also have higher turnover rates and incoming call rates. Oddly, they never liked the idea of seeing how many tickets were actually followups to previous tickets. They were also continually short-handed, despite being larger. (Which is why I'm not sure that it wouldn't be cheaper to do a better job, but one company doesn't make a good sample.)

Only one bone of contention: Where Metrics come from. They don't come from the support company. Even in the 90s, most computer makers outsourced their help desks. They just did it inside the US. Those call metrics? They come from the company doing the outsourcing. They tie the rate of pay to the contractor to those metrics. "If you meet all the metrics we'll pay you 100% of our contracted rate, if you miss be less than 10%, 90% of your rate, " etc. Since these are huge companies (HP, IBM, Dell, etc) dealing with several smaller companies desperate for their business, they can write these contracts knowing the call center can never realistically make the full, contracted rate. Eventually, the contractors catch on and in response, just hire less qualified, cheaper staff. After all, they aren't measured on how many problems are correctly fixed. Just how fast you get to the customer, and staying on an average of 10 minutes. Need basic customer service skills to do that, not technical knowledge.

Majority of the issues in tech support stem from this dichotomy. Techs get bitter because they can quickly see they aren't ALLOWED to help, customers are just frustrated to no end with ineffective support, and computer manufacturers just blame the contracted companies, all while laughing at everyone else involved.

What would help avoid many tech calls would be better operating manuals. One of the things that makes BBedit such an excellent program is that it comes with an excellent user manual. Most of the video tutorials are simplistic. They may be good for novices, but serious users need technical manuals.

Before I buy commercial software, I want to know who good the manual is.

Many people rag on the outsourced techs but I think I prefer them. I've only had native English speakers try to strike up small talk or call me a "hoser" on the phone (seriously). Sure, hire Americans if you like but make sure they don't get distracted from their job.

I don't want to talk to you about the weather or tell you what my job is or where I go to school. You're not my friend. Ugh, small talk during tech calls is the worst.

I remember a skit by a group called something like 3 trolls about help support. Basically a trainee is grouped with the senior tech (I've been here over 3 months!) and they take a call from an old guy, which the tech refers to as a 12 o'clock flasher (he's the type of person that has 12:00 flashing on his VCR because he can't figure out how to set the time on it). They go through several troubleshooting steps which involve acerbic, sarcastic, and terse instructions from the tech, and inane idiocy from the old guy (No, the illegal error doesn't mean that you've done anything illegal. No, you don't have to turn off the computer. No, don't --- Sigh, I'm going to put you on hold for a moment) and excessive hold times as the tech constantly puts the guy on hold to "teach him his place." In the end, the tech gives up, and asks if there is a child in the house, and is put on the phone with his young daughter(?), who is able to understand instinctively how to go through advanced menus and options with little prompting from the tech. The girl fixes the problem in a matter of seconds, and the tech tells her she should get her parents to buy a special computer for themselves (It's a very special computer for old people called a Mac) and take the computer for herself.

It was a very funny skit and epitomizes the sort of experiences I had on the call desk. Honestly, a decade or so ago when I was doing phone tech support, it was a horrible experience. The job, which I had for about 2 years, was soul-draining, and I became increasingly bitter and angry during that time. It was only when I left the job that I realized how badly it affected me. Maybe it has gotten better since this as the computer generation has aged and taken over a much greater percentage of the population, but dealing constantly with people with computer illiterate people was frustrating on a level that I cannot describe, and haven't seen before or after that period in my life.

Honestly, a good help desk person isn't necessarily the most technically advanced, as one of the two editor picked comments points out. A good tech really needs a ton of patience, a good personality/bedside manner that can interact with customers well, and lastly technical skills. The technical skills can be taught, the former two cannot, and are absolutely critical.

Good article. Brought back memories, albeit not particularly good ones.

What would help avoid many tech calls would be better operating manuals. One of the things that makes BBedit such an excellent program is that it comes with an excellent user manual. Most of the video tutorials are simplistic. They may be good for novices, but serious users need technical manuals.

Before I buy commercial software, I want to know how good the manual is.

I just printed this page, highlighted your comment, and taped it to the outside of my cube.

I'm an IT tech writer who spent time in the TS call center ... and I wish every product manager and executive would hear what you're saying.

That said ... RTFM is universally recognized because so few people do.

Second, i think the most profound difference between a modern computer and any mechanical device from previous eras (like those often mentioned cars) is that computers today are "weird machines".

A mechanical device usually has one task, and you can trace out each step of that task by following the power transfer (crank shaft and such) onwards. Computers on the other hand, once we moved past the DOS era, is like a huge stack of mechanical systems (just booting a OS these days result in 10+ programs starting) that are hooked and unhooked from the power source at blistering speed. And often these systems share common resources, resulting in something being left in a unexpected state, and you get a catastrophe.

So comparing a computer to a single car is not really accurate. More appropriate would be to compare it to all traffic in a city block, or even a whole city. That is the level of interaction and complexity that sits in your lap at this time.

Years ago I took a temp job doing internal helpdesk for a major UK bank. They were in the process of outsourcing the operation out to India and at the time I worked there they were pushing 1/3 of the way through the process. It was a job I loathed, but was only ever a short-term thing - I'd just been made redundant and it was either this or the dole - I jumped ship less than six months later when a better prospect came along.

Anyway we saw the whole gamut on both sides - everything from users that you had to wonder how they found their way out of bed in the morning to those that "knew enough to be dangerous". Occasionally you were lucky and got someone reasonable that just wanted their problem (whatever it was) fixing and would work with you to that end. On the other side of the fence we had everything from people that appears to know little more than the users did through to others that were very good but arrogant and pissed off the customers. Some were genuinely skilled at both IT *and* support and others that were horrific at both. On a couple of occasions we actually ended up with ops that would outright lie to customers. Needless to say they didn't last long.

Personally I always felt sorry for the boss of the team - we all got complaints against us for one reason or another and he had to sort through all this crap to work out if the user was to blame or the operator was.

Anyway, we found that the outsourcing project was affecting the productivity of the internal team in two interesting ways:

1) We ended up having to pull a couple of the better reps (both in terms of technical ability *and* CSR skills) off the phones to move to a dedicated "Fallout cleanup" roll - basically taking any jobs that the Outsourced ops had screwed up and both a) sorting it out and b) dealing with the (by now very pissed off) user.

2) We had a couple of Indians on the team in the UK. I'm not sure if they were immigrants or had been born here (nor is it of any great relevance) but both of them had fairly strong Indian accents (although both were eloquent and easily understandable). Anyway, once the guys out in India were picking up (and flubbing) a significant number of calls it wasn't uncommon for folk to ring the helldesk, and then, if they heard an Indian accent on the other end, hang up and try again until they got someone that sounded English. The ridiculous thing is both these chaps were both very good at the job - one of them in fact was probably the best of all of us on the team.

Either way it was a horrible job - while the boss did his best to make us feel valued, very few other people within the company did and I was deeply glad my time there was so short.

Great article, and it mentions some of the conversations I've had with my mom who is a customer support rep for a large insurance company.

The same solutions apply to all types of support whether tech, insurance, vehicle, or whatever. Patience from both parties, as well as getting the most accurate information about the issue can alleviate much of the disconnect the consumers and support personnel have.

If more companies that offer support were to lessen the impact of their metrics I believe that all support personnel and the customers they serve would have a much better experience. One example that comes to mind is that my mom has to go through a script before getting any information, and must follow it exactly or she gets points taken from her score. her calls must also be resolved within a certain short time period, I thin it's 3 minutes. And yet many of the calls she takes take upwards of 5-10 minutes just to find the right materials she needs to fix the issue the customer was calling about.

Yeah, I know CSB.

The point stands though, focus on customer support, and let the metrics be damned.

On my help desk job we got trained by senior staff. Luckily, I signed on at a point before the call center realized it was screwed by bigger sharks. The senior staff really knew their stuff. One trainer told us not to think of it as using our customer service skills, but rather our diplomatic skills. This job was as much a game of diplomacy as it was tech support. Somehow, this crystallized it more for me than the watered down business speak of customer support skills.

Just wondering... In the late 80s in high school there were at least 2 or 3 mandatory computer classes wherein we were taught what RAM is, what a CPU does, what an OS does, even light (BASIC) programming, etc... Is this true today? Kids are savvy, sure, but do they know how to fix things? Everything's better than it was in the 80s of course but those lessons and problem solving go a long way.

Given two equally-suited technical options, I'll purchase a Lenovo over an HP because I know that when I call Lenovo I'll get someone in Atlanta that will absolutely NOT force me through a BS script when I say, "this keyboard is mechanically defective".

So much that. Working in IT, and thus having the "opportunity" to interact with technical support from many different tech firms, has made me a Lenovo fan for life.

I read this article and ended up having to look into a call log at work. Here's what it reads:

When checking her e-mail it would go to a blue screen and then she would get a message about choose between to programs that she was using to bring her back to where she was.

1. Would like prority service2. Made a noise like a fan berring disconnected the computer and restarted the computer and it went away.3. When checking her e-mail it would go to a blue screen and then she would get a message about choose between to programs that she was using to bring her back to where she was. . 4. They had it in six months ago for virus removal

I just want to say thanks for this article. Having worked at a number of help desks and technical call centers in my younger days, this article is pretty much spot on.

In training for my first big tech support job for a major computer manufacturer, I sat with a top tech (according to metrics) who showed me "the secret" -- look for any excuse to get the caller off the phone as quickly as possible in order to meet the metrics; whether that meant transferring to another dept or convincing the caller to run some BS time-consuming step and call back in if that didn't work.

I was disgusted by this behavior and refused to play along, resulting in one initial layoff and constant consultations with my manager throughout my time served.

I was never the best at call times and the only thing that saved my ass time and time again was FCR (First Call Resolution) and frequent letters to my management from callers that expressed gratitude in my ability to help them. I also had to often point out the quality (and length) of my notes in the help tickets, which I was ace at, compared to the vast majority of my peers.

My first time through, I was burned out severely and vowed never to pursue that line of work again. My second time through, I was lucky enough to work for a company that actually gave a damn about their employees (and customers) and had good management that would fight for their team as long as the techs could show the quality and competence necessary for the job. Metrics were still involved but took a backseat to the customer satisfaction element.

The difference between the two companies were night and day.

This article should be essential reading for anyone in charge of a help desk or tech support call center.

I think you explained very well what is wrong with this obsession with metrics. My brother worked on tech support as well for a year, and his experience seems to mirror yours. He cared a lot about doing a good job and helping people. He wrote long notes in help tickets. But as with you his metrics were not that good. He often got called in to the manager because she has listened in an noticed that he sometimes skipped the script. Times where anybody with any technical understanding would understand that the script did not make sense.

My brother started hating his job eventually. He was putting in a lot of effort but the managers were just assholes back. A couple of weeks before he quit he thought "I don't care about this job anymore". So he started being very sloppy and careless about everything. He never made much of an effort to solve peoples problems or to write detailed notes about problems. To his amazement his managers got thrilled by his new great "performance". He was doing really well according to all the metrics. By not giving a shit he had become a model worker according to the metrics.

Later they outsourced it all to India. They had better metrics, too bad the customers thought the help they got was shittier than ever.

But really is this unique to tech support? I have felt a lot of the same things as a developer. People who churn out lots of crappy and buggy code get nice metrics:

1. They deliver new features really fast.2. They fix a lot of bugs fast. (Why because there are lots of easy to fix bugs in they sloppy bug ridden code).

If on the other hand you write solid bug free software, your metrics look bad.

1. Features are delivered later.2. Since you produced fewer bugs, you have to fix bugs in other peoples code, which is always much slower than doing it in your own.

Sure the developers who come after you and have to maintain your code saves lots of time by working with solid code. Except managers seldom see that. They just see how long time it took to deliver the initial feature.

On a course about statistics analysis (Tableu software) the trainer told us stories about some call centre workers repeatedly and deliberately cutting callers off after 5-10 seconds because it helped their metrics.

Average call time went down, number of calls answered in an hour went up, call centre worker and his boss both looked good on the stats pages.

Of course this was all linked in with how his "wonderful software" would help managers spot trends like this, but when the numbers can be screwed so easily (and at the expense of your customers) it highlights how poor these metrics are as an overall method.

Interesting article and insightful in terms of both user and help desk perspective. Some fairly naïve conclusions are drawn at the end however.

Tossing out metrics and all that “MBA” conventional wisdom is a wild over-reaction. Consider the scale of service operations. A small operation with a couple dozen techs ‘maybe’ could pull that off. Without even rudimentary metrics however they would find themselves in hot water trying to terminate any under performing employees. A major consumer focused manufacturer will have literally thousands of support agents, in dozens of facilities across multiple geographies. Better to argue which metrics are important and which are not, but to throw them all away is a non-starter and a sure fire way to guarantee an absolutely horrible customer experience as there will be no control of the operation.

Also, to make the blanket statement not to outsource or offshore is one dimensional thinking without considering the other side of that decision. Support costs can nearly triple between some geos. The consumer obviously has to pay as support costs embedded in the product. Better to argue how best to maintain economical and effective support process using all available resources, domestic and otherwise.

Finally, we all hate scripts but keep in mind their intended purpose. These are used by the lowest level techs at first contact with an unknown customer/issue. If you call for support on your new coffee maker, you may roll your eyes when the tech asks you if its plugged in to a powered outlet. But consider, about 5% of the time that IS the problem! Sounds crazy but true – and any good operation will measure and recalibrate their scripts for effectiveness (metrics!!) to pick these low hanging fruit.

The article makes some excellent points. But if you want to move the situation forward in terms of better service experiences you cannot simply ignore the other sides to the equation - the things that drove these behaviors in the first place. You have to find a solution to both.

Good read. I am blessed to work for a good boss whose only concerns are making sure the customers are taken care of and making sure we do our jobs. We don't have to worry about metrics, we don't use scripts, and there is a camaraderie here that I've never seen at any support job that I've had before. People help each other out with difficult issues and get along fairly well. A few coworkers marked their 5th year at the company a few days ago, and I can see myself being here at least that long.

I myself used to do support and the Metrics were murder. I've since moved on but we were given bonuses that were directly tied to our metrics. It was ridiculous. To make it worse the company removed annual raises and substituted the bonuses.

The worst two metrics were your Team utilization and Average Handle time. If the team did not meet the utilization ( everyone is busy working and taking calls ) you got dinged and lost about $25 of your bonus.

If you did not meet your Average handle time of 15 minutes ( give or a take a minute ) DING another $25 gone. Suddenly that 150 bonus is now 100. Miss a third metric like say, attendance or quality score? ( yes we were graded on how we performed on the calls following scripts etc ) you lost even more dropping it down to say 75.

To make matters worse, when it was slow if you suddenly got an hour long call and you had handled a handful of other calls that day, then your Average handled time was pretty much screwed.

We also had software that tracked everything we did. When you would login, when you would logout, when you would go on breaks etc. If you were a minute over your allotted break time the manager would come to you and let you know and if you did it to frequently there was the very real chance of being written up. We lost more great technicians to break issues then anything else which is sad.

It's a work environment that does not reward those who do well, but only those who can cut corners and get the job done as quickly as possible. This usually resulted in angry customers calling back many times. The only way you could really hope to succeed was if the customer would fill out the survey that was sent to them after the call praising how well you were as an agent. But that would more then likely bite you in the form of your handle time because you spent so much time working with them to get it resolved.

And let's not forget you were given a specific amount of time to wrap up your calls and notes. If you went over then someone probably came to speak to you about why you were taking more then 2 minutes to wrap up the notes for that hour long call you were just on. *sigh*

On the plus side getting laid off from that job because the client I was on pulled out was probably the best thing that happened to me.

I just don't understand how companies can expect to have good customer service and support experiences when you put such restrictions on agents. It makes them hate their jobs, and want to try and get the customer off of the phone as quickly as possible. After being in support I myself hate calling any support line and avoid it. If I have to, you better believe I'm as nice as I can be to the person on the other end having been in their shoes once.

This comic sums up the entire support experience in the best way possible.

To add to my other post, at one point I did have to switch jobs in the company and did QA for a bit. I still say the funniest thing that happened to me was when I had to QA a call from an Indian guy in America calling the outsourced call center in Bangalore and they could not understand each other.

The company I work actually makes the CRM software that many support organizations use. We do not use scripts and the metrics we use are limited. We are also paid a salary, so volume is not a factor. Much of what we do is a multi-session affair. Things usually aren't solved on the first call or email.

That being said, the communication aspect is paramount. Customer and techs with good communication skills go a lot farther and are much more satisfied. We have special programs for our larger companies where we assign a dedicated tech to simply summarize and go through all of a customer's issues one or twice a week. Then we can expedite as necessary based on feedback from the customer. This has a huge impact on our customers' satisfaction levels because even if they have a flurry of problems we need to work through, they know what is going on and that progress is actually being made. Of course this means a lot more time spent on our part just to have these meetings, but it is worth it in the end.

That being said those with poor communication are quite the train wreck. We have some techs and customers who are completely worthless in both technical and social aspects. I hear them on the phone sometimes, and cringe. Then when I have to mop up the eventual mess, it is extremely frustrating, which unfortunately gets passed on to the customer occasionally. Of course this is not unique to Support, but there are lots of places where inept people are left to do jobs beyond their abilities, but we all manage to scrape by regardless.

I worked all four years doing phone and in person tech support at my university. We were the end of the line for students, but could escalate faculty tickets or campus wide issues to the actual university IT staff.

I really enjoyed my job, and went above and beyond what was required a. lot. because I liked where I worked and who I worked for and with.

There are a couple factors to this: one, we were treated as skilled workers by both the rest of the IT staff and by our manager. Second, we were given a lot of latitude in how to solve a problem. We didn't have quotas, nor a script. (We did have recommended steps in our training, but they were suggestions, not required.) What we didn't have was a budget; any tool we used was free or open source. (This was mostly things like virus scanning, etc, but also included our wiki and training documents.) Consequently, we didn't do serious hardware problems, although faculty hardware issues were referred up the chain. (Also our manager was concerned about liability issues after the first couple times we pulled out the soldering irons to fix damaged flashdrives.)

The absolute worst customers were the ones who assumed they knew more than us. The most egregious offenders were the computer science professors on campus. They would lay out all the steps they had done to trouble shoot, assume they had covered everything, and would get very rude if you asked for more information. Generally, they had done all of the troubleshooting you needed-- except for some of the troubleshooting for interactions between different parts of the system. Because they didn't know the weird shit that happened when the print server was down but the wireless was fine, etc.

Also, my two cents about chat support-- while screen sharing can be very useful, I generally have found chat support (from both sides) to be less helpful than email or on the phone. It's not necessarily that customers lie on purpose-- but customers lie, either because memory is fickle, or because they honestly don't know or recognize the import of what they saw. And chat is short and informal; you end up having to do a lot more wheedling to get information out of people. It's also more awkward than phone because you don't get the same kind of social cues, and people who don't use chat services regularly (i.e., most of the less computer savvy faculty we got calls from) don't pick up on the social cues you do use in all text.

There's something really wrong with me - I've worked corporate, ISP support, VOIP support, and . . . I rather like it. Everything but the payscale is fun. Your brain works, you're always learning, and generally someones day is better after they talked to you than before.

I don't think I've had ten callers in eight years that were problematic, of which only 2-3 actually annoyed me enough that I can dredge details out if I work at it.

The pay sucks - I'm overpaid for my position compared to many, and I have no idea how some people make it. It's frustrating to know there are techs out there that make six figure salaries and I'm never going to do that in this field.

I wish I still had the email addresses to my old employers. I would send them this link and beg them to have administration read it.

I've had one tech support job that was (relatively) lenient with the workers and let them actually get the work done right. No surveys, no scripts, no time limits.

All the rest were outsourced to specialized phone support companies. At least it provided jobs here in the USA, but the constricting rules hampered our ability to do our work. This has become a plague on the tech industry. Everyone expects tech support to be horrible because we can't get out of this assembly-line support system.

Sometimes the problem is that the technical support personnel have their hands tied by ridiculous (even dehumanizing) policies. Put another way: "Initiative considered harmful"

Ten years ago, I was working in a call center providing tech support for direct broadcast satellite (DBS) customers and installers. During each call, we were required to go through a script and not deviate from it. Calls were monitored, and occasionally we would be pulled off the phone by a supervisor to listen to our recorded calls and be graded on whether the call "does meet" or "does not meet" quality standards.

One day I got a call from an installer who was on a rooftop trying to install a new dish. He was mystified by the fact that despite getting a transponder signal on the dish, there was no video coming from the receiver. I started going through the script with him, and he immediately interrupted me. "Look," he said, "this is the third time I've called, and the last two support people took me through the same rigmarole. Can you tell me anything that I haven't already heard?"

I thought for a moment, then said, "As of last week, there is a new satellite up there broadcasting HD channels. It's possible you're pointed at the wrong satellite, and the fact that you're receiving a transponder signal is throwing you off." I stayed on the line while he did some adjusting. He finally came back and said, "That was the problem. We have a picture now. Thanks so much for the help!" And that was that.

Or so I thought. A week later, I was pulled aside by a supervisor. That call had been randomly recorded and reviewed. I was told that even though I had helped the customer solve his problem, I had deviated from the script, and therefore my call handling did not meet their quality criteria. Two more strikes that month and I'd be out.

I didn't give them the chance. I quit almost immediately afterward, and haven't worked in customer service since. But now, whenever I have frustrating conversations with customer service personnel, I try to remember that, as likely as not, the employee hasn't been given the power to actually solve the problem.

Your statement that metrics don't matter is a bit simplistic. The right metrics can make all the difference, but using canned metrics from other companies or the old standby of "industry standards" can harm your service desk output.

Here's one I mistake I see being made all the time: First Call Resolution rate should be close to 100%. It's something new managers or stakeholders make. In truth, FCR should be about 60%. Too high leads to rapid tech burn out; too low means customer satisfaction drops. But the right number depends on a lot of factors: how complicated are the calls you expect to get, how many phone staffers you plan to have, how quickly can your level 2 or 3 support get involved, and how accessible are your level 2 or 3 support to your phone staffers.

In more complicated environments, you probably want an FCR around 45-50% if all else remains even. If your level 2 or 3 support collaborate with level 1 instead of just being handed escalated tickets, your FCR should be around 80%.

Other old hat metrics like avg talk time, calls taken, or abandoned calls all need to be analyzed as how they pertain to your specific environment. So I wouldn't say metrics don't matter. You can use metrics to enforce the behavior you want from your phone support staff, but each one of those metrics is a variable in the grand equation of customer satisfaction.

No news is not always good news...sometimes no news means someone else is doing support on the side. Shadow IT is an interesting topic as it related to support staff. Most organizations try to stamp it out, but the truly wide managers see it as a potential solution to solving problems quickly. Organizations embracing shadow IT for some common issues quickly empowers end users to find their own solution and can bring down the costs of support while driving up the value of your phone staff.

As a current Help Desk Manager, I wanted to point out that this is a good post. I have to add though, that the article seems to imply that customer satisfaction isn't a metric. I'd argue that if you ask the correct questions, it can become one that is easily measured.

Don't outsource. Don't do it. It doesn't work, customers hate it, and it hurts your business's brand and its bottom line. Well-treated internal employees being paid a living wage and given decent benefits will represent your brand and your products with a passion totally absent from outsourced, offshored clock-punching contractors; dumping your support organization overseas demonstrates the utter lack value your company has for its customer interactions. A company with offshored support is clearly saying, "We want to spend the least amount of money possible to shut up problem customers and make them go away." And go away they will—they'll leave and instead buy products from your competitors who have adequately staffed lines answered by humans working in Nebraska.

This statement is so wrong headed it's not even funny. The classic view of farmed out, off-shored support with little look beyond costs is DEFINITELY wrong. We have spent the last year and a half bringing up an outsourced support department (actually, we do a LOT more than just support), and, while the initial problems exist, our first several tiers are all almost outsourced, and most of the time our customers have trouble telling. As I LIVE here as an ex-pat, and am directly responsible for their performance, I can assure that poor off-shored customer support is a failing of management.

Even with me moving down here, and the time it took to get them REALLY up and running, our off-shored support is WAY cheaper, and generating VERY good support. Moving your support off-shore doesn't affect it's quality. If you have bad support off-shored, you will likely have bad support in the US, as it usually stems from a poor vision of what support is. The statement that bad support is from commoditizing support is quite true though.

This article is all too true. However, there ARE steps that one can take to improve the customer experience. When I ran tech support, we did several things to keep the first- and second-level techs happy and effective:

o Techs should do telephone support for a limited lime only. Think of it as joining the Army. If you made a mistake, you know exactly when your enlistment is up. 6 months to a year is the optimal range.

o All techs should have at least one day a week to work offline. Not only does this give them a break, it keeps their skills fresh. After all, how can you keep taking money out of the bank if you never put any back in?

o Script are tools to help the tech, not to abuse their intelligence. As such, write the script to assist the tech to remember complex troubleshooting procedures, aid escalations, and guide the customer. If the tool doesn't fit, don't use it!

o Create separate technical and management escalation paths. The latter is for when a customer feels they haven't been treated right, or a contracted obligation hasn't been fulfilled (e.g.SLA).

o Metrics should be used, but as a diagnostic tool, not as a brain dead way to evaluate employees. We refined our metrics to show which products or services caused the most problems. Incenting tech to close tickets at all costs produces the results so well described in this article, and also loses valuable data that otherwise could lead to process or product improvement.

o Do measure customer satisfaction. There are many ways this can be done, but the key to success is to improve this metric over time. Nothing else matters!

Although tech support is a highly visible example of our poor customer service culture, it is hardly alone. Ever tried arguing with an airline representative over your inability to actually use the frequent flyer miles? Tom Peters used to make a point about the tire dealer who repeatedly failed to deliver, then made the excuse that "well, we're no worse than anyone else." Do you really want to buy a product where tech support is "no worse than anyone else"?

As a current Help Desk Manager, I wanted to point out that this is a good post. I have to add though, that the article seems to imply that customer satisfaction isn't a metric. I'd argue that if you ask the correct questions, it can become one that is easily measured.

I've yet to see anywhere that asks the right questions, be it an internal or external support desk. Typically, customer sat is measured by a short 1-5 or 1-10 scale survey where customers are bullied/cajoled into giving all 5s or all 10s, and anything other than all 5s or all 10s gets the agent fired.