Welcome to Jimmo.com
  Login or Register
::  Home  ::  Downloads  ::  Your Account  ::  Forums  ::
· Home
· Authors and Articles
· Content
· Downloads
· Feedback
· Groups
· Journal
· Private Messages
· Recommend Us
· Search
· Statistics
· Stories Archive
· Submit News
· Surveys
· Top 10
· Topics
· Web Links
· Your Account
Who's Online
There are currently, 8 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here
Select Interface Language:

Click here for Masthead/Impressum

Help Desk Models - Choosing the Right Model

In their book The Art of Software Support, Francois Tourniaire and Richard Jarrell speak of two kinds of help desk models: front-line/back-line (FL/BL) and touch-n-hold (TH). Although they may be referred to by different names in different texts, these are perhaps the most common terms and are very straightforward in describing what they mean.

With the FL/BL model, your support organization is broken into two groups. As you might guess from its name, the front line refers to those support analysts that are in direct contact with the customers and are the first to get the problems. When they cannot solve the problem, it is passed on the back line. With the TH model, the analyst who first receives the call will hang onto it until it is resolved. That is, you touch the problem and you hold it until resolution.

The structure that you choose for your help desk will be decided by which approach you’re going to take to manage calls initially (i.e., when they are first received). There are two philosophies here: dispatch and resolve. The first approach, dispatch, is where incoming calls are dispatched to the correct place. When receiving a call to the help desk, the task of the first person who gets the call is to "dispatch" it. This could mean assigning the call to a particular queue or checking the customer’s information to make sure it is accurate or to make sure they have a valid support contract (assuming support is fee based). If they don’t, you could send them to customer service to get a new contract. With a result- or resolution-oriented model, the first person to get the call will also attempt to resolve the problem.

The primary advantage of a dispatch-oriented system is that the customer gets to talk to someone, usually within a relatively short time. However, this says nothing about how long it will take before they can talk to someone who will actually start to solve their problem and doesn't say anything about how long it will take to resolve the problem. That is, the time to resolution usually goes up.

On the other hand, it is generally easier for the dispatch to decide which queue is most appropriate (assuming you have a situation where different analysts solve different kinds of problems). It is very frustrating to the customer to wait on hold only to discover the person he eventually gets to talk to is not the right one to solve his problem.

Another major problem with a purely dispatch model is that the customer will often need to describe the problem more than once. Because the dispatch staff probably does not have the technical training to solve the problems, they might not even have the technical training or knowledge to even understand it. If the dispatcher is expected to write a brief description about the problem into a help desk/problem database, what comes out may not even be understandable to the analyst. The dispatcher does his or her best to write a description, but often the words are unfamiliar, so they will write what they "think" the other person said. The result is that once the customer talks with the analyst, he or she will probably need to repeat the description of the problem. This can waste time and annoy customers.

Another problem that the dispatch model creates is that customers soon learn that the dispatchers do not solve their problem and try to figure out ways to get around the system. The customer usually knows the first and last name of the analyst (particularly if they ask) and call back and ask for this person directly. If your company or organization allows incoming calls to people on the help desk, all the customers need to say is that they are a "friend" of the analyst they wish to speak to. While working in support, I received numerous calls from customers who got to me directly, claiming they were friends.

This problem can continue after you switch from the dispatch model, because the customer does not want to wait in a queue. If the analyst has a phone shift, the customer could hang up before they get to your voice mail. If you are not on the phones, people normally answer the call only to find it is a customer.

The resolution method is a system in which the first person to get the call will try to solve the problem. How long that person spends trying to solve the problem and what their technical expertise is differ dramatically from company to company. In many cases, they have just a rudimentary knowledge of the product and are there to deal with the very basic calls.

On the other hand, I have worked in companies where a large number of the analysts were scheduled for calls on the front line. The length of the call was limited to 5–10 minutes, after which the customer was either passed to a different engineer who would spend more time or schedule a callback (e.g., if the customer was instructed to do certain tests).

What I see as becoming more and more common in the help desk industry is a help desk model where the first analyst to get the call essentially has no time limit and will work on the call until it is resolved. If your product or the level of calls are generally very simple, this method as a very high level of customer satisfaction. The problem is the more-complicated problems where it might take hours to find a resolution. Analysts should therefore know when they are not making any progress, so that the call may be passed to a more-experienced analyst or even that they should take a break and approach the problem with a fresh mind later.

The two main advantages of the resolution-oriented approach is that the easy calls are solved on first contact, and other calls are still worked on by the analyst beginning with the first call. That means the first contact is used for problem resolution, not for administrative functions.

I would only suggest employing a dispatch-oriented model when the majority of your calls are either extremely simple or not technical at all. For example, many organizations have their hotline under the heading of "customer service." They handle the whole spectrum of calls from complaints to warranty calls to technical questions on how the product works. Complaints and warranty issues are not technical issues and generally require less training to solve. Your customer service staff can quickly sort out the calls.

There are certain modifications of each model, but the general structure stays the same. For example, I have worked as a support analyst in an organizations that used the FL/BL model. However, there were actually three levels (not counting the engineering department and other companies). Analysts working on the actual front line that dealt with the customer were expected to solve or pass the problem within 15 minutes. This resulted in quick turnover for the easy problems and also gave the back-liners a head start in working on the problem (provided the problem and the attempted solutions were documented correctly). The model was still resolution oriented, with each level providing more in-depth support than the previous one.

I have also worked as a support analyst in an organization that had a mixture of the FL/BL and TH models. The people who first answered the phones were the customer service representatives, who were given a certain amount of technical training. They would screen the calls to determine those calls that they could solve as well as those that specifically needed a patch, upgrade, and so forth. Normally they could determine this within the first couple of minutes. If not, or they determined the call actually did need a "real" analyst, the call would be passed along. Once the next person got a call, it was theirs to keep.

Copyright © by Jimmo.com All Rights Reserved.

Published on: 0000-00-00 (9593 reads)

[ Go Back ]

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2005 by me.

Distributed by Raven PHP Scripts
PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 1.99 Seconds

:: Chronicles phpbb2 style by Jakob Persson :: PHP-Nuke theme by www.nukemods.com ::