Improving Operations in a Small Helpdesk System?

El Presidente asks: "I'm the department head of a small IT helpdesk in a not-quite-so-small business. The department's small in the sense that (a) there's only three people (including me), and (b) not only do we do helpdesk, but develop all the in-house systems, build our own servers, and more. We're supposed to log every helpdesk call that comes in (we've previously developed our own software for this), log notes on each call, and log the resolution. However, although I do set a good example by logging (most!) of my calls, the other two don't, even though I've asked them to do so numerous times. Although they do the job well, this is the one area that is letting the department down, and now management wants full stats on what we do every day, so obviously a full helpdesk log for each day would go a long way to prove what we do (or don't do). I don't want to come down on them with the Big Iron Fist (tm) and check up on them every few minutes, because I've got my own work to do. How can I actually get them to buy into logging calls, and not 'forget' or be 'too busy' to log things properly?"

Comments

Make the advantages obvious!

[angel_7th]

If you developed the logging software in-house, it was probably developed with some goal in mind. Either this goal was not of any use to your colleagues, or they don't see it yet.

I'd say: make sure logging calls is useful to them as well, or at least make it obvious how useful it is to the rest of the business in general. As long as it's just another burden on their daily work, you'll never get you colleagues to use the logging tool to its full extent without that iron fist...

Re:change their phones

[CaymanIslandCarpedie]

Another way to do this which has helped me tons, is to get away from using phones ;-) Our help desk would recieve requests via phone, email, IM, or just stoping by in person. Performance matrix weren't an issue, but just keeping track of all the tasks was a nightmare and I was too busy to be logging everything properly.

I just created a system instituted a policy so every request must be logged in an intranet help-desk application by the person making a request before it would be handled. Now there are nice logs of everything and users can even search previous requests to find the solutions for themselves.

Alternatively, you could face facts

[$RANDOMLUSER]

"Too busy" isn't an "excuse", it's the "truth". You and your guys are understaffed and overworked, running around like chickens with your heads cut off. Anything that decreases your productivity or slows you down is doomed to failure. Time sheets (whatever you call them) are a perfect example. "What did I do today?" Errrmm. "How about yesterday?" Ahhhh. "Last Tuesday?" Not a clue.

Hand out digital voice recorders to facilitate "taking notes". You can use them as you're dashing from one fire to the next. Give each guy two or three hours a week phone free, where the other two cover for him, and he can transcribe what he's been up to. Just enforce that. "Dave, you got nothing to do but write up your notes on Tuesdays after 2:00; but at 5:00, I expect to see what you've written up."

I've used casette recorders for many years doing big HP-UX/Solaris installs/upgrades. They don't slow you down at the time, but they help you remember for next time.

Auto-create trouble ticket upon phone call

[falzbro]

Two options.

1) If you are using analog phones, this likely will not apply to you

However, if you use VoIP based on something like Asterisk, you could force-open a trouble ticket when a call comes in to the support line. This way, they are forced to go in and close it, which should lead them to putting notes in it. You could further auto-assign the ticket to them if it went to their phone.

We currently do this when someone calls our on-call number- there's a big annoying ticket setting there awaiting resolution. Once this is working, set up some automated job to spit out a text listing of who has unclosed tickets, how long they've been open, etc. Have this list sent to all techs automatically.

We use RT for tickets, so creating new tickets in the appropriate queue can be done a few different ways. Sending an email to the account we have setup to create the tickets is the way

2) Incentives ($$)- bonuses and raises based on time/tickets/minutes logged. Nothing logged? No money for you.

--falz

Get the customers to log the calls

[Marcion]

I worked at a Helpdesk for what seemed an eternity (although I always enjoyed it).

Get the customers to log the calls. Save your staff's time for solving the problems and all the other fun things that you mentioned. A decent system, even the free open source ones, can guide the customer to give decent information (contact info, category of problem). You will find that these calls yield far better information than comes through email, so turn the email off. If a customer is not willing to write the call then it is obviously not a real problem.

If they ring then get the adviser to write the call while the customer is still on the phone, if the adviser explains what he is doing (explicitly, or implicitly - murmuring the field names), then the customers will learn.

Re:Two ideas

[martyb]

2) One way to increase logging numbers is by making certain simple helpdesk tasks self-logging. For example, when a client wants their password changed, it's tempting for the helpdesk consultant to just change the password without ever opening a ticket. Why not write the password change utility so that it automatically opens a ticket, provides some minimal level of notes, and then presents this to the consultant?

I'll second that suggestion and add another: make an API that facilitates logging and merge that into your workflow. NOTE: This is all off the top of my head. I expect you'll tailor it to your specific needs. Augment as needed and/or time permits.

I'm thinking along the lines of wrapper functions that implement:

1. StartTicket implement a small program whose sole task is to log the start of a ticket. Record: Date, Time, Caller, Technician, Severity, Short Description

   The date and time can be captured automatically from the system. Ditto for the tech. That leaves gathering who called which could also be captured automatically from the Caller-ID info from your phone system. That leaves the Severity (Urgent! Important. When-you-get-a-chance) and Short Description.

   Another comment suggested carrying around a small voice recorder. With the increasing availability of IVR systems, even these could be captured with a small front-end that the person calling the help desk goes through. If techs were only permitted to work on calls that come through such a system, then everything you need is already there. Log the incoming call's audio as a BLOB in an RDBMS, use some Speech Recognition on that to get a text-formatted problem ticket. Sure, it's not going to be 100% accurate translation, but for now it's good (enough) to go. Get the minimum up and running Right Now. You can enhance, later.

2. LogAnActivity Simply record a text or voice update to the current task. Along with the current date, time, and tech.
3. StopTicket Again, implement a small wrapper program which captures the information you need. Date, Time, resolution, followup required.
4. Write a TASK utility that uses these wrappers.
   1. invokes the StartTicket wrapper,
   2. opens a new shell / window,
   3. tech uses shell to perform requested action; all shell output is logged to a log file whose name is based on the tech's name and the current date time in ISO-8601 format. Take a look at Date (Unix) for details. Don't have a unix date command on your system? Take a look at the GNU utilities for Win32. So, now you can construct an easily sortable date/time stamp;

      export right_now = $(date "+%%Y%%m%%dT%%H%%M%%SZ")
      
      or, under windows:
      
      SET UnxUtils=C:\TOOLS\UNXUTILS\USR\LOCAL\WBIN
      
      COPY CON: right_now.bat
      %UnxUtils%\date "+SET right_now=%%Y%%m%%dT%%H%%M%%SZ" > %TEMP%\right_now2.bat
      CALL %TEMP%\right_now2.bat
      ^Z
      
      right_now
      
      I just ran it on my PC and got:
      
      right_now=20061226T175320Z

   4. tech closes the shell / window
   5. on shell close, invoke the LogAnActivity wrapper
   6. invoke the StopTicket wrapper.
5. Permeate your workflow Leverage these wrappers as a framework and as it becomes clear, write other TASK wrappers as needed.

You are pressed for time right now, so this is going to need to start lean and simple. Just capture enough info to show that you are way too busy. Get some wiggle room from management.

Other Approach Rigorously provide what they request in the way of documentation adn logging!!! If you are short-staffed, then LET THAT FACT BE KNOWN! TANSTAAFL. U