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

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.

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