Working W/ End Users Toward an Effective Solution

Posted on
Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

A study released recently by Forrester Research showed that only 53 percent of respondents to a survey of 2,138 technology users within U.S. companies were satisfied with their help desk experiences. Two of the primary issues behind the substantial dissatisfied minority’s frustrations were the overall time it took to resolve their requests and the ability to solve their problems the first time around.

In a perfect world, every call you took from end users would involve them asking you a simple, straightforward question and you responding with a simple, straightforward answer—case closed. But it’s hardly ever that easy. It’s frequently a non-linear process that entails taking two steps forward, then two steps back, then another two steps forward, and so on. Most customers—and a good many help desk professionals, too—get really frustrated in these circumstances. Yet you’ve got to maintain a clear head and patient disposition while you try to resolve the end users’ problems as quickly as possible.

Now, the frequent failure of end users to understand and empathize with the difficult circumstances that support professionals are often faced with is a given. More often than not, they don’t appreciate the fact that you might not be able to see what they are looking at, and therefore can’t come up with a solution immediately. Or that their own technical incompetence may be hindering the effort to resolve their issue. However, you have to put all that aside during the call and focus on possible fixes for their problems.

To enhance your own ability to bring a help desk call to a successful conclusion faster, you need to put on your Sherlock Holmes hat and exercise your super sleuthing skills. First of all, you’ll need to approach every problem with an open mind. Don’t assume you have an answer until you’ve heard all the details of the end user’s difficulties.

Additionally, be sure to really listen to end users themselves to determine how tech savvy they are. If they refer to icons on their monitors as “doohickeys” or “whatchamacallits,” then you may need to speak slowly and start with the simple stuff. But if they seem to know their way around an operating system, you might want to consider skipping ahead to the more advanced potential problems.

Also, don’t rely too heavily on a set of FAQs or stock solutions to a point. You should try to find out as much about the hardware, software or system that you’re troubleshooting so that you can utilize your own knowledge of the subject to find answers. In order to do this, you can familiarize yourself with product manuals, or even talk to the developers, engineers and administrators who design, implement and maintain those solutions. Ask them what problems they frequently run into in their own day-to-day tasks. This may provide you with a great deal of insight into the issues that customers who call in might face.

Finally, once you’ve figured out what the problem is, don’t merely give them the answer and assume the matter is settled. They may call back shortly thereafter with the same problem and waste their own and a support professional’s time getting the same thing explained to them again. Try to make clear to customers why that solution works so that they’ll really understand it and internalize the information, and be able to apply it over and over again in the future. As the old Chinese proverb goes, “Give a man a fish, and you’ll feed him for a day. Teach him to fish and you’ll feed him for life.”

–Brian Summerfield,

Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone


Posted in Archive|


Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>