After Hours

The 10 worst ways to communicate with end users

To be a successful support tech, you have to be a skilled communicator. See if you recognize any of these common communication missteps.

You think you're a good communicator: You keep your users informed and you listen to their problems. So why is it that no one appears to read your emails or seems capable of following your instructions? Are you surprised to learn that the users have been living with computer issues rather than ask you for help? These are all signs of a breakdown in communication -- which we, as support techs, frequently misinterpret as user indifference or even stupidity. Before long, we find ourselves on a downward spiral toward complete communications failure. Even with the best intentions, it's possible to sabotage our own attempts to communicate with the users by inadvertently committing one or more of the following deadly sins of miscommunication.

Note: This post is based on a previously published article. It's also available as a PDF download.

1: Inappropriate nonverbal communication

Our words may say, "Absolutely, yes, of course I don't mind helping you change the toner cartridge," while our facial expressions, tone, and body language simultaneously scream, "You complete and utter gimboid, do you honestly think that I spent four years in school, have an IQ of 167, and earned 53 technical certifications just so I could change your toner cartridge? Would you like me to breathe for you too?"

It's not necessary to be a behavioral psychologist to know that tutting under your breath, rolling your eyes, and suppressing little smirks combined with your apparently kind words, sends a patronizing, insulting message to the user. Instead, if you are frequently asked to perform such seemingly menial tasks as changing toner cartridges, turn it into an opportunity to educate and empower the user.

2: Showing off

Just because we happen to know all the correct technical terms and concepts does not mean we should use them when communicating with users. Providing instructions that are overly technical and contain far more information than users need is not the most effective means of conveying our message. Instead of impressing a user with our superior knowledge, it alienates and belittles them and makes us seem supercilious and pompous.

For example, telling users to clear their cache and delete their objects to solve a browser issue may be technically correct. But the chances are, if a user knows how to carry out these instructions, he or she has already done it. Try giving the user click-by-click instructions on how to perform these tasks, perhaps accompanied by a single line of explanation in terms the user can relate to. Aim to impress with your attitude instead of your knowledge.

3: Losing patience

If William Langland had not coined the expression "Patience is a virtue" in 1377, I am firmly convinced that it would have been invented by an enlightened support tech sometime during the latter half of the twentieth century, just as humans were being introduced to computers in the workplace. Even though the computer literacy of the general working population has steadily improved over the intervening years, there always seems to be at least one user who simply doesn't get it, and whose persistence in demanding help for the same problem stretches our patience to its breaking point.

Calling the user a brainless twit and bashing him or her over the head with a gel wrist relief may provide a moment of immense satisfaction. But it's likely to result in a miffed user and an unemployed support tech and should, therefore, be avoided at all costs. A better alternative is to develop techniques for (a) preventing such situations and (b) handling them appropriately when they do occur.

4: Being dismissive

Imagine going to see your doctor because you have a mysterious green knobbly growth in your arm pit and all he does is pat you reassuringly on the back and tell you not to worry but do come back in a month or two if it hasn't gone away. How would this make you feel? What if the doctor didn't even look at the growth? This is precisely how we make the users feel when we fail to engage with their problems, dismissing them with platitudes and vacuous reassurances. Even though we may be 100 percent certain that Bob's computer isn't really taking twice as long to boot up and that Marcie must be imagining that high-pitched whine, telling them not to worry about it and to let you know if the problem doesn't go away achieves absolutely nothing except to make them feel stupid and insignificant.

Whether a computer problem is real or perceived makes little difference to users. All they know is that they have a problem that needs to be resolved. Even merely perceived problems can be fixed with some sensitivity and a little creativity. However insignificant the issue, by engaging in the problem and treating users with respect we increase their confidence in us and open the lines of communication.

5: Failure to inform

This may seem like stereotyping, but in general, geeks are not natural communicators, at least not when it comes to communicating with members of our own species. Unfortunately, the ability to meaningfully communicate with fellow human beings is a prerequisite for being effective in our role as support techs. In many organizations, the support tech is the user's prime interface with the IT department. Support techs function as Babel fish, translating between geek and human, and are ultimately responsible for ensuring that users are kept informed and up to date.

Constant communication is a critical part of fulfilling any work order, from acknowledging its receipt all the way through the process to a follow-up phone call to make sure the user is satisfied with the work performed. Often, users can accept a delay provided they know about it in advance and can plan accordingly.

6: Lack of documentation

Not providing the users with consistent, clear, and easy-to-follow instructions is another way in which we frequently fail to communicate. Various aspects of our jobs require us to write user-consumable documentation, such as instructions for new procedures, explanation of corporate computer-usage polices, and manuals for new employees. Before distributing new documentation, test it out on a few users. Well-written documentation, kept organized and up to-date, should ultimately save you time, as it provides users with an immediate resource for answering their questions.

7: Lying

What should you do if you're asked to perform a task you find laborious or boring? Or what if you're asked a question to which you don't know the answer? What if the answer to an inquiry is something that will make the user unhappy? In such circumstances, bending the truth or misrepresenting the facts can be alluring, especially if the lie seems harmless and the chances of being caught are small. Is lying to the user ever justified? Sometimes, it's necessary to simplify the facts to give users an explanation they can comprehend -- but that's different from deliberately lying to avoid work or to save face.

Many years ago, I worked with a senior support tech who was in the habit of blaming Microsoft for everything. When users came to him with a problem he could not immediately resolve, he would tell them it was a Microsoft issue and they just had to live with it. After awhile, users stopped going to him with their problems and he took to bragging about what a great job he was doing, as his users had so few issues. This situation continued until the next IT reorg, when he was assigned to a different group of users who were more computer-savvy and accustomed to being treated with more respect. A few weeks later, the tech was out of work due to the high level of complaints and his declining skills.

In short, when presented with a problem we can't resolve, for whatever reason, it's far better to be direct with users and help them find a resolution by some other means than to mask our ignorance or unwillingness as an insoluble technical issue.

8: Giving too much information

Honesty may be the best policy, but this does not mean it's appropriate to overburden users with too much information. A mother of five grown-up boys once told me that in her experience, the average teenager will tune out all but the first three sentences of any lecture. So you want to pick those sentences carefully. It may be unfair to compare users with teenage boys, but the principle still applies: Limit communication to what's absolutely essential and don't expect users to absorb too much information at once.

It's possible to fail to communicate by overcommunicating, in terms of both frequency and detail. If we email everyone in the company every time the slightest imperceptible change is made to the users' environment, many of them will simply ignore the messages. Before long, work orders to set up inbox rules deleting messages from the IT department will start flowing in to the help desk.

Limit mass email to the users who will actually be perceptibly affected by an upgrade, downtime, or some other change. If the impact is for a limited period of time, such as a lunchtime reboot of the email server, set an expiration date and time on the message. Be careful not to overwhelm users with details or explanations that aren't relevant to them. For example, if the email server needs an unexpected reboot at midday, tell the users the time, expected length of outage, what it means for them, and what -- if anything -- they need to do. Users don't need to be given full explanation of why the reboot is necessary, although a single sentence summarizing the problem may help them appreciate the urgency and is more likely to elicit their cooperation.

9: Not providing training

Training is not restricted to sitting in a classroom for three days learning how to create a PowerPoint presentation. Support tech-provided training can be as simple as a 30-second demonstration to a single user on how to add a contact to his or her address book or as complex as a multi-day onsite class on advanced report writing.

Even if providing training is not part of the support tech's formal job description, it's almost impossible to effectively fulfill the job function without training users. Some techs deliberately avoid educating users because they regard knowledgeable users as a threat to the integrity of the network or to their jobs. Although these concerns should not be dismissed as mere paranoia, they aren't valid reasons for failing to improve the computer literacy of users.

10: Failing to listen

Communication is a two-way process. As support techs, we need to actively listen to our users. By definition, our role is to support our users, to enable them to perform their job functions, something we can hope to do only if we have a thorough understanding of their needs. As time allows, listening can be a proactive process, with the support tech spending time with users to learn their routines and to see where technology can be applied to improve productivity or safety.

Opportunities for user feedback can be created through feedback forms, satisfaction surveys, follow-up phone calls, and even brown-bag lunches. Although it may not be possible or even desirable from a business standpoint to implement all of the users' requests, without making a concerted effort to align the IT function with the business directive, it's all too easy for the IT department to become wholly self-serving and to perceive users as little more than an inconvenience.

Agree or disagree?

What do you think about the points raised here? How realistic are these recommendations?

43 comments
cRizOselliva
cRizOselliva

..you need to be more patient when handling end users cause we need them in our job..you need to teach them how to teach us..

mginnard
mginnard

Communication skills cannot be over-emphasized in the IT Industry. These rare "people skills" translate into job security when ability alone would not be the case.

Badge3832
Badge3832

I find it hard to believe that anybody learned anything from this article. If you didn't know this stuff already, you're in the wrong job.

sboverie
sboverie

Communication is a 2 way process and still has pitfalls that make most communications fail. It helps to be aware that people are not neccesarily stupid, most do not have the depth of knowledge you have and more important you do not have the depth of knowledge the client has. Techs tend to use acronyms and jargon that are incomprehensible outside of geekdom. I was taught a concept called the customer retention cycle. In this model, the customer can be an internal or an external customer. An example of an internal customer is you boss, your co-workers and other people in your company. An external customer is what we think of when we think of customers. The cycle begins with a greeting. Techs tend to skimp on this point (I am guilty of this too) but the idea is to let the customer shift gears and be involved with giving information. The next step is to gather information, define the problem and ask questions to narrow down the problem. Skimping over data gathering will increase the probability that the solution will not work. Diagnosis and solution is the next step, if the solution does not work then more information is needed or a different approach to the problem. Verifying with the customer that the solution fixes their problem is the next step followed by asking if there is anything else that you can do for them (this invites the customer back into the cycle). The idea of the customer retention cycle is to take more effort to provide service to the customer so that they will be happy to use your services and, more importantly, refer other people to you. Also, the idea of internal customers is helpful to understand how effective you are for your company.

borglah
borglah

I used to be an elementary school teacher, and most of what I learned about dealing with children applies in my tech job as well. Patience, listening, and REPEATING what they said to you in your own words will often help clarify the problem. Example I had: CLIENT: "I need all my employee's contacts put in my Outlook" ME "So you are asking me to copy all the contacts from this persons's Outlook address book into yours?" CLIENT: "No, I want the contacts that AREN'T in their address book." ME: "Give me an example of a contact you need that she has." CLIENT: "When my employee starts to type

jmichalec
jmichalec

Great article and I believe that I even made many of these mistakes along my career. Interesting is the lying issue because sometimes I find myself blaming Microsoft, especially when for example, the user tries something with IE9 and it does not work on but it does work on Firefox, Chrome, Safari, Opera, etc. You see the point ;) But I will curtail that explanation after reading this. The one point I wanted to make was that I have one person who is above me in the chain of command. She is not a tech but more of a liasion between me and the company's VP. She has a total negative view of computer "users" and in fact, has a large sign in her office that says "The only good computer user is a dead one". Can you imagine she still has a job? Anyway, I take pride when the "users" call me and refuse to call her. Thanks again for the article.

neily
neily

excellent article,accurate, i personally have made all the mistakes in the article. another tech told me to tell the customer to "Toggle the Master Re-Boot Modulator " ( the power-switch ) hee hhee

RetiredGeek
RetiredGeek

I worked in Microsoft tech support for over 10 years and even with all the training received on both the products and how to deliver support, one of the most important things was to be patient. Sometimes it was the lack of knowledge of the caller, sometimes it was the perceived amount of knowledge of the IT expert who had an issue, and sometimes it was just being able to deal with the unknown. (I'll be the first to admit that there were a lot of bugs, er, I mean, design features in the products, and being patient while the customer vented was very important, too.) One of my favorite memories occurred when walking a Mac user through a series of steps and he couldn't locate the button he was supposed to click... Me: "Look at the lower right corner of the dialog box." Customer: "Is that your right or mine?" Patience!

CharlieSpencer
CharlieSpencer

Most often, I lose patience with myself. If I'm not effectively communicating with the user, I get frustrated with my inability to express the concept in terms he or she can understand. That frustration is easily mistaken for anger and a lack of patience with the user. I'm aware of it, but often not until I'm already doing it.

JohnOfStony
JohnOfStony

As a software developer, I am continually trying to broaden my knowledge so as to improve the software I develop and expand my potential and frequently I have occasion to use 'Help' which all too often tells me what to do but not how to do it, the latter being the more important. A classic example of really bad 'help' was when I finally succumbed and bought an iPod Touch in January this year. It took me a whole evening and part of the following morning to figure out how to use iTunes to put my music and photo collections onto the iPod. I ended up having to use Apple forums because the help was so useless. May I suggest that every 'help' article has "how" links throughout so that the text isn't overburdened with detail unnecessary to the more knowledgeable, but for complete newbies who need the fine detail, it's there at the click of a mouse? I must add that I've been full time in IT since 1978 and have worked in many different software environments so for a program to have me stumped it must be really badly designed. I'm absolutely astonished that the company that produced the delightfully intuitive iPod Touch could have produced the mess that is iTunes.

SKDTech
SKDTech

I actually had a user praise me the other day because I am not afraid to tell people "I don't know, but I will either research it or put you in touch with someone who does know/can help you". It is impossible, or at least impractical, for every tech to know everything. The important skill is knowing where and how to find information or the right person for the job.

Zianda
Zianda

Wow,good points u raising for us.Most of the time we tend to rush through to provide the solution for the user without even asking them what really went wrong....this will not only allianate us frm the user but lead to dissatisfaction

santeewelding
santeewelding

First, I don't "feel". Try indifference. The emotional imperative does not work; neither here nor in what immediately follows. Second, "makes (users) feel stupid and insignificant" betrays another aspect of your fundament, Becky, and those who respond approvingly to your piece of writing. I know. I know. You all have a job to do. You are "middle", sandwiched and squeezed between conventional structure of above and below. I think your structure would fall apart if, no matter who you encounter -- including self-encounter, no one were "user", but "sovereign". Stupidity and insignificance, as you put it, are the sole charge and responsibility of sovereignty. Not yours with respect to another. Goes without saying that, were one to decide so, one would be no longer. Sovereign, that is. You would have them, and how you say what you say would make sense. I also advise that the "realistic" in your other question has no bearing on the reality of my sovereignty; that is, if you hadn't guessed.

pgit
pgit

This has to be the most well crafted article I've yet read here on TR. There's only one thing I'd suggest: you should make the text "babel fish" a link to the definition... in the event any non-geeks read this, which is likely. ;)

gmcprsm2011
gmcprsm2011

Great article, but kkaty_98, what does FORU stand for? That's an acronym I've not seen before.

kkaty_98
kkaty_98

Too often we don't ever take the time to comprehend how a user understands the technology. We can use every analogy we have ever found effective and it still doesn't fit. If the job is to make the technology useful, step one is understanding how the user..not only uses but how they truly comprehend it.

gdburton
gdburton

Although much of this article reads as "directed" common sense, it is definitely worth saying it. (Again & again!) We are all liable to fall into one or more of these traps, some of the time. I might have put No10 up at No1. Not listening and jumping to the quickest reason that explains the first symptom the user reports is all too easy. Great article, thanks Becky

jemorris
jemorris

with a practical field test afterwards. I know some local "Geek Squad", Office Depot & Staples techs that would fail miserably!

Papa_Bill
Papa_Bill

Others learn best "on the job".

NickNielsen
NickNielsen

I'm not having any trouble believing there are still people who already [think they] know it all...

TBBrick
TBBrick

You need to to something about that, "So glad to be me, so sad that you're not!" attitude. I can just see your users cringe when they hear your smug voice on the line.

sboverie
sboverie

Why would you assume that this article did not have some bit of fresh information for someone else?

ScottRohl
ScottRohl

Those big words yes do the job, but do the job and dont make people feel bad with those big words you Know!

boxfiddler
boxfiddler

One of your milder, not to mention more understandable posts. Nothing particularly insulting, along with thought provoking comment. I guess folks just don't like to think. Why am I not surprised?

Hobbesl
Hobbesl

The question wasn't, "What do you feel about the points raised here?" The question was "What do you think about the points raised here?" The author wants to know if, in your opinion, are the points raised realistic. I'm not certain what you are trying to say in your second paragraph. Becky is stating that being dismissive and condescending to the end user makes him or her feel stupid and insignificant. This is true and there are many studies to prove it. Remember the bad experiences you've had as a customer. How did you feel during those situations? You probably felt frustrated and that the support person was treating your issue as stupid and insignificant. I think what you're trying to say in your fourth paragraph, is that a person shouldn't empower someone else to make him or her feel stupid or insignificant. This is true but not very realistic. First, it takes mental discipline to accomplish this and second, often it's used as an excuse for bad behavior. As for your closing paragraph, I'm not certain you understood the nuance of the term "realistic" in this context. Think of probable versus possible; is it possible someone will give me a million dollars? Yes. Is it probable? No. In the context of Beckys article, "realistic" is used in a similar way. Certainly it is possible to utilize all of Becky's suggestions. The question is, given whatever circumstances there are surrounding the technician, is it probable? Thats the opinion Becky is requesting from each person.

spdragoo
spdragoo

So, #1, santeewelding is claiming to not be human, since he/she/it isn't affected by "emotional imperatives". Which is ridiculous, as I sincerely doubt that TechRepublic has any AIs that are subscribed as members to the website. As for #2, apparently santeewelding feels that other people shouldn't ever be affected by "emotional imperatives", since exception is taken with the article's statement "makes (users) feel stupid and insignificant". Although that seems hypocritical, given that there's almost an emotional flavor to the reaction. As for the rest...I'm assuming someone's experimenting with their medication (too much, too little, it's hard to say which). Although, if taken literally, I suppose the stance being advocated is that each person should be the one responsible for coding & programming their own separate OSs & applications, so that we can all be "sovereigns" of our destiny. Which is just plain silly. I mean, if you're crossing the street with the green light in the crosswalk, & some idiot decides to ignore the red light & hit you... it doesn't matter how "sovereign" your control of your own decisions are, you have *no* "sovereignty" over the other person's choices. Nor can santeewelding have 100% "sovereignty" over their own life. At some point, someone else will be the one deciding how the work is performed, when the work is due, who will be on the team performing the work, & what computer hardware/software (if any) will be utilized in the work. Sure, one can always choose to quit & look for another job, but "sovereignty" won't put food on the table, money in the bank account, or gas in the car.

gmcprsm2011
gmcprsm2011

Is it just me or does santeewelding's comment sound like a drug induced rambling of unintelligible thought?

warpie
warpie

Naturally, FORU is: FORU, the Federation of Oceania Rugby Unions, is the International Rugby Board's Regional representative in Oceania. Perhaps this relates to point 7?? I have no idea, but I am surprised at how many "dismiss" the helpful information, whether repeated or not, that this provides.

ScottRohl
ScottRohl

There is I have been to it with IBM.

santeewelding
santeewelding

I will use small words, one part each, to lead them as though by a ring through the septum (oops!).

santeewelding
santeewelding

Was changed to, "think", sometime in the two days after my comment.

Papa_Bill
Papa_Bill

leans toward the avant garde. One must examine it closely in order to garner the intent of the artist, although it is not necessarily true that one of lesser introspect could possibly seize upon the nobler aspect of deeper-than-thou thought. It is a challenge to consider, to fondle gently and then to discard with an all-consuming sense of loss. So there.

cory.schultze
cory.schultze

I really can't grasp his point there. That is, if a point is intended or whether the author's intentions are to induce inflection in the reader. It does appear to be a loosely associated (if only by words alone) paradigm. Ha ha! Now I'm doing it! Sovereign, or dominion, SanteeWelding? Are you trying to imply that users should infact be considered paying customers, and that failing to support them effectively will directly affect their loyalty to you, which in-turn affects the security your role in technical support? And that the users' stupidity is resultant of your failure to educate? That these users are your property, if you wish, and you're fully responsible for their actions, as with man and dog? Nah, you're still gonna have to explain it...

Papa_Bill
Papa_Bill

after three shots of cheap tequila and four of what the guy said was generic Xanax. After my neurons began to ooze out through my hair follicles, and were given a buzz cut by mistake, it all became as clear as my forty-year-old specs from the the back of my desk drawer. Here is my decryption of Santee's post: he sai oops, battery dead

santeewelding
santeewelding

They arise as consequence of speaking without using the word, God.

cory.schultze
cory.schultze

...applies to those of us who have expressed our incomprehension of your comment. I make no claim to another's opinion, I merely state a fact of common interest. "We" just don't get it - sovereignty in the classic sense is territorial control, it almost seems as though you're implying another meaning. Whatever the case, a comprehensive median has not been attained in this matter and I fear never will be if riddles ensue. One thing we can agree on, is that this post has crashed and burned...

santeewelding
santeewelding

Your bit about, "only you fully understand", runs smack into sovereignty. Would that I fully understood my intent, and whatever else goes on between my ears, I may only claim that knowledge of myself for myself. No way in hell do I claim to know that of another, and certainly not for need of "we", which you do. This does not forbid that I conjecture. Thing is, I [i]know[/i] I guess. What are [i]you[/i] doing? I'll leave the pieces of your "theory [b]of[/b] sovereignty" for another time, it having suffered a head-on collision, too.

cory.schultze
cory.schultze

OK, I don't think sesquipediality is the defining factor of condescension. Many people understand the meanings of complex words. It's the context and syntax that make the difference. It was Baba Ram Dass who once said "Only that in you which is me can hear what I'm saying". Basically, only you fully understand your intent. You cannot assume anyone else to. That said, the ring through the septum part is a little less cryptic. We still need some clarification on your theory of sovereignty.

santeewelding
santeewelding

Is a poor word to use in reference to that which has no beginning, no end, and therefore cannot be relatively tracked and characterized.

cory.schultze
cory.schultze

As any reader can see, I have no point to make, only questions to ask and assumptions to cast. Perhaps your sovereignety could be your salvation in this sub-debate; take control of your destiny, please help us understand your words...