Tuesday, October 16, 2012

Customer Service, Part 2: Asking For Help

We (IT professionals) don't know everything.  There is just too much to know. The typical IT person is the "jack of many trades, master of none".  There are specialists out there though that are masters.  These are typically the people that have one job to do and one thing to take care of.  For example, the Microsoft Exchange Administrator.  You probably wouldn't want them working on the SQL database, but if there's a corrupt mailbox on the Exchange store, that's the person to talk to.  The point is, there are ways to go about asking for help, and points when you should and shouldn't ask for help.  This all sounds obvious, but a lot of us forget, get rusty, or just plain lazy with this skill...myself included.

When I first started as a graduate assistant at RIT (Rochester Institute of Technology), I spent every minute of my shift bouncing between students answering questions that they should have known from class or 5 minutes of reading.  One day I was venting to one of the professors I was close to and they said "You're doing it wrong.  You're letting them get the easy answers out of you and not teaching them anything in the process.  Tell them to list three things they've tried to solve their problem, and then give them a fourth".  That changed my tenure as a graduate assistant.  When I started doing that, students started asking me more intelligent questions, and the lazy students interested in just passing instead of actually learning just went away.  Everyone should do this.  If you can't figure something out, don't quit right away.  Don't call support right away.  Open a book.  Open a web browser.  Google is your friend!  Then after you've spent some time researching on your own and trying different things, THEN call out for help.  You'll be much better off, and learn more in the process.

The first step in the support chain is "Who ya gonna call?!".  (If you just yelled "GHOSTBUSTERS" in your head, that's ok.  I did too)  Many of us have a list on our desk of support numbers for various companies we deal with.  This may seem obvious, but don't call someone when you know there's a slim chance they can/will help.  For example, you probably shouldn't call Dell for help with the APC UPS that you're trying to make work with your Dell server.  You should call APC.  Even though Dell may be more pleasant to deal with, they're not really going to be able to help you as effectively as calling APC themselves.  If you foresee yourself saying "I know, but I was hoping you could help anyway", don't make the call to those people.

The next thing I personally experience all the time is after people have spent some time searching for an answer themselves, they give up and call (me) for help.  I'm usually willing to give them help, but they are not in any circumstance to receive my help.  By this I mean they are calling from their car on the way to their kid's soccer game, or don't have the misbehaving computer in front of them, or not even logged into the system they are having the problem with.  This is bad for all parties involved.  DON'T DO THIS!  When you ask someone for help, be ready to act INSTANTLY.  If you ask your question, and the person providing support right away starts telling you what the solution is, you should be doing what they tell you to do right then and there. Nothing is more annoying then when someone asks me a question, I tell them the fix, and I get "hold on, let me go to a computer".  You wouldn't want someone doing this to you if they asked for help, so you shouldn't do it to someone else.

Now that we've covered when to ask for help, we need to cover how to ask intelligent questions.  There's a fantastic article at http://www.catb.org/esr/faqs/smart-questions.html that covers this issue in great detail, but it's targeted mainly for mailing lists and other forms of electronic communications.  I strongly urge you to read it.  Before picking up the phone or writing an email, you should think about your question.  Make sure it's clear and concise, and try not to leave out any details.  You don't want to turn the support chain (phone calls, emails, etc) into a long process that resembles the support tech pulling teeth from your mouth.  You're obviously not going to have all the details support may want right away, but present all of the data you have.  For example, if calling for support for an Internet connection problem, tell them right away if you've done anything even remotely related to the Internet connection.  For example, if you've replaced your router in the last two days and suddenly your Internet connection is dead, that'd be a good thing to mention.  Hiding information is much more frustrating to the person providing support then having to deal with someone who simply doesn't know.  It's possible to guide someone that doesn't know the answer to find the answer to the question.  But it's really hard to get someone to "un-hide" information.

And on that note...don't lie.  Ever.  We all do it.  I do it.  But we shouldn't.  There are two types of lies.  The first is the most common: the lie of omission:
  • Customer: "My Internet connection is down."
  • ISP Support: "OK.  How long has it been down for?"
  • C: "About 5 hours I think.  That's what everyone is telling me."
  • S: "OK.  Is the modem powered on?"
  • C: "Yes.  And lights are blinking"
  • ...~10 minutes later
  • S: "Everything looks good.  We can talk to the modem.  We even see a link on the Ethernet side."
  • C: "Well, I did replace my Linksys router late last night.  I got it from a friend of mine that said it would work without any problems.  My computer also says something about No Network Access in the clock area there on the bottom of the screen"
That last "confession" would have made this call a lot shorter, and a lot less frustrating for all involved.  The "lie" was not presenting all the information up front.

Next we have the basic "lie": saying the pen is red when it's really blue.  We've all done this.  For example, calling Dell tech support for a mouse that doesn't work and they say "Have you tried formatting and re-installed Windows?".  We all just say "Yes" to get past it because it's a stupid suggestion for that problem.  But the more common lie is much more subtle then that:
  • C: "The Internet is down"
  • S: "No one can get anywhere on the Internet?"
  • C: "Correct"
  • ...support tries a few things from their side to test the connection...about 5 minutes later...
  • S: "We can see your modem, and there's even traffic on it.  Can you please try going to www.google.com in your web browser?"
  • C: "Well that works, it's Google!  That always works!  I can't get to www.somerandomwebsite.com/myplace/thispage.html.  It says Page Cannot Be Found."
Did you spot the lie?  If the customer said upfront that THEY THEMSELVES cannot get on the Internet vs. everyone, that's an entirely different problem solving tree for the support person.  Try not to embellish, exaggerate, or make up data.  Doing so can cause both parties to suffer needlessly down a useless path.  If it helps, think of a support call as a trial in a courtroom, where you are on the witness stand as a witness to a murder and the lawyer is the support person.  The lawyer is trying to piece together what happened.  Leaving facts out and/or distorting the facts is no help (and could get you thrown in jail...or at least in the case of support...kicked to a different representative and have to start all over).

And along the similar lines, accept what support tells you.  They will not knowingly give you a wrong answer.  Remember, you called them for help.  If support suggests you try something, there's a reason.  That thing may not work, but it's a data point.  And even a failed test is a valid data point.

So you've asked all the right questions, you've gotten the right answers, and your problem is solved.  Issue closed.  Moving on, right?  Wrong!  Take a few minutes and WRITE DOWN WHAT HAPPENED.  And this should go without saying, but write it in a language you understand.  The support person may have pointed you at the heisenberg compensator and told you what value to set the expansion rate to...but you probably don't know what any of that means.  You should write down what was said to you exactly so you can learn, but also write down things like "Click on start.  Go to run.  Type in 'StarTrekAdjuster.exe"...whatever it will take you to be able to reproduce it on your own.  I'm sure you don't like it when people ask you how to do the same thing 10 times...

Lastly, and most importantly, always be polite and calm.  Very few problems are solved by getting angry (unless you're a boxer).  Even fewer problems are solved by rushing.  Even race car drivers can't rush or else they risk running out of fuel faster.  If you approach a problem calmly and with a clear head, the problem will get solved faster.  You wouldn't want someone yelling at you for help, so treat the person helping you the same way.

If all of this seems like it was a waste of your time to read, I'm glad!  That means you already ask perfect support questions at always the right time.  You're the best customer anyone can ask for.  However...I highly doubt that.  We all have broken at least one of these guidelines before.  Sorry...just playing the odds on that one.  So the next time you need help with something, just TRY to remember some of these tips.  If just one person starts doing one of the things I mentioned here, I'm a happy guy and I'll toast to you next time I have a shot of Glen Ord after hanging up the phone from another person that didn't really want my help.


  1. A couple things to expand on your points of support/customer communication (which are all really good):

    1)I find a lot of customers (especially in the field I support of accounting), think that if there is 1 problem then there is 1 solution. The customer doesn't realize a lot of times that each problem may be caused for X amount of reasons. They assume that since you're some graduate of some tech school, that you have all the answers for each problem that occurs. Sometimes we might know what the reason is right away, other times we have to do some trial and error testing, like you said, getting "data points" that will ultimately lead you to the fix. So it can be frustrating at times when the user says "That's not how you fixed the problem for this other person" and I have to explain that there was a different cause for the problem.

    2)I find IT Support to be a lot like doctors doing medical support. If you walk into a doctor's office and say "I have a head ache", he's going to ask you some questions and maybe run some tests to find out why your head is hurting. Obviously, a head ache could be caused by any number of things (banged your head into something, hangover, tumor...). Same with computer problems. There are any number of reasons a computer might not turn on anymore (dead PSU, bad memory/hard drive, it's not plugged in...) A lot of times, it's the answers to those questions that can lead to the answer and as Dr. House will tell you, everybody lies. When someone calls up and says "My program isn't working", and you go through your general line of questioning, it's like you said, if they gave all the details to begin with, the problem might be solved a lot quicker with a lot less stress involved. If customers treated coming to IT Support like they would going to a doctor's office and being open with everything that might have led to them having a "head ache", we could fix the "head ache" a lot quicker.

    Now only if we could get paid like doctors...

    1. Two very good points.

      The flip side of being paid like doctors is then people would expect more out of us..don't know that I'm down with that. :-p


IT Accountability: Avoiding Murphy

Amongst technology experts, Murphy is someone we all try to avoid.  Murphy's Law states "Anything that can go wrong, will".  E...