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

Bring down the hammer.

[PhxBlue]

How can I actually get them to buy into logging calls, and not 'forget' or be 'too busy' to log things properly?

There's a time to be a buddy, and there's a time to be a boss.

You put to them, in plain terms: They will log their calls or you will find people who can follow simple instructions. Yes, it's a Big Damn Hammer(TM), and they may resent you for it in the short term; but your ass is on the line to get your helpdesk in order the way the company expects you to run it.

Re:Bring down the hammer.

[TheWanderingHermit]

There's a time to be a buddy, and there's a time to be a boss.

This is an excellent point. I don't advocate dishonesty, but you could point out to them that they are asking you to justify your time and personnel, which is essentially what is going on here. Point out that you have to show your boss what is going on and prove that you need two people. Without their logs, you can show what you're doing, but not what they're doing. It's even possible they could eliminate one or both positions unless you have proof that they are both kept active and busy -- and that proof would be their logs. If there are no logs, you can't prove they're busy.

They will log their calls or you will find people who can follow simple instructions.

I'm willing to bet that was written by someone who has never run his own department or business. It would be nice if one could do that, but in the real world, if you've got an employee that does 90% of the job well, then you're damned lucky. Sure, you can fire them, but there's a good chance their replacement won't do as well as they do. Logging and documentation are two areas programmers, admins, and other IT people are notoriously poor in. People can claim to do that in an interview, but once someone else tells them he's never done it, they won't bother with it either.

It's hard to find good employees and you don't want to replace a 90% fit with an unknown that could be 90% bad.

Be straight with them

[Rastl]

Are they aware that the call logs are one of the few objective measures of productivity for your department?

If not, make them aware. Charts hanging on the wall will reinforce that a bit in the beginning.

You're always going to get the "I can either fix it or log it. Choose." kind of attitude. The answer is "You're going to do both."

However, there are some exceptions.

Is there actual value in the detailed logging? Is anyone going back to use the old resolutions or report on stuff? Perhaps the answer is a streamlined logging process that gets the basics you need without making your people jump through hoops.

So the question to me is whether you have a call tracking system (pure counts) or a problem tracking system (historical data, etc.) and what value you're getting out of the time spent.

Two ideas

[imidan]

Two things from my prior helpdesk experience:

1) Typically, the reason management wants statistics on helpdesk call volume is so they can make staffing decisions. I was not management at the time, but was at the same tier as helpdesk management when I was asked to compile statistics for average call volume by hour. Two weeks before Christmas, management cut helpdesk staffing hours by something on the order of 25%. We managed not to fire anyone, but they certainly weren't happy. After that, we saw a significant increase in calls logged. When the employees were faced with the real consequences of not demonstrating their workload, they decided that logging calls was a better alternative to not having jobs.

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? If you can make ticket tracking easier to do than to not do, people are more likely to do it. Don't make the logging process completely invisible to the consultant, though--the idea is to integrate these steps with their workflow so that they get used to doing them, not to hide them altogether. One presumes that for the more difficult problems, consultants are opening tickets, anyway.

Just two ideas.

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

Re:Take charge

[p!ssa]

Yes, good point, dont forget to nail a kitten to a board and strangle it in front of them too. Dont kill it, just let it pass out... and stangle it again after you poke it in the eyes with needles to wake it. Keep repeating this until one of the weaker employees cry (it may take a while or require multiple kittens if they are used to abusive callers), then lock the kitten in a dark box with no food or water, leave it close enough to thier work area that they can always hear the muffled crying. The key is to let them know there will be alot of pain but no death, morale and productivity will sky rocket. You will most likly get a bonus when the CxO's get news of your "Balanced Kitten Card (tm)" management methodology. The kitten will make for great holiday cards too, remind them again and again at easter etc., 1 kitten can go a long way. If that doesnt work, just shoot them in the face.

Best Regards & Happy Holidays,
Dick Cheney

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:change their phones

[citking]

I can't agree with this more.

I also run a small help desk (me & 5 students) that has a lot of turnover (can't keep the students forever) and very few overlapping shifts. What this means is that automation has become our friend. Help the users to create their own tickets and it'll save your staff a bunch of time.

We do this in several ways:

-E-mailing our help desk opens a ticket and fills in as much detail as it can from the e-mail address. It attempts an AD lookup as well if the domain is ours.

-Web forms. We have a couple of .asp scripts in place on our web server. One of these scripts is hooked into AD and sits on the Outlook Web Access login page. If someone needs help, their name/dept/phone/etc is all filled in for them and all they have to do is say what's not working. This keeps the person from having to fill in too much (which means they'll sometimes spend a bit more time on details rather than just saying "e-mail don't work."), it gives us accurate information, and it's conveniently located right below the login box!

-Calls are harder, of course, but I always ask my staff what ticket they are working on. If I get a blank look, they go back and go create a ticket, then resume work.

-Desk stop-bys. If possible I ask people in the offices to just create a ticket and we'll pick it up from there. If they e-mail me or a staff member directly, I'll open one for them if I have time, otherwise I ask them to do it.

-Voicemails are sent to us by our phone system as e-mails which, when sent to the desk, open their own ticket. So not only is the entire VM archived, but it is accessible even if it gets deleted or is purged from VM after 15 days. Plus we can send the VM ticket to others as necessary.

We use Numara Footprints for our system and I like it. It's pretty easy to use, customizable, and pretty expandable.

My final thought to all of this is to embrace automation. Anytime a computer or another person can make a ticket for you saves you a bit of time (excluding those with the "it doesn't work" phrase in the details).

Hope that helps!

"If you didn't log it, you didn't do it."

[The Monster]

You have a little chat with the guys in the department. You tell them that lawyers keep track of how much time they spend working on each client's cases. It's called 'billable hours'. An associate who doesn't produce them in sufficient quantity gets fired. It's just the way it is.

Blame it on the beancounters. "I need these stats to be able to justify our jobs. If I can't show the Guys in the Ties that I need both of you, they'll make me get rid of one. If it comes to that, we'll lose the one who logs the least hours working trouble tickets. It probably won't even be up to me at that point."

Every phone call or trip to an employee's cubicle is an 'event' or 'activity' that needs to be documented, even if just with a sentence fragment (Asked Jane to reboot her workstation and call back if further errors.). Make sure your system accounts for who you're supporting. When budget time comes, you might be able to show that the lusers in one department generate a disproportionate number of support calls, because they insist on being local admins with the power to install extra crap you haven't tested. Your fourth person's salary might come out of that department's budget.

But the big win will come when you can data-mine your system and find patterns. "That GPF is only showing up on workstations with Foo version 3.6 build 2405 using the Barf-o-matic 2010 video card with the xZyzzy chipset."