I have been living online full time since 1992 orTech Support Online! so and on and off many years before that using the old interactive text menu version of CompuServe.

I have provided online end user support for Toshiba and ClubIE and ClubWin.

I have done a lot of Tech Tutoring.

I provide volunteer support for my students, family, friends, and strangers and here are the truths I have learned when it comes to providing Technical Support in an Online setting.

These truths were learned in many places over many years.

They are not specific to any personality or company and I am speaking to the Tech Support person and not the end user:

  • Be Nice: People are going to be rude because they are upset they are having technical problems. Don’t take it personally. It doesn’t help them if you are rude back to them. It is your role to accept those blows of anger because your job is, as my friend Steve Schone at Micro Solutions used to say, “To be a pillow.”
  • Answer the First Time: Provide some sort of answer if you answer a question. Don’t answer a call for help with questions. Provide a frame of a solution first to assuage the fear and the anxiety of the user. Then prod for more information using additional questions if you must. If you are a tech support volunteer and you do not know the answer, DON’T ANSWER! There’s nothing more annoying than to hit an online support forum and find a slew of responses from people trying to help that solves nothing and provides no insight except to build up the ego of the one pretending to provide an answer when none is really offered.
  • Live Boilerplate is Better than Dead FAQs: Boilerplate, by definition, has steps and solutions embedded in its contents. Good boilerplate that you can modify in situ to provide more specific help is preferable over the awful “Read the FAQ” mantra that has replaced the “RTFM” curse of a few years ago.
  • Forget FAQs: FAQs are for support people, not for newbies or people desperately searching for information. To answer a question by pointing someone to a FAQ may save you time, but it does not help the end user to a successful resolution because many FAQs are unclear and poorly written and non-universal. A FAQ may make Tech Support feel better, but the end user is forced into self-help mode, and that experience is usually doomed to frustrate even more. Pointing someone to a FAQ is like standing in the street and someone asks you a question about a former president — and even though you know the answer — you point to the library across the street and say, “The answer you seek is right there in that building. Look under ‘politics’ in aisle three.” It takes just as much effort on your end to give them the answer.
  • Don’t Use Discussion Threads: DO NOT point people to pre-existing online threads to find an esoteric answer. There’s nothing more annoying than having to peel through a 52 message thread to try and divine a single answer to a simple problem. If you know the answer is in that conversation, PROVIDE THE ANSWER! Pointing someone to a conversation instead of an answer is like if someone asks you for Mary’s phone number and — while you know the answer — you instead hand them your address book and say, “She’s in there somewhere.”
  • Accept People Don’t Know: One way to push away the end user while looking like you are really helping them is the old chestnut of forcing a long laundry list of technical questions on them before you will begin to help. Making them answer questions about machine type and OS and RAM and everything else that you don’t have direct access to anyway only pushes them away in the false hope that they will actually go away so you won’t have to really help them. That kind of “support” is sneaky and disingenuous and rather cruel. Take what information people give you and work from there. Don’t make them fill out a long form first.
  • No Live Chat: I’ve never seen Live Chat that is helpful in a tech support situation. Live Chat merely provides cover and the buying of time because inevitably the “Live Chat” person has to push your problem up the chain to an engineer who actually knows something. Live Chat is the human version of the “Fill Out My Laundry List First” method of keeping the end user waiting and at bay for an answer.
  • 2 Hour Turnaround: Years ago, if we provided answers within 24 hours, end users were happy. That world no longer exists. Users now expect not only a response, but a solution to their problem, within 2 hours. Honor that need as you realize time and space are compressing every single day.
  • Train Volunteers: If you plan to use an all-volunteer support system where end user supports end user, you must train those volunteers. Be Warned: People who have all day to sit around and answer tech support questions for free are not ordinary people. They crave attention and seek power they do not have in their real lives and so they seek that authority virtually and they use that authority-by-false-proxy on your users. Do not allow those people to answer every single question without answering anything. Cut them off! Anyone can point to discussion threads and paste FAQ URLs all day long — but few can just answer a simple question with a simple solution. If you don’t reign in the false helpers they will, in the end, always turn on the paid staff by using guilt and insolence to curry favor and to bully adoration: “I do and do and do for you kids and this is how you repay me?”
  • Provide a Path to Private Paid Support: Some end users don’t want unknowledgeable end users not answering their vital questions. For those users who have the means and the need, provide a private path to expert support that you can charge them for in the end on your end. That makes you money. It makes those users happy because they are guaranteed to have an expert answer without wading through the chaff of ego that volunteer end user support creates.

That’s it for now! What do you want to add to the list? What truths have you learned in either providing online tech support or in receiving it as a frustrated user?

35 Comments

  1. Hi David,
    I wish all tech support was run the way you’ve suggested.
    I’ve been trained by experience to not expect much from tech support anywhere.
    When I was in college, tech support was non-existent. Or, at least it seemed that way. I think there was an office someplace that handled things, but I wasn’t sure how to contact it to get questions. This was in the pre WWW days using the VAX system, so I’m sure tech support is easier with the internet set up the way it is now.
    I did buy PC-Write with an educational license from the computer people for a low price, so I didn’t come away empty handed.
    When I was in graduate school and the graphical internet of today was just taking off, it was more experimentation since nobody really knew how to do anything at that time. Most of my answers were found via contacts in the internal newsgroups and word-of-mouth from other users.
    School tech support involved experimenting and trying things until someone cuts off your account. 🙂
    My first website in 1994 was on a machine in the engineering department. A friend of a guy who had sublet my apartment one summer set up an account for me. It was deleted not too long afterward because I wasn’t a student in that department. My next website was created on Geocities a couple of years later.
    The lack of tech support taught me to use the scientific method to resolve any technical issues. Do some research using available sources and experiment. Keep track of what you do so and test any hypothesis by repeating the experiment several times.
    When I used AOL, I don’t think there was any tech support beyond some forums that were run by volunteers. I don’t think there was any good way to ever get in touch with AOL to get anything done. I couldn’t even get them to disconnect us from the service for quite some time without having to call many times, cut off the credit card, and threaten to turn them into the state attorney general.

  2. What a great history, Chris!
    Tech support is difficult. It takes real, live, smart people and you have to pay them a lot for their technical chops and their ability to cope with a wide array of angry personalities.
    Tech support gets into trouble when volunteers are used in place of paid staff. Proprietary fiefdoms are created, pecking orders are enforced, and indignation rules. It gets uncomfortable and ugly fast and I was big into doing a lot of volunteer support on CompuServe, MSFT and other companies so I’ve seen these dangers from inside the Cool Kids Club, ClubWin, ClubIE and lots of other scammy schemes where free labor support a for-profit entity.
    When you exchange payment for tech support services, however, the dyad becomes one of proper negotiation and getting along. There are no hard feelings at stake. No one can pretend to be doing you a “favor” by answering your questions or by demanding a “thank you” in return for their volunteer effort on your behalf.

  3. Hi Nicola!
    I do that sort of thing for companies.
    The hardest thing for companies to accept is the angry, upset, rude customer is always going to come at them with that negative energy. I tell them if their customers were happy and friendly they wouldn’t need your Tech Support. The trick is to find the easy charm in the predictability of their venom — then they can’t sting you.
    It does drive me crazy when I see or experience Tech Support poorly performed. It makes me feel cranky and rude.
    😉

  4. Hi Chris!
    “Be a pillow” is an excellent mantra when you know you’re dealing with upset and angry people. If you know they’re out for blood then it doesn’t hurt so much when they hit you.
    😀
    The best thing to do first is to repeat back in your own words what their problem is as you best understand it and then offer a solution. That lets them know they’ve been heard and understood – actually say the words, “I understand you.” — and it takes all the power out of their future punches. Here are some other phrases that work well:
    “I am on your side.”
    “We’ll fix this together.”
    “I’ll be in touch soon.”
    “This isn’t your fault.”
    People want to feel understood when they don’t understand what their problem is or what got broken.

  5. Even when you are in an adversarial role, you can let people know that you aren’t on their side, but you can understand where they’re coming from, then suggest working toward resolve the issues.

  6. Why is it that most Tech Support people are like Nick Burns, Your Company’s Computer Guy?

    He has minimal patience for the problematic computer users he has to help, and usually mocks and berates them.
    He would start troubleshooting a problem by rattling off instructions to the character at the computer in confusing technical jargon, and quickly gets fed up by their relative technical ineptitude, eventually yelling his catchphrase, “MOVE!” He then sits at the keyboard and fixes the problem himself, gloating at the relative ease of the solution (“Was that so hard?”).

  7. Heh! That’s right, Chris! Some are not cut to do Tech Support! It is a specific niche. You have to like people on some level to do it effectively.
    One school where I was teaching had a guy who had the job of providing tech support to students. He was a student too, and he often wore a black tee-shirt with “RTFM” emblazoned on it in bold, white lettering. No one knew what it meant — though, I did — but he HATED helping “the idiots.”
    The powers that be recognized his inability to “work and play with others” and he was put on faculty support instead where he could really let loose his wrath!
    😀

  8. To a tech impaired like me, the ‘FM’ makes things even more goofy…no matter what I do with it!
    The bottom line is – ‘service industry’ is not for everybody, it needs patience with a capital P.
    I think those wearing RTDM captioned t shirts need another catch line there – HSFP ! 😀

  9. When I worked as a consultant at the Rutgers Computer lab one of the first things they told us was this:
    This may be the thirtieth person today to ask you for help with printing something the right way, but to them this is the first time it is happening. You have to treat each question as if it’s the first time you’re getting it and not with an “Not another one of those questions” attitude because that’s not going to help anyone in the end.

  10. From experiencing working on both email support, telephone support and many support forums, I am pleased to see this thread! Very well thought out and interesting! You may be generalizing on the odd comment, but in life, we have to generalize knowing there are exceptions to every rule! Excellent post that I have bookmarked to remind me of some of these points!
    Trent

  11. Hiya sulz!
    Welcome to Urban Semiotic and I have enjoyed reading your work in the WordPress support forum!
    Helping can be a difficult thing. I try not to answer a question unless I directly know the answer and can directly provide the solution.
    To reply to a request for help with a URL or a FAQ entry that may — or may not — provide a solution isn’t really providing proper end user support because it just makes for long and noisy comment threads.
    If you can copy a URL — then why not just copy the answer at that URL and provide that solution as your reply instead?
    I also think it’s important for those providing “official help” to be able to solve your problem. When those volunteer help icons can only rename threads and manage messages and refer others to the Feedback area when it isn’t closed — the whole “peer support” process quickly devolves into a sad effort in tedium.
    If you’re going to do support right you need lots of active, qualified, people with proper backend access to get in and fix what’s broken 24/7.

  12. Hey sulz!
    Thanks for that link! I didn’t know about that thread! I try to stay out of non-support areas because I know I’ll get sucked into chatting all day! I have little resistance to having fun online!
    😀
    Thanks again for the heads up and the support!

  13. Why Urban Semiotic Moved from WordPress to Movable Type

    (UPDATE 4/18/08:  We are now using Movable Type Open Source 4.1 on Media Temple.  Here is the story why.)Hello, and welcome to Urban Semiotic!  This blog is now running — racing, really — on Movable Type 4.1 hosted by pair…