Discussion on:

10 things help desk techs can do to improve service

Items #3 and #4 are especially irritating. Add the fact you are probably talking with someone who does not understand US idiomatic English, the call is already doomed to failure. There is no excuse for a caller to have to repeat the problem two, three, four, or whatever number of times before someone knowledgeable gets involved and attempts a fix.

You can't do it the way that you want to do it.You have to say stuff like "You probably have some bad code here" and "Your modem might have a problem" or "Did you try a reboot?".

Implement a live chat client when possible. It can lead to significantly improved speed and accuracy in handling tickets, and there are simple ways to log all that has been said for future reference, as well as for producing frequently given instructions at the push of a button. And the customer can have an email transcript of the whole thing, so they can print it out and have the instructions at hand during their part of the investigation/fix.
No more waiting for emails, and no more "what was that last thing, again?".

Yes, please! Chat should always be an option, but sadly is not.

but I have experienced HEAVILY scripted chat sessions that were excruciatingly slow and painful. A script is a script whether it's spoken or typed, so I see no inherent advantage with chat other than the ability to easily verify alphanumeric error codes, license keys, and the like.

In my experience, the best tech support sessions have included the use of shared control remote access.

They're crappy, you see.

I don't know if remote access is always necessary, and a lot of people are antsy about it, but for some things, sure, it's probably the best. It has most of the benefits of a real live tech coming over, without the drawback of having to try and fit two people in front of the computer

I've had experience with 'live chat' through a major telecom company and believe me it caused more trouble than it solved. The problem is that you get conflicting information from the phone support techs and the live chat techs. You'd think that they'd have the same information available to them but in my experience they tend to have different information between the two which can cause extreme frustration.
It got so bad that the phone help desker told me that I shouldn't believe anything the live chat help desker told me, and to top it all off the technician who came to my home told me that neither the phone help desker or the live chat help desker knew what they were talking about. You know you're in for a rough time when no one bothers to ask the most basic question that all help desk staff should ask "What operating system are you using?" So while live chat support seems like a very good idea in theory it still relies upon the personnel manning the service.

If the live chat techs who don't know anything, that's not due to using live chat - using live chat probably didn't turn them into idiots.

The 10 points are a given and anyone not observing them should find alternate forms of employment. Too many computer people only want the meaty exciting stuff and forget why they are there in the first place.

As a general rule we instigate remote support session whenever there is a need to 'see what the customer sees' which helps us and also takes away that frustration of trying to explain in a meaningful way what is going on.

Its great for our customers but equally helps us. Its all about making the experience as painless as possible.

at times shows a complete lack of knowledge on the part of the responder. Especially when you have to drive an hour and a half each way to go to a remote place to follow the same script you have already done countless times.

The best tech support I have had on a complex problem with a Vodafone Suresignal (effectively a personal mobile phone access point in my home office where there is otherwise no signal) turned out to be a guy in Egypt. And the worst - time after time - is BT. (The bank is even worse in that whenever I discover security loopholes in their online banking they simply do not want to know and I have been forced to report them to the regulator in order to get them to take action).

The suggestion of "Sir, I understand that you may have already tried this, but our policy requires me to try it anyway" is insulting to the customer. If the technician knows the script that well, s/he can say something like "we may be able to get there quicker if I can just ask you a few questions to confirm what you found" and pick out some checkpoints along the way. A smart technician will have worked out what to ask to short circuit the script and ask it in such a way that the customer feels they are being treated with some consideration. This way the customer feels like they are being treated as an individual even if the technician is still largely following the script. We all like to be treated as individuals.

I pay more for my services because I prefer to deal with companies that have knowledgeable technical support than those who are "script monkeys".

AND - when I have to deal with tech support that actually treats me well and is flexible, I try to compliment them and if there is the opportunity for feedback, I give positive feedback. After all, if a supplier is doing a good support job, they need to be told so they keep doing it and don't outsource it to the cheapest script reader.

"The suggestion of "Sir, I understand that you may have already tried this, but our policy requires me to try it anyway" is insulting to the customer. If the technician knows the script that well, s/he can say something like "we may be able to get there quicker if I can just ask you a few questions to confirm what you found" and pick out some checkpoints along the way."

Sometimes you can do this, but too often, taking detours or even reasonable shortcuts can get you fired... I know, I was really close to losing my job on a help desk (basically, if another group in the same company didn't want me, I was going to be let go) because on *one call* I went around the script to get to the end... oh, and if I followed the script, I'd blow the SLA on a priority 1 item, but my shortcut let us beat SLA. So even though I saved them thousands in penalties, I was on the chopping block!

So yes, while the customer made hate it, my approach is the safe one for the technician. They shouldn't be in this position in my opinion, but since so many of them are, customers just need to roll with it and put up with it, I'm not going to demand that someone lose their job over helping me with my issue.

J.Ja

"customers just need to roll with it and put up with it"
No, customers need to complain loudly - but not to the tech who has no choice. Complain where it has a chance to do some good. Whenever possible, give your business to companies who don't expect customers and technicians to suffer through "the script."

All too prevalent in our culture. Unfortunately, be it government or medium to large businesses, it's SOP.

I'll say this about the customers in general though....they want great customer service...but they don't want to pay for it. So...to an extent....they sort of do it to themselves. If they want your undivided attention, to be treated like kings, and not be on a "script" they need to recognize they're going to have to pay more for that service. At the end of the day, most would rather not.

When you see someone demanding gold star support on a product they paid $50 for, but they want free support, you need to shake your head. How do you think the maker will stay in business like that? A low end PC has a margin of something like $8 or $15 per PC, one support call wipes that out... at the same time, vendors have got to realize that if you are going to sell something with razor thin margins, it needs to be good enough (reliability, usability, etc.) that people really don't call in about it.

J.Ja

sometimes we all are guilty my favorite is the keystone cops
remote office calls we are down. tech notifies network and they start troubleshooting
a four way conversation starts up with the clients in the middle. A simple hand off
is most appropriate........

Speak understandable English! And if you can't speak understandable English, then provide me with the option for Chat support which takes out the accent.

The real issue with this nation is that from day 1, people are led to believe that support is the first and only thing that can fix any problem. On top of being frustrated and permanently challenged by technology, north-Americans can't take a step to the side to try and understand where the root of a given problem is. IT and similar tech support employees do not think users are stupid, they are aggravated by the fact that in 2011, it's time for 95% of the workforce to know what the right button does. That if an email comes back, try to send a test from another account and spellcheck the address. No, instead, they drop everything and dial the support number.

#1: Calling a helpdesk now, any time I get what sounds like a speech or rehearsed line when they answer the phone is my first indication the person is going to follow a script all the way. After doing helpdesk for a few years, I found personalizing my answering routine helped thing a bit. Just so it wasn't the exact same every time. Probably made it less boring for me since the caller doesn't know what is supposed to be said.

#2: I can counter your point about following a procedure from the number of times when the customer has said "I've already done X" and they really haven't. Either becuase they insist it isn't required, or they did it wrong. Better to check and make sure if it can be done quickly so you don't lose a lot of time spinning your wheels.

Only to find out (after a long a painfull process) that they were pushing the power button on their monitor, not the pc. I love that one

That one is a classic. I have gotten to the point where I am very specific when I ask a user how they rebooted.

Most of the things you suggest are great ideas, but several of them will never work, because the business priority is always on answering more calls. A technician should always read any past notes that are available, but he doesn't have time to talk to the last technician the user talked to, and most likely that technician is also on a call. The tech is being pressured by management to take another call.

I spent ten years at Dell, and lip-service was always paid to true customer service, but calls per hour was always the primary metric when it came time for review. Dell's customer service dropped through the floor, primarily because of this focus.

So, while your suggestions are good, they cannot truly be implemented by most techs, because they are being pressured to get on to the next call. Resolve rates (how many of your callers do not call back within a set timeframe) is measured, but is never giving a higher importance than calls per hour.

Most of the points are valid, and are what people want. However, when calls go through and even if the notes are detailed on the first call, the next level may not get access to them because they might be at a "call center" cross country or continent. Try calling these support places when you know exactly what the issue is, and yet despite the top level of contract support, you cannot simply state the symptoms and ask for a heat sink, you MUST go through 20 to 40 minutes of script, or if the symptoms show that a Motherboard is dying and key parts are failing, yet its script time again. Thus far, only DELL have been the most amenable to reasonable cause and effect calls, especially where all I want is a replacement power supply after a new unit has either died or is rebooting. Calling some places for technical support is only good when you get someone with what I call "nous" , basically a+ b = c ( or the equivalent), just the understanding that if I call in, and I have seen this issue anywhere from 15 to 100 times, then I expect some credit for the experience, but don't bet on it. The "Doing More with Less" philosophy is a virus that supervisors with defined "metrics" at call centers expect techs to follow; of course it does help that the right info is recorded, which I understand, since if I don't get the info from the service desk, I don't know if the issue is a two click password issue, or a failed graphic card, e-sata card, or drive access, even when they( person calling in ) have the error available, if help desk does not tell me, then I don't know. But I know from my end of things that even if I do report in detail I have no guarantee that my detailed report to the service desk/help desk, is going to get to the level 3 tech, when I have a Xeon Workstation T7500 that has boot issues, PXE, AHCI errors, or event logs that indicate something fairly specific.
I don't know what the answer is overall, all I know is that I try and help staff I support as much as I can, and keep them informed. Seems to work in my main area, since that area has the least local problems, but network problems still happen thanks to budget cutting "cost saving" measures.

In this day and age end users need to do more to not burden IT will silly requests. Its slow, is the network down, forgot my password, etc... are a huge waste of IT time and should be a thing of the past. The computer/network are tools to do work. Not toys.

With that being said, helpdesks and scripts are the TOOLS of satan. Save a few dollars and have annoyed clients/users. Helpdesk staff with Bad english, limited tecnical skills, and forcing people to sit on hold forever while listening to cheesy music can't be a good thing or keep your clients ($$$) happy.

Pay the extra coin and get proper support, so you don't end up fiddling with someone overseas in a call center.

Read the ticket notes. You go there. They have a folder and an electronic file. They don't remember diddly about your history. Every individual between the front door and the doctor will ask the same thing usually while holding your folder and/or looking at your on-lne record. If they were asking for updates, that would be one thing, but they ask the same thing that the last person holding the folder or adding info to the on-line file asked. And let's face it; the doctor's front office is the ultimate help desk.

Talk about, "This is Peggy"!

Speaking English and Listening to the Customer are my two biggest problems with Support. I once called Support and told them up-front, that I had a Windows driver problem. They made me go through useless steps and waste over two hours. One tech couldn't figure it out and just hung up. When I called back, I had to start at the beginning all over again. I hung up after being constantly put on hold. The 3rd time I called, when they answered I told them, 'I have a Windows driver problem and I'm not going to go through all of this again. He listened and had me fixed up in minutes. The trouble is - it took over 2 hours on a problem that could have been fixed in minutes had they 1) been educated on the item they were giving support on and 2) listened to what the customer was saying. The real problem lies in the fact that most Tech Support is contracted out and they know nothing about the product. They read from a script and use the ' If this -then this' method of trouble-shooting. Like the guy that hung-up on me, he ran out of script and my problem wasn't fixed, so he passed it on to someone else by making me call back. I know that profits are low on a lot of electronic items - but when you pay $1000+ on something, we, the consumer, want educated help when a problem arises.

I was on first line support for three years. We were tech support and advisory support for an investment bank. Thus in addition to tech support, we also had to provide financial advice. We had to write tickets, not so much for tracking purposes but to give metrics for requesting and maintaining our head counts. We also did "follow the sun" where we took a hand off from one region, did our shift and handed off to another region. Since we were high salary, because we also gave financial advice, we don't get paid overtime. So, when it was time to hand over support, I would stay with the client until it was solved, but hand over the rest of the systems. We also did chat that others could see and if a call back was necessary, we had a system generated call back alert when the time was getting near. We also had "hotlines" where our highest profile customers had an open line to us. When we handed over, if the problem still persisted and if I couldn't take care of this, the next region had already listened in on their end (we had an hour overlap), so no repeat questions and nothing "tried again." When call back or answer back was required, even across shifts, the alert moved along with the hand over, even it is a call to say nothing has changed.

Then our desk created a 24/7 call center to take first line tech support (in Singapore - multiple languages and dialects because the tech support people are from all over the world but lived or were relocated to Singapore, so if the customer needed to have "Cockney Rhyming Slang" you got someone who could do it ) and we only had to provide financial support where we sort of became second line support, and if the tech people needed us, they could get us systematically (via computer) and we could listen in and join the chat or phone call. Thus, the escalation was done without the customer knowing. If the customer knows, and wanted to speak with us, we could immediately join in or take over. I went to Singapore to train the people on the tech side and the saying was always, "imagine you are on the other side of the call" and "our clients are our lifeblood." A new employee never really got trained, but the supervisors would keep a close eye on someone until they could be seen to provide courteous and prompt responses, if they weren't after sometime and some coaching, they would be moved to another job. The formula had worked for years even as far back as before 9/11, so when 9/11 occurred, every center was on-line 24/7 since we had to reroute some clients communication lines. We are all in the loop with the clients, anytime required. We had some really dedicated people and outstanding upper management. We never once lost a customer and when new clients are searching, they check with competitors and others before coming on board. We had KYC (know your customer) before it became a way of doing financial business. The sales people listed what languages and accents were needed along with the other pertinent customers' business requirements. By the time the first support call comes through, we feel like long time partners.

We got many awards for excellent support. But the company has to be willing to spend money to recruit and retain quality people and you need systems that support the support people "tools". All systems were required to have hooks to support systems, unless the developers and designeres were going to do the support. Mostly they never want to do that, so they made systems that were easy to diagnose and had ways to fix problems without calling the developers/designers. The end point is that you need a company culture that requires outstanding support people and training where necessary and newcomers see how the experienced operate and they either join in or move on.

We know that you are reading your apology from a script and it is annoying to receive "I are sorry for your inconvenience..." after every line! Stop the insincere and condescending apologies and let's get to fixing the problem already.

When i do a stint on Phone support it really exasperates me when a caller commences with m"Can you connect to PC12-019"-while this is succinct, there is no effort to say 'Hi' or enagage on a human level. Conversely, i dislike cold-functional types when I cal for assistance elsewhere, those inflexible robotic types who could not smile if you paid them a thousand dollars.

How about a little standardization in the world. Most times if you call in 4 times, you will be told 4 different things. I've been in IT for about 20 years. I'm happy to start seeing some helpdesk certifications to standardize internal procedures much better. Two of the best I've seen are Globalbenchmark Inc (www.globalbench.com) and HDI (thinkhdi.com). I'm told globalbench is better especially if you're on your own budget. PLEASE STANDARDIZE MORE!!!!

by far my worst experience was having to escalate an ftp issue to corporate IT. We were transmitting a huge amount of data to a corporate ftp server when it just died on us. I called the provided number only to find myself with... you got it, a guy from India who could barely speak English. I quickly exposed the problem along with the usual trouble shooting tips : Check that the server still has space to write files... check that my user/password as not expired/been disabled... please check that the user id still has write privileges. if all else fails, just re-start the darn thing. you know... the usual.

long story short, I spent close to five hours being asked the same stupid questions (that is, script based questions) over and over again because when their script failed to found the problem, they would escalate to another guy who would do the same stuff. In the end, one of them geniuses suggested to re-start the server! the very thing I was asking them to do from the start over and over again to no avail. The problem was fixed like magic and they were all so happy about it. Never in my IT career I had been so aggravated. No wonder so many people really feel a hot passionate hate for us IT guys.

The moral of the story is.. point # 11: Listen carefully to your customer. Actually pay close attention to what your customer is saying. Not all of them are raging fools.

Peace!

Worst part is the help desk support tells you that they are sorry, having network problems and cannot resolve the issue and I that i just need to wait for the network to be okay..

I hate hearing the phrase, that is this department's job and that is that department's job. Some people are too quick to push things off onto someone else before they realize they are the ones responsible to resolving an issue.