Intranet Journal   Earthweb  
Events Jobs Premium Services Media Kit Network Map E-mail Offers Vendor Solutions Webcasts

   Intranet Journal Subjects
Search Earthweb

Privacy Policy



internet.com
IT
Developer
Internet News
Small Business
Personal Technology

Search internet.com
Advertise
Corporate Info
Newsletters
Tech Jobs
E-mail Offers

internet commerce
Be a Commerce Partner
















 

[ Home | Discussion Forum | How Do I... | Lotus Notes Intranets | Microsoft SharePoint | Products | Shopping  ]

free news!


Dealing with Difficult Users (Help Desk, Part 3)


Paul Chin
(www.paulchinonline.com)

10/24/2006

Go to page: 1 2 

Printer Friendly Version

user -- and knowing how to keep a tense situation from getting worse -- can be the difference between resolving a problem and the user going ballistic.

  • Set boundaries and maintain control -- It's one thing to show diplomacy; it's another thing to allow users to treat HDAs as punching bags. If users become abusive -- shouting, using foul language, insulting the agent -- and HDAs sense that the interaction is slipping away, they must be able to maintain control of the conversation as well as their own emotions. HDAs can be firm but still diplomatic, telling the user, "I'm here to help you through your problem, but if you continue in this manner, I'm going to have to end this now and come back after you regain your composure. We're both professionals so lets start over from the beginning." This provides the user with a "do over" and a time out to reel in spur-of-the-moment reactions.

  • Don't talk like a robot -- The interaction between HDA and user isn't a state of the nation address. There's absolutely no reason to be overly formal. In fact, users' stress level can actually be reduced if the HDA speaks with them in a real human fashion rather than using overly formal business-speak. HDAs should humanize the interaction and, if appropriate, make small talk to lighten the atmosphere and remind a high-strung user that they're there to help.

  • Personalize the interaction -- Even though some problems have standard procedures, don't turn an HDA/user interaction into a cookie cutter script by simply reading off a list of steps. Speak with users like real people and use their names during the interaction.

  • Provide details -- If an HDA senses that a user is frustrated that the problem is taking too long to be resolved, tell them (briefly) what has been done and what the next steps are. This will help minimize the feeling of the HDA as the driver and the user as the helpless passenger. Taking the time to explain the situation to the user and making them a part of the process (even if only by perception) is much more effective than simply saying, "We're working on the problem."

  • Don't transfer the user too many times -- Nothing will frustrate stressed out users than constantly being transferred to other agents or departments. The initial HDA should try his or her best to see a user through a problem from beginning to end. If the HDA has to consult with another, more experienced, agent it should be done behind the scenes. They shouldn't simply hand off the user to another agent or department. HDAs should only do this if the problem is totally outside their area of expertise.

  • Become a "bartender" -- Users need someone not only to deal with the technical aspects of the problem, but also someone to empathize with their situation. A difficult situation can be diffused if an HDA just takes the time to relate with the stressed out user (see the first part in this series for more on this.)
  • To be continued...
    HDAs won't last long in a front line support department if they take every negative interaction with a user too personally. Remember that most users are in a heightened state of stress and their behavior is based on frustration. Don't mistake these moments of temporary insanity as personal attacks -- and most importantly don't take them home at the end of the day.

    In part 4 of this series, I'll be discussing the process of hiring the right people for the job.

    Paul Chin is an IT consultant and a freelance writer. Previously, Paul worked as an intranet and content management specialist in the aerospace and competitive intelligence industries.

    Go to page: 1 2 

    Printer Friendly Version


    Other Resources
    from Intranet Journal
  • Intranet Journal Discussion Forum
  • Let's Talk: Add domBulletin to your Intranet (Part 1)
  • XML Basics
  • Creating a PHP-Based Content Management System
  • from JupiterWeb

    email this page

    Tutorials
    and more at:
    Intranet Journal's Tutorials
    Intranet Journal Favorites

    Creating a PHP-Based Content Management System

    The Spyware Guide

    Introduction to Microsoft SharePoint Portal

    Intranet Journal
    Part of the EarthWeb Network

    Managing Editor
    Intranet Journal

    Tom Dunlap

    EarthWeb Home Page
    Jupitermedia Home Page

    Media Kit




    The Network for Technology Professionals

    Search:

    About Internet.com

    Legal Notices, Licensing, Permissions, Privacy Policy.
    Advertise | Newsletters | E-mail Offers