Improving Your Help Desk?

mtbowen asks: "Our help desk is pretty much a joke. Most people don't bother calling them, they go straight to the developers or whomever they think can actually help them. I am trying to work with the manager of the Help Desk group and give him some ideas of how to improve in some key areas. I would like some opinions on my approach, as well as any comments you feel pertinent to the situation." What kind of processes would you start, in the hopes of improving a Help Desk that isn't providing much help?

"The problems as I seem them are:

1. Credibility - Until the users see them as useful, they aren't. Once there is some confidence that they are competent and helpful, users will stop bypassing them and developers will stop letting users bypass them.
2. Poor Processes - The help desk is supposed to be able to field most basic calls. They should answer all calls related to basic program functionality and system availability. They should know how to bold and underline, change email settings and know whether or not the web server is having problems. This requires cooperation from other groups, and I think everyone is willing to help IF there is a legitimate attempt at improvement.
   
   What would be wrong with using some sort of decision tree (electronic or hardcopy) that walks the Help Desk person through the process of gathering information, determining the problem, and either answering the question or forwarding on tot he appropriate party? They have some sort of knowledge base, but either it is poorly maintained or it is not easy to sue because they don't use it.
   
   I really like the idea of a decision tree type process that could guide them through a trouble call. It would also help new employees become effective faster since the basics are laid out for them. I know this will not catch everything, but it should help answer a lot of the basic questions as well as gather enough information that whomever the call is passed to (also determined by the tree) will have all they need to begin working on the problem.
3. Poor Follow Up - In my experience, follow up is crucial in determining effectives of any service. I think they should implement some sort of follow up procedure to track overall effectiveness and user satisfaction.

Anyone have any other thoughts on how to attack the problem of a help desk that doesn't? Any books, articles, software, etc. would be appreciated."

Comments

Improve communication between techs and helpdesk

[SpaFF]

The biggest problem we have where I work is that there is a huge communication gap between the helpdesk people and the techs/developers. The sysadmins will change something that impacts users and the helpdesk people won't know a thing about it. The reverse is also true, i.e. the helpdesk people will get calls about something that only someone with higher privileges can fix and they won't forward the problem along.

To fix this I think you would have to either have an intermediary, someone who works as a tech but also does some work with the helpdesk people on a regular basis, or set up frequent meetings between helpdesk people and sysadmins/coders.

Read Limoncelli and Hogan

[TilJ]

Get a copy of _The Practice of System and Network Administration_ by Thomas A. Limoncelli and Christine Hogan. Read chapter 15 (Help Desks) and implement it faithfully. For real-world system and network administration topics, this is the best book I've run across. There's a FreshMeat review available.

There's also a website at www.sysadminfocus.com, but get a dead-tree copy as there's not much on the website.

Then, get involved in SAGE and USENIX. These are common problems, and talking about them with a body of folks who know how to solve them is going to much more productive than posting to Slashdot ;-)

You've pretty much answered your own questions.

[DuckDuckBOOM!]

Credibility

Users don't see the help desk as competent and helpful. Fine: train, equip, and motivate them until they are competent and helpful. An earlier poster hit it right on the head: he doesn't use the help desk because (paraphrasing) "they know less about the product than I do." Until that situation is turned around (to a degree that makes it obvious to everyone that it has turned around), they'll keep right on going to the people who do know; e.g. the developers. Can you blame them?

Poor Processes. . .they should know how to bold and underline, change email settings and know whether or not the web server is having problems. This requires cooperation from other groups...

Why? What's the problem with giving support people the ability to tweak mail settings, and setting up simple is-alive monitors to let them see at a glance if a server or whatever is up/down? Routine maintenance matters e.g. password resets can be made simple and secure enough (via scripts or such) for CS technicians to use safely with nominal training. These have been BIG win-wins for help desk / tech support / customers on the two occasions I've helped implement them.

What would be wrong with using some sort of decision tree. . .They have some sort of knowledge base, but either it is poorly maintained or it is not easy to sue because they don't use it.

Nothing whatsoever is wrong with this approach; that's why just about every help-desk operation of any real size uses both. From your description of the situation, I'd estimate that (1) you're using the wrong software, and/or (2) the chicken/egg syndrome - they don't use the KB because it isn't well-populated, and it isn't well-populated because they don't use it. You should be able to find decent integrated call-center / knowledge-base software within your co's budget; that should take care of the ease-of-use and KB population problem. Put the decision trees on keyword-searchable HTML pages for ease of retrieval & maintenance; the higher-end call center systems have this integrated in.
N.B.: Decision trees are NOT a substitute for operators' knowledge & experience - having to deal with CC ops that mindlessly walk the tree from "Is the computer plugged in?" for every call will quickly send non-novice callers scurrying back to the developers.

Poor Follow Up. . .I think they should implement some sort of follow up procedure to track overall effectiveness and user satisfaction.

And to make sure that incidents don't fall through the cracks. And to track the effectiveness of improvements to the CC process. You're right. Any decent CC application will track calls through follow-up, and the better ones will auto-escalate aged calls and/or flag them for mgmt. action.

You have the right idea; all you need to do now is gain mgmt support, then act.

Oh, and here's one thing not to do: Put policy / procedures in place arbitrarily compelling users to go to the help desk. If the help desk's act hasn't been thoroughly cleaned up it won't work, and if it has, busy developers will start pushing users that way on their own. And you'll spare yourselves a great deal of grief from users, and their management, and your management.

Ownership, leadership, motivation

[somekindofuniguy]

I've been involved in this sort of thing before, and have identified 3 key areas you probably need to at least look at. I've seen tremendous success with this kind of thing - I remember a helpdesk analyst getting an outstanding achievement award for fixing 68 faults in one day. Six months later (after these things had been looked at), the same analyst was awarded again - for 142 faults resolved in one day.

1) Ownership: There should be a single point of contact for all faults - the helpdesk. Each phone jockey should take a call, and whether or not they can resolve it, be responsible for calling the dev/sysadmin, and chasing them until it is done. This is transperant to the customer/user - and they know to call and ask for "Mike" (or whoever) regarding the incident they logged. This almost invariably results in a *huge* perception boost.
2) Leadership: Your managers/team leaders/shift supervisors need to be on the ball. They need to make sure work is distributed evenly, and, as a couple of people have mentioned, ensure that everyone has something to do that *doesn't* involve being on the phone - even if it's as simple as typing up some documentation. A well deserved break will improve morale (and, consequently, productivity) drastically. The guys on top also need to not be afraid to chip in now and then. Staff will be more inclined to follow a leader who helps them out in the tough times.
3) Motivation: Perhaps most important of all, the phone jockeys need to feel like they are going somewhere with this. Spending years of your life knowing that you will either be on the phone, or soon be on the phone, is disheartening. Allow staff to be promoted to engineering, admin, dev, whatever their interest is.
In short, happy, productive staff with clear objectives with boost the image and effectiveness of helpdesk immensely.

Re:Some stuff

[slaker]

I've done "level 3" support a few times (level 3 on a scale of "reads off the screen", "clueful about basic stuff" and "the guy who actually fixes things") in various Windows/NT/Netware environments.

1. Most successful helpdesk I ever worked on, hands down, was run by a woman who used to be a phone sex operator. She had a normal "professional" voice and a "get a rise out of a corpse" voice. It was utterly AMAZING how much of an impact that voice had on our helpdesk satistaction reports, even though the field techs never got any better in the time I was there.

Just the other side of the "don't just hire girls" thing.

2. Proper procedure? Well, for crissakes, don't do a goddamn thing on paper. Nothing. Make a database. Use a text file. Something. Miscommunicated problems are going to happen, but papers detailing previous visits etc. get lost, and anyone who has been through the fun of "Oh, I just explained this to the other technician yesterday", or even the "What's your name and phone number?" will appreciate your helpdesk types actually having this information. Make folks enter the information for anything more than a 1-step call (eg "reset password") into some kind of online system that EVERYONE can look at. Fire the people who don't use it, or don't use it properly.
The other side of this is, don't make support run around your trouble-tracking system. Nothing sounds worse to your users than "I hafta go open a support ticket before I can fix your solitaire icon." I've been in organizations (*cough*ABC*cough*) that's the case. An ideal would be a tracking system that can be accessed from deskside.
Don't use your electronic system as a basis for tracking costs. Find some other way to do it. Invariably, stuff won't make it in the database, and for the low-level helpdesk guys, stuff like "target call lengths" just breed complacency.

3. Store user data off the local machines. Not necessarily someplace where it gets backed up every night, but someone who can access all their stuff from the PC in the next cube is going to complain less than the guy who has EVERYTHING on his "C:" drive. This is an administrative issue. Hopefully you have clueful admins.

4. Use .MSI and .ZAP-based installers for Windows software, and install stuff from network shares. Packaged installers are a lot easier to fix than the old fashioned kind. If you're REALLY good, append your install apps to some kind of a log, so that user apps can be restored quickly by the helpdesk guys. No more "But I also had Lotus Notes on my old PC!"

5. Make sure your field/deskside guys actually know how to do things. Man, there's nothing worse than finding out the dumbass you hired for desktop support doesn't know anything about DHCP or Outlook profiles or whatever. At a minimum, the guy you send deskside needs to have some knowledge of IP networking, your client-side standard software including the OS (most particularly the email client!) and the ability to speak (English) well enough to be understood by a native. Your deskside guy should be carrying a "gold disk" or two with common images, and should have some semblance of an understanding of how to find things on your network (like the share where you're keeping your apps). In a perfect world, he'd know how to use google, too.

6. Standardise your clients! Not a helpdesk thing (talk to your CIO), but it's a lot easier to support 3 client configs, one office suite and one email package, running on one OS, than it is to do 20 different types of PCs, three different office suites, four email systems and every OS microsoft has shat forth. Get a copy of GHOST or a similar program and take advantage of the similarities between your machines.

6a. Gold disks are our very best friends, but only if we've already taken the step of moving client data off the client PC.

7. Set standards of professionalism among your team. Best helpdesk I ever worked on, the standards were simple: No eating or drinking when outside our "helpdesk" area. No drinking while on the phone. Don't sit out in the client area if you aren't working on something. Keep swearing to a minimum (harder than I thought it would be!). Take EVERYTHING with you when you leave a desk or work area. We found that our customers didn't mind dress much - desks get crawled under, dusty printers had to be moved, etc, as long as there was at least a nod to business clothing... which translated into "wear something besides a tshirt. Tuck it in. Wear pants, not shorts, skirts or coulots. Every little bit helped.

8. Don't let the deskside guys spend too long with a single client. Have 'em report in to (whoever) after, say, 30 minutes on a ticket. If a guy is floundering trying to fix something, it should either be escalated to someone with a clue or the machine should be "refreshed" (gold disk or new hardware put into place).

9. Candy and a means of feedback. Don't laugh. Someone's day was interrupted. Leave them a little something for their trouble. Halloween-size bags of M&Ms might be a shameless ploy, but the guy who had to find something else to do for a half-hour while you fixed his PC deserves something for his time. Means of feedback? Well, electronic, since paper doesn't do anyone any good. Have someone senior do spot-checks on your tickets (i.e. contact the user), say, two days after the ticket is resolved, or one day into any open ticke and two days thereafter.

10. Have a means of dealing with assholes. Helpdesk guys are often contractors. "Real" employees sometimes get shitty with them. Some helpdesk guys are assholes too. Either way, there needs to be a real means of resolution with real consequences. The day an employee at a fortune 100 company called me a "Fucker" for my not being able to magically turn his CD-ROM into a CD-RW drive, and he got fired for it, I was absolutely stunned. Neither helpdesk people nor customers are being paid to be abused.

Well, OK. That's probably enough crap from me.