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.

Re:Bring down the hammer.

[tacarat]

In more real terms, explain that raises and getting more people (essential for taking vacations) are based off of these reports. As mentioned earlier, you can also explain who the boss is. There are non-confrontational ways of doing it, and you should consider what you say carefully to avoid "hurt feelings" because they get defensive or puff up their pride.

Or you could link this article and point at them. "That's you".

Re:Bring down the hammer.

[silas_moeckel]

Funny run a small consulting company though a midsized company CTO and I would have to wonder if it makes sense to fire the hotshot. If they generate billable hours and the customers love them it sounds like they need an assistant to deal with paperwork drudgery. I would rather add on 30k of salary expense for a low end secretary to deal with time reporting than loose a top gun guy. Technical documentation is a different story as it's billable but can still be given to a jr person to do.

Re:Bring down the hammer.

[itwerx]

I know with Remedy help desk, a ticket will take 5 minutes...

That's more of a reflection on how badly Remedy sucks than anything else. :)

Re:Bring down the hammer.

[kjs3]

Frankly, this is utter rubbish. You've clearly never had P&L responsibility. I'm supposed to take 30k profit out (obviously much more with loaded costs) just because I've got someone who can't be bothered to account for their time? Right.

But hey...let's pretend that admin salaries are pixie dust and don't count against the bottom line.

The guy that won't produce required paperwork for his manager, per his job description, won't do it for "a low end secretary". All you're going to do is add "30k of salary expense" to get one frustrated, ineffective admin and one (or more) overly entitled "hotshot" you still can't accurately bill for. Been there, done that, hired the "time accounting admin", realized that was st00pid. Do you really think someone who won't do their own paperwork is going to suddenly provide an admin sufficient doco for the admin to do it accurately? That is, unless the admins job is to stand by the "hotshots" desk and record what they are doing...

It's not about time. Please...time reporting takes minutes or tens of minutes a day unless you're a lawyer and billing in 6 minute increments. It's about "I don't feel this is important, therefore I won't do it". Life got so much better when I realized that doing the job is about doing the whole job, not just the part someone wants to do, and started holding people accountable for the whole job.

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.

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...

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

Take charge

[sinij]

Seems like you have leadership problems, failure to log is only one symptom of much bigger problem. Good thing - you have an easy way out of it. Hire somebody you can trust, shortly after that hold a meeting on keeping notes, have new person use 'too busy' excuse and fire him on a spot for it.

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

Your softwqre is letting you down

[Gorm the DBA]

Find out why they aren't logging.

Do they not log because the system just gets in their way, adds no value (suggested fixes, workflow tracking) to the process, and takes too long? Then fix/replace the software.

Do they not log because 50% of their calls are quick hit 20 second resolutions and logging takes too long? Make it so they can log a call with nothing more than "password reset - extension 2710 - Complete" and move on.

Do they not log because they are so busy taking calls they don't have *time* to log? Then you need to implement a faster system, or staff up so that they aren't overworked.

Do they not log because they're lazy? Then you need to come down with the big hammer. But don't assume it's this, it's probably one of the others.

If management asks, you must deliver

[farker haiku]

Simply tell management that your current tools are not up to the job that they require. State to management in no uncertain terms that while you could write a program to document the calls, or come up with a way to do it that enhanced the performance of your team, you can't set aside additional time to do that and still stay on top of your work. State that it would take you x number of hours to develop the tool to track tickets at y$ per hour, where x*y>z (z being the cost of the ticketing system you want for your helpdesk). This is called stalling.

In the meantime, while management hems and haws about spending that much money, ask your helpdesk what they'd like to see in this ticketing software. Tell your analysts that they have a choice - help decide how ticketing is most beneficial to the department, or have no say so in the whole process and have to use a tool they don't like to justify their jobs to management. They have a third option: leave before or after training their replacement to use the software they don't want to use.

Look into the following while making the decision:
1. You want to be able to identify problem users. Train them, or point out in dollars and cents how much those users cost the company by the amount of calls they make to the helpdesk.
2. You want to be able to identify common problems, so that you can proactively fix them and reduce the call volume.
3. You want to be able to identify specific hardware that is failing in the environment. This means asset tracking. This might mean changing vendors.
4. You want to be able to identify which problems are taking the most time for your analysts. Proactively fix those.

Hope this helps.

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: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."