Asking The Right Questions

Providing technical support isn't easy. You have to know your systems and policies for computer usage, how everything works for troubleshooting when things don't work the way they should, and how to assist your users. Helping a user in person is relatively easy. You can show them what to do, explain things a little better and it's usually faster too. However, not every environment has that luxury. A lot of Help Desk techs and people with other IT titles assist users via phone or email. This makes things a bit more tricky, especially phone support. With email, you can prepare each message, verifying that it's carefully crafted and has all of the information you need to provide (plus, if you're smart, you've got templates or hotkeys setup for canned responses). On the phone, you have to think a bit more on your feet and hope your people skills are up to snuff.

Below, I examine some general questions and run through a scenario where asking the right questions can make a phone call a piece of cake or a total disaster.

Your Toolbox is Sacred

Think of questions as tools in your toolbox. When a user calls you, they know they have a problem; That's a given. They usually don't know quite how to explain it in technical terms though. Hopefully, they'll give you too much information and you can pick out the important parts. I always encourage my users to provide as much information as possible about any issues they're experiencing. I'd rather sift through 2 paragraphs to find the 2 sentences that actually matter rather than having to play 20 50 questions. But what questions do you ask? That's a good question! (See? You're already off to a great start?)
  • "What happens when you try to (insert whatever they're trying to do and can't)?"
  • "How long have you been experiencing this issue?" or "When did this start happening?"
  • "Is this on a website or a program installed on your computer?" (an excellent question when you have no idea what the user is talking about).
  • "Are you getting any error messages? If so, what do they say?"
  • "So, if I'm understanding this correctly, you're trying to (whatever they're trying to do) but you're getting (error message)" or "but when you do (whatever is happening) happens, correct?"
These are just general questions you can ask. These questions will lead to other questions specific to a certain system, policy, or application. I can't make a list of every possible question because every environment or policy might have it's own specific questions. You use questions about the problems to drill down to what's actually causing the issue.

Real-World Scenario: The Login

Let's look at a standard situation of trying to help a user logging into their computer.

You: "Thank you for calling IT Help, my name is Andrew. How can I help you?"
User: "Hi. Yeah. I'm trying to get in but it won't let me?"

Now, this statement from the user is pretty vague. Trying to get in? Into what? The building? Their car? What is "it" and why won't it let the user in?) Let's find out more information about the problem since right now, we don't fully understand the issue.

You: :"'It' being your computer?"
User: "Yeah, my computer."

Alright, so now we know the user is trying to login to the computer. At this point, the computer may not have a network connection, the password/username might be wrong, it could not be associated with the domain, or the user could be misleading us. Which is it?

You: "Ok. When you try logging in, what happens?"
User: "It says the username or password isn't correct and I know I'm typing the right password."

For now, we know it's a general login issue, as opposed to a domain issue, networking issue, or something else.

You: "I know this might sound like a dumb question have you made sure that the caps-lock key isn't on?"
User: "Yeah, I already checked that."
You: "What is the username you're using to login?"
User: "Bill8794@yahoo.com"
You: "That might be the issue right there. Your username is actually BillJ. Try that with your normal password."

See? You shouldn't ever assume the user is dumb but you should account for human error and know that there's always the possibility that the user is withholding information, doesn't know the information or just gave you info that was downright wrong.

User: "I tried that and it's still saying it's wrong."

Puzzled, right? All you need is the right username and password to login. This is a good time to verify whether you trust the information that the user has given. Often times, a user will say what they think an error message means rather than reading the error message verbatim. You can usually tell this from how they said it. Error messages aren't written in a casual manner.

You: "Can you read me the exact error message you're receiving?"
User: "Yeah, it says 'The user name or password you entered isn't correct. Try entering it again.'"

Based on your years of Support experience, you know that this is not a Windows login screen error message. We're back to getting more information.

You: "Are you trying to login to the computer as a whole or are you trying to login to something else like Sharepoint or Outlook?"
User: "Outlook. I'm able to get into my computer fine."

Since the username you told them to use is their Windows username, you'll need to make sure they're using their work email address to login to Outlook.

You: "I see. I was under the impression you were trying to login to the computer, not Outlook. For your username, you'll want to use your work email address which is BillJ@work.com."
User: "Alright, that did it. Thanks. Bye."

Most users won't want to stay and chat. They called for help and now that their problem is solved, they're quick to get to whatever it is they were trying to do before they called you. I like to think they're just really into their work. We didn't get into IT for the thank-you letters and baked goods for all our hard work.

Next time you help someone with a login issue, you're likely going to remember to ask what they're logging into. It's an important question and you can't really afford to assume anything. Every issue is going to be different. Take it slow, think about your responses and make sure to ask questions. In order to solve a problem, you have to understand it first. Once you understand the problem, you investigate. This could mean assisting the user, or it could mean trying to reproduce the issue. We'll leave that alone for now as it's another blog post in it self.

Different Type of Users

Phone support gets easier with practice. Listen to the user carefully and learn their needs. Some users don't mind calling IT for something but other users might dread it entirely and will be upset and frustrated before they call you. If they're upset, it's because of the situation, not you, no matter how they act. Show empathy, explain that you're going to help them, etc.

If You Don't Know, That's OK

Occasionally, (or often, if you're new), you might not know the answer to a question or know how to solve a problem. If you don't know, or can't help right then, that's OK. Apologize for any inconvenience, and explain that you're going to look further into this issue and will contact the user back when you either know more or have a solution.

You can also always put a user on hold so you can ask a co-worker or your supervisor how to handle the issue. I usually say something like "I'm certainly sorry to learn you're having trouble. Let me put you on hold really quick while I verify some more information." Saying you're going to "verify some more information" sounds pretty vague when you really think about it but most people don't notice. It's a stall tactic in a sense but it's a better segway to hold-music than "Ummmmmmmmmmmmmmmmm.... hmmmm, hang on."

Try to keep your "holds" to a maximum of 2 per call. On the 3rd hold, the user starts to lose faith that you can actually help them, which could cause frustration if they weren't already upset. By the 4th hold, they know as well as you do that you don't know what you're doing. Trust me; I've been on the user-end of the Tech Support calls and when I'm put on hold 5 times for what I know is a simple issue, I start to wonder which of that organizations managers hired their youngest son for Tech Support because he built his own gaming computer. Huge difference between an PC nerd and an IT Professional but that's another topic entirely. Get on that phone and start getting some minutes under your belt. 

Comments

Popular posts from this blog

Installing CentOS 7 on a Raspberry Pi 3

Modifying the Zebra F-701 & F-402 pens

How to fix DPM Auto-Protection failures of SQL servers