member login  |  privacy policy  |  contact us
      Home  |  FAQ  |  Awards  |  Reports  |  Forum  |  Jobs  |  Consultants  |  Join  |  Order
   Inside
-General Management
-Web Support
-Customer Satisfaction
-Human Resources
-Call Center Operations
 www.ASPonline.com > Library > Customer Satisfaction >
 
An Engineer's Guide to Field Support Soft Skills: Ten Tips on Effective User Interaction

by Thomas S. Wolfe

Whether you are an engineer, technician, or consultant, if some aspect of your job involves user interaction through "field support", it is important to recognize just how much power and responsibility comes with what you say.

From the moment you are presented to an "end user" as someone qualified to diagnose and resolve their concern, you are being perceived in the same light as a doctor or lawyer. You have been recognized for having a very specialized area of expertise and are looked upon as nothing less than a guide to this seemingly "foreign" technical world. At the same time, you have been given a great opportunity. Your advice, recommendations, and even opinions are being taken to heart and intently listened to.

While your technical education and background may have opened the door for you to provide technical solutions, how effective you are as a "Support Professional" rarely depends on your technical know-how, but rather on how well you communicate and present your solution-- is it responsible, politically correct, and can it be understood by someone without your level of expertise?

Presentation is the realm where one can earn the respect of being a consummate professional by both end users and peers alike. The following tips are offered as guidelines to help foster the responsible and effective interaction I talk of. They are suggestions offered in service to building trust and confidence between yourself and the users that you service-- which in turn makes them want to come to you for solutions.

#10: Understand the Potential Impact of What You Say

I've crashed workstations while performing functions that shouldn't crash workstations and taken down servers installing patches that shouldn't take down servers. Through this, I've learned the hard way to preface such implementations with "Under normal circumstances. . ."

"This patch won't crash your server," while well-intentioned, is perhaps not as effective as "Under normal circumstances, this patch shouldn't crash your server". Explain that there's always a chance for something "out of the ordinary" to occur that might impact such operations, and that "it's probably not a bad idea to have your users log out and save all important data-- just to be safe".

It should almost go without saying that any updates to a production environment should be performed after hours, preferably on a Friday-- this will allow a failed backout to continue on through Saturday and Sunday.

#9: Communicate with both Professional Language and Metaphor

When explaining technical concepts to a user that does not have a technical background, use familiar analogies. Cars work well. Comparing 56k bandwidth to a residential street and a T1 connection as a four-lane freeway is one example. Comparing a 486 to a V4 compact and a Pentium II to a V8 performance auto can be used as another example. I've compared brand name computers to makes and models of cars, to help a non-technical user understand perceived differences.

Use words like "workstation" and "user" and "incident" and "resolution" in place of more common nouns. Use words like "identify" and "diagnose" and "implement", and "isolate". "Determine" environment statistics and the "frequency" of a particular problem or occurrence. "Correlate" this data and attempt to "isolate" or "identify" causes as part of your "diagnosis".

Seemingly "strange" things may pop up as part of your diagnosis of an incident. Avoid saying "this is strange" or "this is weird"-- instead refer to such occurrences as "unique".

#8: Don't Make Unrealistic Promises

If you are not certain that a patch or solution will solve a problem, don't say it will. If it doesn't, it reflects badly on your ability to troubleshoot. Just because Microsoft or Novell says that a particular update is the answer, doesn't always mean it will work-- or that it won't cause another issue that might prevent you from using it. In such instances explain to your customer that "Microsoft claims this will fix the problem". If it doesn't, it reflects badly on Microsoft-- not your own ability.

If you're unsure as to whether or not a certain patch or fix is the answer, but want to try it anyway, explain it that way. Have a sound understanding and reasoning behind why you believe this approach should work, as opposed to just having a "hunch". Be prepared to explain your reasoning-- you might be asked to do so!

#7: If You Can't Help, Focus on Prevention

Maybe you don't have enough data to identify the problem, or you did your best but there's simply no way to recover that file. It happens! Empathize. Apologize. Say you're sorry that there's not more you can do to help. It will remove the desire to place "blame", or at least divert such blame from you to the computer system.

If you can, try to leave the user with some helpful advice to perhaps prevent such things from happening next time. In the case of data loss, as much as it might be looked upon as hindsight for that particular situation, humbly suggest that "next time, it might not be a bad idea to save your work more frequently".

In the case of not being able to isolate a particular problem, provide the user with information or instructions that might help to isolate the problem in the future.

#6: Work with the User, Not Against Them

When meeting a user for the first time, take a few moments to introduce yourself. Describe the approach you had planned to take to diagnose and resolve their issue. Rather than simply "solve their problem", it is important to demonstrate your ability to reason and effectively troubleshoot. Through this, the user will become confident in and trust your ability, which will in turn provide you greater freedom in future interactions.

Allow the user to control the mouse and keyboard to save his work and close his applications before handing off control to you, if required. This way if something should go wrong with those previously open files, it will remove the desire to place blame on your actions. Also, letting the user be as much a part of the solution as they desire will foster that you're "on their side" and "here to help"-- not some techno-geek come to make them feel worthless because they need computer assistance. NEVER be confrontational.

#5: Be Honest

If you don't know the answer to a question, don't pretend to. You aren't necessarily expected to know everything about everything. Of course, saying "that is outside the realm of my particular expertise, but I can look into it for you" might be better received than a simple "I don't know"-- the former at least demonstrates a definite focus and direction.

#4: Be Wary of the Political Ramifications of Your Opinion

As a professional, know that your opinion has value. Realizing that your "informal" opinion can easily become fuel to a department's own political agenda is half the battle. Don't feel pressured to arrive at a certain conclusion, simply because a user is leading you in that direction.

I haven't yet met a user who wouldn't like to see his computer problems go away through the purchase of a new computer system. Nonetheless, a bad memory chip shouldn't ever warrant the abandonment of an otherwise good system, for example.

Until you know the cause of a user's computer problem, it's perhaps best to politely avoid questions concerning your diagnosis. User questions like "Is my computer bad?" are entirely loaded and can easily come back to haunt you when your Manager receives a requisition for a new one.

#3: Be Friendly

There is absolutely nothing wrong with getting to know the user you're servicing, while performing a diagnosis or repair. Asking "What do you do" is a good start, followed by comments on posters or items one might see in the office or cubicle. This will help you to understand the personality of who you're working with, and also demonstrates that like them, you're a person with interests, likes, and dislikes too.

#2: Take Ownership

Treat the user's concerns and data as if they were your own. Keep the appointments you make. Leave your direct extension and pager number, in addition to your team's extension or the "Support Hotline" number. In the event of an ongoing issue, put together a plan of action and keep the user apprised of developments, as they occur.

These all demonstrate that the user's inability to accomplish their required business tasks is important to you, and whether the solution to their problem is simple or complex, you're in it for the long haul and are willing to be there, no matter what it takes.

In an environment where support is divided among teams with varying responsibilities, don't simply "hand off" the user to a new team without first describing the process. Explain that while your expertise is in this area, another team might be better suited to address this particular concern.

#1: Know When to Give Up

If you've spent more than 15 minutes working to diagnose a problem, ask the user if this is a convenient time to continue. It's very easy for several hours to pass through minutes of "just trying one more thing". Perhaps it would be better to schedule a date when the user is out of the office. Alternatively, if the problem is critical, ask if the equipment can be taken to your own lab area to be diagnosed.

Whether the user takes you up on this or not, giving them the choice again only serves to demonstrate your desire and willingness to help-- which ultimately, is exactly what you're there for.


About the Writer:

Thomas S. Wolfe is a 15 year veteran of the technology industry who has served as a technology consultant for both Fortune 50 and Fortune 500 firms, and as the owner and executive manager of a technology consulting firm / outsourced solution provider. He may be reached care of www.networkstech.net

© 1998 Thomas S. Wolfe - Used by ASP with Permission - All Other Rights Reserved