IT Policies

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.

12 comments
melanieellsworth
melanieellsworth

Perfect read for me since I'm writing a business case to implement new solution. Has anyone put together an ROI for this that might be willing to share or direct me to some great templates?

AMS-Ray
AMS-Ray

A great low-cost Help Desk solution is Sysaid (www.ilient.com). We've been using it for over 3 years in our small business. It has inventory, ticket tracking, automatic status updates by email, ticket creation works from either a web page submission or by sending an email to a special helpdesk account. They even have fairly frequent free updates.

epcs00
epcs00

I would switch the phone and email options. Email requests rarely contain enough information and almost always require follow-up. The phone call can possibly be resolved immediately or if not more detailed information about the issue can be gathered. Another proactive Help Desk practice is a way to notify users of major outages so they are seen as the user tries to submit the issue. Either a notice on the web form or a front end message on the phone system.

shawn
shawn

ITIL integrated solutions take the guess work out of configuring the help desks of old. However, many commercial systems are cumbersome or cost prohibitive to configure. Numara Footprints is probably my favorite system for medium to large enterprises given its ease of use and its configuration wizard, but c.suppAort at www.gwi.com is closing gap on an old favorite. C.support could prove to be an all around solution given its low price point and feature rich offering.

dgennello
dgennello

This is a great guide for anyone starting a helpdesk. We started a new helpdesk service for a Small Business client base about a year ago. Writing it from the ground up was not an option and Remedy was just too expensive. We found ServiceDesk Plus from Manage Engine. It has all the right features and is fully customizable and VERY cost effective.

jmgarvin
jmgarvin

Let me plug my company, FrontRange Solutions. They have an ITIL based product called ITSM. It is a very robust product made more robust by the ability to write jscript, use the BPML work flow engine to work with time based events, and it has modules like Enteo and Centennial for software rollout and discovery, respectively. If you are looking for ITIL helpdesk software, make sure to shop around though. Infra, BMC, CA, and Axios are also very good products.

Fairbs
Fairbs

I see multiple methods of contacting the Help Desk as a way to encourage prioritization on the part of the Customer. Priority 1 should be a phone call to say that the businesses core operations are down or a high priority system is down for multiple users. Priority 2 or higher don't have the same level of urgency and can wait. Taking a request / problem through an email or web form doesn't disclude excellent Customer service because you will most likely have contact with the Customer anyway. If you take all calls via phone, you become interrupt driven and are forgoing working on someone else's problem because you have to pick up the phone. Another point is that the goal of the automation be it data collection, automated updates, escalations, ... is to increase the amount of time you spend actually working the problem and getting that Customer back in business.

TU SIS
TU SIS

I have two problems with the heavy deprioritization of phone as a means of contacting the service desk: 1) It is the only option (aside from on-site deskside support) that provides human interaction. 2) Without clear communication to the user community, expectations of end users will not match IT focus. Regarding 1, too often IT tries to use technology to solve human problems. Why would you want to ask the end user who needs help with fonts to use a Web form? Instead use the opportunity to kill multiple birds with one stone, engage him or her in training or other opportunities, and create one of your biggest champions. Besides, unless your ratio of end users to analyst is over 300:1, a competent IT worker should be able to handle and excel at phone support. Regarding 2, there is no mention in this column that the order listed is also the one that has been shared with management and the user community. Failing this, people will wonder why their phone calls take 10-15 minutes to be answered, and point fingers at the Help Desk as incompetent and poorly managed. Assuming good communication, and that you have a very good, very intuitive Web form that people can reach from a shortcut on their desktop (please don't tell me to search the intranet), deprioritizing phone contact can work if you want it to. But given the opportunity of 1 above, why would you?

iandlee1964
iandlee1964

There are so many servicedesk systems out there! My preference is for Sitehelpdesk, again for it's ease of use, installation and configurability. The added WMI Monitor gives auto discovery and a good start to any CMDB.

Meesha
Meesha

I agree that the phone option should not be deprioritized. Primarily since we have built in "Live Assistant, Click to Chat, presence awareness, et al" directly into our front facing and back facing contact center solution. We feel that with technology today ANY form of communication is good for those seeking help. For example, some of our new users are still not comfortable with doing emails or texting on their Blackberries so they call. The software automatically turns that call into a service ticket waiting to be assigned by the call taker thereby reducing data entry fatigue and errors. All methods of communication should be used and provided for in the workflow of a contact center. When phones or emails go the way of the Dodo then that's when you look to only provide what's modern and relevant.

Editor's Picks