Inevitably, being a technical support contact, you are going to have to speak to a client, whether it's being the first point of contact and they have called you to report a problem, to get more information about a particular problem, or to let them know an issue has been resolved. Unfortunately, in my experience, most technicians do this the absolute wrong way.
What's the wrong way, you ask? Well let me explain. For the purposes of this article, I will define a "user" as someone who has between 0 and 10 hours of total training of a particular product. Whether this means that they went to a night course on how to use Microsoft Word more effectively, or they looked at the sticker on their phone that tells them how to get their voicemail is irrelevant; they are not power users by any stretch of the imagination, just someone who knows enough to get by. Also, for our purposes the words "client" and "user" can be used interchangeably.
Problem Description: User calls the helpdesk and says "I can't save my document to my network folder."
What I almost always hear the technician ask is something along the lines of "Ok, and what server and share is giving the error?" There are so many things wrong with that sentence, I don't even know where to begin.
1. As much as it may pain you to do so, empathize with your client, but don't sympathize. Start out replying by saying something like 'I understand how that can be frustrating, now let's see what we can do to fix it.' Letting the user know that you relate to the problem will let them know that you have formed some sort of personal attachment to their issue. Also, most users will realize that the problem isn't your specific fault, so emphasizing that you're willing to help them fix it actually lets them know that you are taking personal responsibility for the problem and will invest all of your resources into fixing it. The reason I use 'we' is to set the customer expectation that they will be involved and that you need their help. This is something I think is critical in setting customer expectations and allowing them to feel involved in the process. (Setting customer expectations is something we will discuss more in depth in a later article.)
2. 'What server and share...' assumes that the user first of all knows what a "share" is, and secondly what server this 'share'-thing is on. Never assume that your user has any technical knowledge beyond what they've just explained to you in whatever technical or non- terms. Ask more user-friendly questions like 'Where are you trying to save to?' This will allow the user to respond in whatever level language they feel comfortable in. Also by listening to their response, you should be able to make a good guess as to their technical competency and tailor your next questions accordingly. The initial call is an excellent time to learn client lingo and educate the client on proper terms. While educating a client on proper terminology is something that we will focus more on at a later date, it is very important at this stage to note that the use of the exact words used by the client should be noted to determine where the issue lies. This is often how the user and technician get confused.
3. She didn't say anything about an error, so don't assume one is showing up. Feel free to ask 'Is there an error message on your screen?' but don't assume that there is one just because something isn't working. Maybe she had a mapped network drive that is no longer showing up under My Computer in a Save As dialog box. That would satisfy the criteria of not being able to save to her network folder, but not having an error, would it not? You must play detective for the users and realize that more often then not they have left out information inadvertantly, as they're really not sure what to be looking for in the first place. Ask more probing questions like 'What is the title of the window that you're currently looking at?' or 'Can you describe what buttons you have available to you?' More often than not, even something as simple as knowing that there is a certain button available on the window she's looking at will help you immensely in narrowing down what the user is looking at.
Now, that's three major problems in a 10 word response; that's pretty bad, if you ask me. Never mind that 2 out of the 3 issues could be resolved by not assuming anything. Being a proficient help desk technician requires more than just being able to solve a technical problem, but also to be able to tailor your responses to the client so that they feel comfortable doing what you're asking (e.g. converting 'geekspeak' to 'normalspeak').
I can tell you that 99 times out of 100, if you are able to communicate on the same level as your client (whether that means dumbing things down to the point of using Winnie the Pooh characters or whether you're communicating back in forth in binary), you will be able to get them to listen to you, as well as get them to do what you're asking, with little resistance. You have to remember that computers, while not necessarily a new thing in the workplace, are still mysterious machines that at the click of a button can make incredibly huge calculations and at the same time play the latest song from Britney Spears. The more comfortable they feel around them, the less worried they'll be about potentially breaking something.
Next week, I'll continue this article by going more in depth about how to explain technical issues and terms to users who might not "get it".
My name is Justin Smith, and I've been in some sort of technical support role for the past 8 years. I've done my share of phone work either conducting surveys, and in various technical support positions both first, second and third level. Currently, I'm a senior help desk analyst/help desk supervisor for a small company in Calgary, Alberta, Canada, where we support approximately 50 or 60 different small businesses with an average user base of 15-20 per client. I run a website called the "The Help Desk How To: Techniques for Technicians" at http://helpdeskhowto.blogspot.com.