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!


Support! Support! My Kingdom for Support!


Paul Chin
(post@paulchinonline.com)

1/18/2006

Go to page: 1 2 

Printer Friendly Version

Taking a Structured Approach

The size of a help desk varies depending on the size of the organization, its IT infrastructure and systems, and its user base. Large organizations typically have multiple levels of support: first-level support staff to run the help desk phones (or chat/IM lines) and to solve basic problems; and a specialized second-level support staff to handle field calls and more complicated problems. Help desk managers might assign specific systems and disciplines to these level-two specialists so no single technician will be overtaxed

This is an ideal solution for multi-departmental systems such as intranets, since the help desk acts as a buffer between the users and all the various intranet team members. Rather than forcing users to call different people for different problems (sometimes they won't even know who the right person to call is), a centralized help desk can act as a triage station and direct all incoming requests to the appropriate people.

The help desk can be trained to handle the most common intranet problems so that intranet developers aren't bogged down by numerous minor problems. If the help desk is unable to handle the request, they can contact one of the intranet team members and follow-through with the user, or the intranet team member can contact the user directly.

Below is an example of an internal, corporate help desk structure:

Help Desk Structure

  1. A user has a problem with a system and calls the the help desk (staffed with first-level support technicians).

  2. The first-level support technician generates a service ticket containing details of the user making the request and the problem they're experiencing using help desk software such as HelpSTAR, Remedy, or ServiceCenter (these tools are used to manage user requests, prioritize service calls, coordinate personnel assignments, and generate service tickets).

  3. The first-level support technician will try to solve the problem with the user over the phone (or chat/IM line). This can be done by having the technician walk the user through several troubleshooting procedures or by taking control of the user's PC with remote-control software. The latter is very useful for organizations who need to support employees in satellite locations that don't have on-site support.

  4. If the first-level support technician is able to solve to problem on the spot, the service ticket is updated with the details of what was done. The service ticket is then closed; no more action is required.

  5. If the first-level support technician is unable to solve the problem or requires a technician to be dispatched to the user's location, the ticket is escalated to second-level support staff. At this point — depending on the structure and software employed by the help desk — a triage or queue manager usually assigns service tickets (based on priority and severity of the problem) to specialized second-level technicians who are more familiar with the system in question.

  6. The second-level technician will try to solve the problem with the user over the telephone, by making a field call, or by using remote-control software.

  7. If the problem is solved, the ticket is updated and closed. If not, the second-level technician will either see it through to completion or send it back to the queue for reassignment to another technician.

Cardinal Help Desk Rules
Be natural: Too many technical support personnel try to act like they're air traffic controllers landing a fleet of airplanes. They do this most likely to sound more official, but users respond much better to friendliness than formality. Dealing with users on a casual, yet still professional, manner will get a much better response.

Be prompt and efficient: Try to solve all problems in an expeditious manner. If users have to wait a long time to have a problem solved, they will think they're being ignored and lose faith in the help desk. If there's a high volume of requests, inform users of their position in the queue so that they will know approximately how long they have to wait.

Follow through: Whenever possible, the same technician should see a problem through to resolution. If the original technician assigned to a problem needs to ask for help from another technician, they should do so behind-the-scenes so that users will always be in contact with the same technician.

Closing Thoughts

Regardless of the support structure and technology used to manage calls and requests, it's still basically one person trying to help out another. Help desk managers need to make sure that a high-tech help desk isn't marred by technicians with poor interpersonal skills and unpleasant demeanors. While poor commercial customer service reflects negatively on the product (since support is increasingly seen as part of the product), poor system support in a corporate environment reflects on the quality of the staff providing that support.

Inadequate user support can end up becoming a catalyst for system failure, affecting the longevity of the systems the help desk is meant to support. When a help desk becomes a millstone for users, they will eventually stop calling (based on their own negative experiences or word-of-mouth from other users). Minor system problems will then accumulate and snowball. When this happens, the system will no longer be in the hands of the help desk to fix; it will need to be sent back to the developers — and then it won't be the users who are putting their heads through a monitor.

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
  • Supporting Key Business Decisions: Do You Make the Grade?
  • Intranet Security Begins with Education
  • from JupiterWeb
  • Why Enterprise Software Rollouts Fail (Datamation)
  • from the Web
  • HelpSTAR
  • Remedy
  • ServiceCenter
  • 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