How-To: Speak to your client (Part 2)
As we discussed in part 1, communication is as big a part of your job as a technician as the technical know how. No longer are the days where the IS or IT departments are holed up in a bunker some 20 floors beneath street level, or put in a 3 foot by 5 foot closet and expected to never speak to anyone. As a current technician, you are going to be forced to interact with your users directly. Whether that means being on a SPOC (single point of contact) such as a helpdesk or technical support line and speaking to the users on a regular basis, or being a second/third level technician who needs more information about an issue and must contact that user, you will be speaking to someone outside of the IT department eventually. How easily you can adapt your conversation to the user's knowledge level will determine how much confidence the user will have in you, as well as what kind of leeway they will give you should the resolution take longer than expected.
This article focuses on the soft skill (or people skill) techniques you can use to communicate more effectively with your client which will let you focus on the more technical part of your job. We will go over things like how to determine your user's technical competency, how to explain issues to a non-technical person, and in a forthcoming article, how to politely refuse a client's request.
Before you even begin to think about explaining an issue to a user, you must first determine their technical competency. By jumping the gun and explaining in minute detail how a particular server's file system crashed to a non-technical person could make that person feel inept or stupid which could lead to more problems during the duration of the issue, and conversely, telling a technically-inclined person that 'the smart TV box needed a nap' could invoke the reaction by the listener that you are the dumb one. So, the question you're probably asking is: 'How do I determine what a user's technical competency level is?' Unfortunately, this is something of a soft science and can't be precisely defined. There aren't any hard and fast rules to determine how skilled your user is, but there are some things you can listen for that might give point you in the right direction:
- Does the user seem to be forcing you to do all the work?
Example: You're asking them to do something simple like a few mouse clicks and they still want you to come to their desk and do it for them?
This could be because the user just doesn't feel comfortable doing something that they haven't done before. I know personally, if I'm learning a new procedure, I like having someone watch over my shoulder the first time I walk through it, just to make sure that I'm doing it right. If I can get through it with nothing breaking, I'm a happy camper and won't have any problems doing it again by myself. The user may find themselves in the same boat: they want to have someone watching over their shoulder to ensure that they aren't causing any more problems. Now this doesn't necessarily mean that this person is completely green, but if you have this request multiple times from the same user, a little light should go off in your head that this user may not have the skillset you do.
On the other hand having a user that really loves to work the KB and mouse does not indicate that they are either competent or willing to learn. I've often experience this as a power user wanna be. A very dangerous position to be in, this user often has lots of questions and seems to know the lingo. It will take some time to determine if the user really is on the ball, a statement like "Should I reinstall the TCP/IP stack?" clearly shows that someone has learned to do something but doesn't really know what it does. In case you aren't sure the answer is always "NO" if the TCP/IP stack needs to be reinstalled, you do it and NOT in front of the user.
- Does the user say the word 'thing' a lot?
Example: 'That computer-thing is making a lot of noise?' or 'The thing I just clicked on went away.'
99% of all people have an innate desire to show off/brag/etc. as often as possible. Why does that matter? Because if they knew the term, they would use it to try and impress you (or perhaps simply themselves). Instead, the user is trying to let you know that they are manipulating a certain object but don't know how to explain or describe it any better. Hearing the word 'thing' a lot usually gives me the impression that the person does honestly want to help you help them, but don't have the know-how to do so.
As well as I touched on above, a use of correct technical terms is not a clear indication of capability either. What you are really looking for here is more the ability of the user to articulate and be comfortable in their environment. You may have a user that says "I'm using program and trying to process when I get error." This isn't proof that the user knows what's going on, it simply indicates that the person can explain things to you accurately.
These are just two of millions of subtle nuances you should be listening for when speaking to a client explain an issue; little hints that should give you a fairly good idea of what kind of person you're speaking with. You have to remember that you shouldn't only be listening to what a user says, but also how they say it. Like you probably know, something like 70% of face-to-face communication is through body language. Why does that matter? Because even if you're not face-to-face with your user, you can still hear different movements. I know that you're probably thinking that I'm crazy, but the next time you're on the phone, I bet that without a doubt you could at the very least be able to tell if the person you're speaking with is smiling. That's a physical action, but it's incredibly easy to pick up on if you actually listen for it.
The next question I can hear you asking is: 'Alright, well now that I know my user has a [terrible/alright/excellent] technical background; what do I do with this information?' You want to take this information and tailor the rest of your conversations to their skill level. The reason you want to do this is that, as we discussed earlier, you don't want to go over your user's head because they'll just end up zoning out and not listening to anything you say and you also don't want to patronize someone who does have the knowledge. If there is ever a case of doubt, you are better off assuming that the user does not know or is not interested in knowing and you should reveal virtually nothing about the situation.
You want to be able to keep your listener interested throughout as much of the conversation as possible, so when you're describing things to a non-technical person don't go overboard on the details. Instead of saying something like 'the software's internal development team didn't use the strongly() function and so there was a stack overflow and the core dumped', say something like 'there is a problem with the program and there is nothing you could have done, the best thing you can do if you come across another problem like this is contact us'. Most people aren't going to care why the program broke, they're just going to want to know that someone knows it's broken; how it gets fixed generally won't concern them. As the saying goes, 'Ignorance is bliss.' Like most people who don't care what goes on under the hood of their car, they just want it to get them from A to B, most people don't care that the page file needed to be moved to a different drive and that the RAM was upgraded from DDR to DDR2, so long as they can still save their Word documents.
You want to use the vaguest terms possible, I would advise that you not provide any at all while still maintaining the essentials of the resolution. You don't want to lie about any details, but by going overboard on the specifics that are more than likely going to fly over your user's head anyways, you're just wasting both your and their time. It is best to say 'The issue is fixed now, if you or anyone else in the office has this problem again have them contact us right away.' You can also use analogies, but be sure to use a pre-planned analogy, and not something on the fly. Why pre-planned? It's because if you realize you need to change something halfway through your explanation, chances are high that your user will already have assimilated the first part, and will have an incredibly difficult time remembering something different. The whole reason for using an analogy is to link a familiar mental picture to something new, in the hopes that they'll remember it. An upcoming post will contain an excellent example of an analogy that should be used whenever possible, watch out for it.
To end off this article, I'd like to leave you with one more helpful tip. You are eventually going to have people who, after you've fixed a problem and explained the solution in layman's terms, ask for more details. The big conundrum here is how much detail do you go into? My answer is to let them know that any more explanation is going to be highly technical and might not make any sense. At this point they can make up their mind with whatever they feel comfortable with, and with either decision, you win. If they decide not to have you go further into detail, this will allow you to get back to your other awaiting work, and if they ask you to explain it to them, chances are that you might have underestimated their technical skills, and/or they really are eager to learn. I personally really like it when someone asks me to explain the technical details, it gives me an opportunity to speak in my native tongue (Geek) and not apologize.
Always remember the most important tip of all: enjoy yourself if you can; the moments where the crisis is averted and you are the hero are the moments in which you get to enjoy your professional pride. Take pleasure in the fact that at the end of the call a client who started off angry is now happy with your work.
Justin Smith
nexxai@gmail.com
This article focuses on the soft skill (or people skill) techniques you can use to communicate more effectively with your client which will let you focus on the more technical part of your job. We will go over things like how to determine your user's technical competency, how to explain issues to a non-technical person, and in a forthcoming article, how to politely refuse a client's request.
Before you even begin to think about explaining an issue to a user, you must first determine their technical competency. By jumping the gun and explaining in minute detail how a particular server's file system crashed to a non-technical person could make that person feel inept or stupid which could lead to more problems during the duration of the issue, and conversely, telling a technically-inclined person that 'the smart TV box needed a nap' could invoke the reaction by the listener that you are the dumb one. So, the question you're probably asking is: 'How do I determine what a user's technical competency level is?' Unfortunately, this is something of a soft science and can't be precisely defined. There aren't any hard and fast rules to determine how skilled your user is, but there are some things you can listen for that might give point you in the right direction:
- Does the user seem to be forcing you to do all the work?
Example: You're asking them to do something simple like a few mouse clicks and they still want you to come to their desk and do it for them?
This could be because the user just doesn't feel comfortable doing something that they haven't done before. I know personally, if I'm learning a new procedure, I like having someone watch over my shoulder the first time I walk through it, just to make sure that I'm doing it right. If I can get through it with nothing breaking, I'm a happy camper and won't have any problems doing it again by myself. The user may find themselves in the same boat: they want to have someone watching over their shoulder to ensure that they aren't causing any more problems. Now this doesn't necessarily mean that this person is completely green, but if you have this request multiple times from the same user, a little light should go off in your head that this user may not have the skillset you do.
On the other hand having a user that really loves to work the KB and mouse does not indicate that they are either competent or willing to learn. I've often experience this as a power user wanna be. A very dangerous position to be in, this user often has lots of questions and seems to know the lingo. It will take some time to determine if the user really is on the ball, a statement like "Should I reinstall the TCP/IP stack?" clearly shows that someone has learned to do something but doesn't really know what it does. In case you aren't sure the answer is always "NO" if the TCP/IP stack needs to be reinstalled, you do it and NOT in front of the user.
- Does the user say the word 'thing' a lot?
Example: 'That computer-thing is making a lot of noise?' or 'The thing I just clicked on went away.'
99% of all people have an innate desire to show off/brag/etc. as often as possible. Why does that matter? Because if they knew the term, they would use it to try and impress you (or perhaps simply themselves). Instead, the user is trying to let you know that they are manipulating a certain object but don't know how to explain or describe it any better. Hearing the word 'thing' a lot usually gives me the impression that the person does honestly want to help you help them, but don't have the know-how to do so.
As well as I touched on above, a use of correct technical terms is not a clear indication of capability either. What you are really looking for here is more the ability of the user to articulate and be comfortable in their environment. You may have a user that says "I'm using program and trying to process when I get error." This isn't proof that the user knows what's going on, it simply indicates that the person can explain things to you accurately.
These are just two of millions of subtle nuances you should be listening for when speaking to a client explain an issue; little hints that should give you a fairly good idea of what kind of person you're speaking with. You have to remember that you shouldn't only be listening to what a user says, but also how they say it. Like you probably know, something like 70% of face-to-face communication is through body language. Why does that matter? Because even if you're not face-to-face with your user, you can still hear different movements. I know that you're probably thinking that I'm crazy, but the next time you're on the phone, I bet that without a doubt you could at the very least be able to tell if the person you're speaking with is smiling. That's a physical action, but it's incredibly easy to pick up on if you actually listen for it.
The next question I can hear you asking is: 'Alright, well now that I know my user has a [terrible/alright/excellent] technical background; what do I do with this information?' You want to take this information and tailor the rest of your conversations to their skill level. The reason you want to do this is that, as we discussed earlier, you don't want to go over your user's head because they'll just end up zoning out and not listening to anything you say and you also don't want to patronize someone who does have the knowledge. If there is ever a case of doubt, you are better off assuming that the user does not know or is not interested in knowing and you should reveal virtually nothing about the situation.
You want to be able to keep your listener interested throughout as much of the conversation as possible, so when you're describing things to a non-technical person don't go overboard on the details. Instead of saying something like 'the software's internal development team didn't use the strongly() function and so there was a stack overflow and the core dumped', say something like 'there is a problem with the program and there is nothing you could have done, the best thing you can do if you come across another problem like this is contact us'. Most people aren't going to care why the program broke, they're just going to want to know that someone knows it's broken; how it gets fixed generally won't concern them. As the saying goes, 'Ignorance is bliss.' Like most people who don't care what goes on under the hood of their car, they just want it to get them from A to B, most people don't care that the page file needed to be moved to a different drive and that the RAM was upgraded from DDR to DDR2, so long as they can still save their Word documents.
You want to use the vaguest terms possible, I would advise that you not provide any at all while still maintaining the essentials of the resolution. You don't want to lie about any details, but by going overboard on the specifics that are more than likely going to fly over your user's head anyways, you're just wasting both your and their time. It is best to say 'The issue is fixed now, if you or anyone else in the office has this problem again have them contact us right away.' You can also use analogies, but be sure to use a pre-planned analogy, and not something on the fly. Why pre-planned? It's because if you realize you need to change something halfway through your explanation, chances are high that your user will already have assimilated the first part, and will have an incredibly difficult time remembering something different. The whole reason for using an analogy is to link a familiar mental picture to something new, in the hopes that they'll remember it. An upcoming post will contain an excellent example of an analogy that should be used whenever possible, watch out for it.
To end off this article, I'd like to leave you with one more helpful tip. You are eventually going to have people who, after you've fixed a problem and explained the solution in layman's terms, ask for more details. The big conundrum here is how much detail do you go into? My answer is to let them know that any more explanation is going to be highly technical and might not make any sense. At this point they can make up their mind with whatever they feel comfortable with, and with either decision, you win. If they decide not to have you go further into detail, this will allow you to get back to your other awaiting work, and if they ask you to explain it to them, chances are that you might have underestimated their technical skills, and/or they really are eager to learn. I personally really like it when someone asks me to explain the technical details, it gives me an opportunity to speak in my native tongue (Geek) and not apologize.
Always remember the most important tip of all: enjoy yourself if you can; the moments where the crisis is averted and you are the hero are the moments in which you get to enjoy your professional pride. Take pleasure in the fact that at the end of the call a client who started off angry is now happy with your work.
Justin Smith
nexxai@gmail.com
posted by Justin Smith @ 2:27 PM
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home