What your help desk needs to do, Part 1

In this first of two posts, Jay Rollins addresses some steps in setting up your help desk software so that you can begin to leverage the system to begin to reverse the "Help Desk as a cost center" perception.

In this first of two posts, Jay Rollins addresses some steps in setting up your help desk software so that you can begin to leverage the system to begin to reverse the "Help Desk as a cost center" perception.


Based upon a comment I received last week on this blog, I started looking into the various help desk systems out there and found hundreds of them. My personal experience was with two products, one I wrote myself in ASP using MS Access and Remedy Magic Help Desk. Obviously, the one that met my needs the best was the one I wrote. Regardless, there are some key things to look for and some definite things to avoid.

First, it's important to map out the desired flow of trouble tickets. For me, the desired input goes as follows:

  • Best: User inputs issue via a web form. Basically, they have already logged in to the network and should be carrying around user credentials within their session. This ensures that the user's assets are associated with them and the opportunity exists for the user to review knowledge base articles before actually submitting the trouble ticket. Additionally, you can require more information via required fields to be captured.
  • OK: User sends an email. You still have the link to the user's assets, but you forego capturing detailed information about the problem. The free form allows users to say "the network is down" instead of "user cannot access a particular website."
  • Avoid where possible: Phone call. This is the most inefficient, but necessary. If the user's problem is so severe that they can't get on the computer, they obviously need a different way to contact the help desk. But you need to dissuade users from using this channel as the primary channel. Using the phone promotes reacting.

We have now defined the inputs. Next we define the work in progress (WIP). The focus of the WIP is to facilitate expectation setting for the users. Performing significant expectation setting while a trouble ticket is being worked on avoids time consuming follow-up calls or emails. This is accomplished by allowing the help desk person to update tickets at regular intervals and tie them to service level agreements. Here's a sample WIP flow:

The ticket is entered into the web form and, based upon the nature of the issue, the user is asked to review the knowledge base. If a knowledge base article does not exist, then the ticket is entered into the system. E-mail is generated for the user with a link to a status webpage where the user should go to see updates to the ticket.

Then various status updates occur:

  • Ticket has been assigned to Billy Bob (1:00 p.m.)
  • Ticket has been given priority 3 where priority 3 is defined as "Issue is serious, but isolated to a single user and is not prohibiting the user from performing other tasks. Issue is preventing user from meeting a critical deadline" Note the language communicates a sense of urgency that would not be understood if only a status of "Priority 3" is given. (1:05 p.m.)
  • Billy Bob has one Priority 1 issue and two priority 3 issues in queue ahead of your issue. (1:05 p.m.)
  • This issue has 1:55 to be resolved by Billy Bob or it will be escalated to level 2 resources. (1:05 p.m.)
  • Your ticket is expected to be addressed within 0:45 based upon current trouble ticket volume. (1:05 p.m.)
  • Your ticket is the next issue to be addressed. (1:50 p.m.)
  • Billy Bob is now working on your issue and has 0:55 to satisfactorily complete the issue before it will be escalated to level 2 resources. (2:05 p.m.)
  • Billy Bob: "The issue is related to a software version issue that prevented the user from opening an Excel Spreadsheet attached to an email that was created in a newer version of Excel. I remotely installed an Excel viewer on the user's computer an issue has been closed." (2:35 p.m.) Basically, some sort of update needs to be entered every hour of the life of the ticket. It could be automatic (i.e. there are still 2 tickets ahead of your issue for Billy Bob to address)
  • User is asked to agree that the issue has been satisfactorily closed. (3:00 p.m.)

So there is the level of detail required. Additional steps will need to be performed based upon the nature of the issue. A trouble ticket can be converted to a work ticket. Work tickets are things like "a new PC is needed and will take four days to order and install" or "a firewall setting needs to be updated during the next network maintenance cycle." Basically a work ticket is generated to schedule some sort of field services work. Metrics surrounding Service Level Agreements (SLA) are associated with trouble tickets and not work tickets. Issues need to be addressed in a certain amount of time or they get escalated. The metrics on how many trouble tickets get escalated or miss SLA's go toward staff planning and augmentation needs.

Additional detail will be needed when a ticket is escalated. Examples would be when a network or systems administrator needs to get involved because of administration duties. Finally, as the SLA's begin to expire, the user's manager and the CIO get ticket notifications/escalations. When that happens, issues will be changing priority automatically so they will be addressed.

Finally an e-mail is sent to the user confirming that the issue has been closed

Now that the flow is understood, in the next post we can focus on the features that are needed.

Editor's Picks