In order to help someone, you first need to understand (at least somewhat) what they are going through. That's why part 2 covered "asking for help" first. Understanding both sides of the conversation is key to trying to get both parties points across. You need to know how to spot the lie that every customer will eventually tell. You need to know how to get to the root of the problem, even though the customer may not know it themselves.
But first and foremost, you must be polite and patient. No matter how frustrated you may be, you have to remember that they are contacting you for help because they don't know the answer themselves. Even if you've told them the answer on previous occasions, you still need to be polite and patient. Just like getting angry when asking questions gets you nowhere, getting angry when helping someone is even worse. If you get mad at your customer, news that you were "short" with the customer may make it up to your management, which can put you on their target list.
Getting the correct information out of your customer is the next challenge. If you are face to face with the customer, and you can physically examine the problem yourself, this is typically not an issue. However, if you are on the phone or sending emails with the customer, this can be an interesting challenge. If it's on the phone, ask the customer to do one thing and one thing only, then report back with the results. Preferably with you still on hold or talking to the customer so you can gauge how long it takes. For example, if you ask them to "Type ipconfig and press enter...tell me what it says", and that takes more then 10 seconds, then you know something else could be going on. Having them read exactly what is on the screen is always challenging, but you have to be patient. I can't count the number of times I've heard "nothing is on the screen". I almost always reply "Ok. Then let's turn the computer on and give it a few minutes to start up". Rude? Probably. But it gets the point across that they need to be more accurate.
Talking to a customer over email is a very different process. Odds are when you ask more then one question in a single email, the customer will only answer the first question. (at least, that's my experience.) If you need to ask them several questions, do so with a numbered list. This way it's obvious that there are multiple questions involved.
If you have the ability to, screen sharing tools can save a lot of time and frustration. LogMeIn, GoToMyPC, VNC, Simple Help...all these tools let you and the customer share their screen so you can see exactly what's going on without any guess work. I've never done the math on how fast the payback was, but when we started using Simple Help for support at K12USA.Com, complicated support calls ended up taking a lot less time because we could see exactly what the customer was seeing, and in cases where we needed to, we could do the fix ourselves.
I'm sure some people will comment on this one, but while keeping in mind you have to be polite and patient, the customer is not always right. If they are wrong about something, tell them. Don't just placate their ideas. They won't learn, and they'll just end up calling you back.
Another great "tool" when talking to customers is to acknowledge when there is something broken with the process or program, and apologize. An apology from someone can mean a lot. It means that you, as an IT person, acknowledge that they are frustrated, and that you're taking responsibility for their frustrations. It exposes the fact that you are in fact human, and that you too can make mistakes.
If you cannot solve the problem right away, tell the customer that you will follow up with them and give them status updates. Then...actually follow up with them. Use a reminder in your calendaring software so you don't forget. Even if the update is "we're waiting for a patch from X to fix your problem", it's still an update, and it shows you care about their problem.
When you're all done and the problem is solved, recap what's happened, allowing them time to ask any clarification questions and giving them time to take notes. Try to teach the customer exactly why you did what you did, so that they can use the call as a learning experience.
Depending on the problem, it may be worth following up after the problem is solved. For example, if you're not 100% sure the problem was solved, or if it was a solution that was drawn out and took a long time to fix, reaching out to the customer to make sure their problem is still solved makes sure the problem really IS fixed and that the customer isn't just "dealing with it".
We may not love doing it all the time, but we all have to help a customer at some point. If you do it right, then all involved parties will walk away satisfied, you'll have another ticket in your "solved" bin, and you may have even taught someone something.
I'm sure some people will comment on this one, but while keeping in mind you have to be polite and patient, the customer is not always right. If they are wrong about something, tell them. Don't just placate their ideas. They won't learn, and they'll just end up calling you back.
Another great "tool" when talking to customers is to acknowledge when there is something broken with the process or program, and apologize. An apology from someone can mean a lot. It means that you, as an IT person, acknowledge that they are frustrated, and that you're taking responsibility for their frustrations. It exposes the fact that you are in fact human, and that you too can make mistakes.
If you cannot solve the problem right away, tell the customer that you will follow up with them and give them status updates. Then...actually follow up with them. Use a reminder in your calendaring software so you don't forget. Even if the update is "we're waiting for a patch from X to fix your problem", it's still an update, and it shows you care about their problem.
When you're all done and the problem is solved, recap what's happened, allowing them time to ask any clarification questions and giving them time to take notes. Try to teach the customer exactly why you did what you did, so that they can use the call as a learning experience.
Depending on the problem, it may be worth following up after the problem is solved. For example, if you're not 100% sure the problem was solved, or if it was a solution that was drawn out and took a long time to fix, reaching out to the customer to make sure their problem is still solved makes sure the problem really IS fixed and that the customer isn't just "dealing with it".
We may not love doing it all the time, but we all have to help a customer at some point. If you do it right, then all involved parties will walk away satisfied, you'll have another ticket in your "solved" bin, and you may have even taught someone something.
No comments:
Post a Comment