Slashdot Mirror
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:
- 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.
- 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. - 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.
If your helpdesk doesn't consistently use a good ticket system -- like RequestTracker, plug, plug -- then it doesn't matter even if they always answer every question accurately and immediately: they can't prove it. Using a ticket system will focus the helpdesk's attention on solving and documenting the problem. It's much easier to complain that you're overworked when you have the stats to prove it; it's much easier to tell your boss that the bozo in Marketing has already asked that dumb question six times -- and has received the correct answer -- when you can show the ticket history as proof. And if the helpdesk isn't doing well, having them document what they are doing will let a reasonable person figure out what they need to change.
"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."
Apply serious penalties for anyone who bypasses the system. Management has to be on board for it to work, but if the sales department keeps using developers for low-level support, either charge them for the time or alter the deadlines. It sounds unreasonable, but that's the only way to make changes stick.
Have the developers track their work, including "helpdesk" duties. Once you can show that how their time is being (ab)used, it's easier to get management interested. (I was in a similar situation, and once my manager saw that 30-50% of my time was spent doing helpdesk work instead of coding, things started to change.)
One thing to remember is that developers will always be in the support loop. They may not be Level-1 support, but serious or techinically-involved problems are best solved by the developers.
"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."
The helpdesk should have a rapport with technical services and developers. The helpdesk staff shouldn't need to know detailed information, but enough to pass along to workers. Senior helpdesk staff should be trained in the more advanced applications (including the in-house and production apps!) so that they can act as level 2 support.
You'll also need to work up something (training or a script) to extract information from end-users. Many users don't understand the difference between their computer hardware, OS, application, network and server. When something breaks, users may incorrectly diagnose the problem.
"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."
Get some kind of tracking system, so problems can be entered, categorized, and used for training future helpdesk hires. Review the problems for the previous week/month, and see what can be done to improve productivity. If you find many of the calls are about basic Word or Excel functionality (for example), hiring a teacher for a one-day group class may be cheaper than interrupting a developer or having the person wait for helpdesk support.