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.
Start out by defining the list of things the Helpdesk will help out with, like Reinstallation of Windows 95-Xp yes, Windows 3.1 no. Then the hardware Pentium133+ yes, 80386 no.
Then have knowledgeable staff. Test them once in a while and simply explain the steps to them. Dont forget to rotate em between taking calls and either answering emails or working on computers clients dropped off. Constantly being on the phone is extremely frustrating due to the hard rules of good helpdesk support. A rule of 1 or 2 hours stretch on the phone, then sent back is good.
Dont hire girls JUST because they have a nice voice. Dont discriminate on gender, age, race etc. This is because if you do, you might end up with a bunch of teenagers in the department fooling around. With enough difference between them, they'd be professional.
Now the rules. Dont make rediculous rules that might anger clients. In short, you should be able to print the rules on one sheet of paper to handout/post.
Hope this helps. Ive been part of a successful and highly-regarded Helpdesk Team, so the opinions spewed out.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
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.
A help desk SHOULD know how to bold and underline, but so should the users. The helpdesk is there to help with problems with PC hardware and configuration. They should not be there to teach you how to use word, or how to fax, or how to fix your excel spreadsheet. That is just ridiculous. A help desk should be designed with multiple tiers- the first line consisting of 7.00/hr high school students that can reroute questions like 'is the webserver down' and follow procedures to fix common problems like resetting printers, diagnosing where the problem is with the user's network connection (IE, software, hardware, or router problem). Then there should be the second tier guys who deal with things like the webserver being down, or the router melting down, or the tcp/ip settings of network printer 9E resetting themselves after a voltage spike. A system like that should work for any size org, although most larger ones tend to have a third tier... the 'oh shit' guys that really know their stuff. Above all, it is your hiring and training practices that need to be reviewed to make a helpless desk into a helpful desk. Users should be trained quickly that unless word is not starting, or it is mangling your documents upon opening them, to not call the help desk and bog them down w/ calls that make them want to hang themselves. Instead, they should bother their supervisors, who can then see the idiots that they are, and the cost of having them waste time due to basic inability to use software. Good hiring and training practices among both the users and techs will make all the difference.
What is this helpdesk for? It sounds like a product or service of some sort, so I must ask, why are you letting the developers handle support issues? I think your first problem is a major lack of responsibility and clear set roles for your developers and helpdesk people. Developers are not support, they develope. Helpdesk does support, that is their job. If a developer gets a support issue, they should automatically send it to the helpdesk unless it came from the helpdesk. I don't know about you, but if users refuse to follow support guidelines, they do not get any service.
As far as your helpdesk itself, having people who know what theyre doing is a major requirement, and training them for the responsibility is also needed. I'd make a formal system that logs support requests complete with filing dates and 'due dates' by which those requests must be handled. In tech support, using the standard queue system works well for the most part. First come, first serve; everyone gets served. Support requests should be centrally stored so everyone knows what is going on; no pieces of paper that once lost mean a support request is gone, thats sloppy. Id make sure the system tracked open and closed requests and draw a distinction between the two. Make sure your helpdesk knows the difference.
Quite frankly, a lot of this is fairly straight forward, and requires mostly setting up the right infrastructure to handle it. The keys are making sure your personell are properly trained, and that everyone has their own responsibilities. Forgetting about a support request or not being able to properly handle it is not acceptable. The problem might be the manager more than anything since I myself would not accept that level of slackness from my employees.
"What can a thoughtful man hope for mankind on Earth, given the experience of the past million years? Nothing." -Bokonon
I am certainly not all-knowing, but one of my biggest deterents to calling any help desk is that 9 times out of 10, they don't know any more than I do, and in some cases they no less. In setting up a help desk, determine who you are trying to cater to, and then make sure your attendants are more knowledgeable.
j.goforth
1. People - some people are simply better troubleshooters and problem-solvers than others. Attitude is a big part of the equation as well: if the helper doesn't care too much about the call, he'll end up providing shoddy service. People in support positions need to want to help to some degree or suffering will occur somewhere in the chain.
2. Processes - The help desk personnel need to know who to go to for what and in what circumstances. If this is unclear, start logging calls and the results of their handling. This gives you a baseline to examine for problem areas, and all kinds of things will be pointed to: the processes themselves, the people, attitudes, the product, etc.
3. Communication - Someone else pointed this out, and it's critical. When departments and their personnel don't know what's happening across the hall, it leaves a lot of cluelessness, and this will kill a help desk. What ends up suffering in the end is morale and therefore attitude, which comes across in such a high visibility department.
4. Know-how - Once the right people and processes are in place (which you'll know because proper communication gets it across), fill in holes in the knowledge of the help desk reps to reduce overhead in time spent per issue. This kind of training can come from inside or outside, and provides possible promotion material down the road.
So long, michael. Don't let the door hit you...
I worked for 3 years at a small company with the same problem. In their case, the problem wasn't the helpdesk, it was the software. I am assuming you are a custom software biz.
If the help desk is experiencing problems that only developers can assist with, the software is probably buggy, too hard to use, or too hard to support. Worse yet, if the developers are spending time doing support, the bugs aren't getting fixed.
Do you get daily calls like "Can you fix my whatsit files so they do the whoojimonger?" If so, I recommend that development code to prevent problems, and give users the chance to avoid/fix problems themselves, instead of adding new features. Maybe a rewrite is necessary.
Beyond that, the help desk should simply institute good processes. Log calls, and all that good stuff you already know. If you don't know it, there are books, courses, software, etc. that know this better than Slashdotters do.
Oh, and make sure there is no "hero." The hero is the one person who knows everything, and does all the work. They like solving problems, but don't have the time or inclination to pass knowledge on. Sometimes, they have to be let go, because despite their best efforts they are keeping the company from learning lessons.
If the "hero" is a developer, then get them off the helpdesk 100%, and let them fix the software so you don't get so many calls in the first place.
If support just shows users that problems have been recorded and routed to an actual person, and that that person has an estimate as to when the problem will be looked at, that will go a long way towards peaceful relations and improved operation.
The reason it's so hard is that help desk/it support is essentailly a customer service role, not totally (or often) a techincal one. But, you need technical people to solve the problems. As you all know, those types of people don't always have good communication skills let alone customer service skills.
Having a ticketing system and using it can help alleviate that, because it fits in with the tech. person's workflow (recieve problem, provide estimate, fix, notify of fix), and provides instant and easy communication via the system to the user needing help.
http://www.naildrivin5.com/davec
You also need a range of skills to draw on. Good help-desk people are almost as valuable and rare as good tech people, just a different skill set. Depending on the size of the organization (and therefore the help-desk), there should be a range of experience and processes in place to rotate people to expose them to more situation (i.e to gain experience), and more experienced people always available to help out. A lot of times, there is enough work load to have admins assigned to the help-desk to handle second tier problems directly (help-desk staff takes the call and dispatches to the correct on-desk or on-call person). Admins don't like to do this all the time, so you're going to have to rotate if possible.
If a developer is getting involved, it's called debugging, and it shouldn't be sitting with the help-desk anyway. If your developers are being bothered all the time with help questions, then they aren't doing much developing. Again, this would be a management problem, because good managers will be aware of this sort of thing and take steps to fix it.
"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.
It sounds like your real problem is that there is a seperation between the two groups. Sysadmins should be overseeing the helpdesk people, or be the 'second tier' of the help desk system. Secondly, unless you are dealing with large enterprise type machines, the developers should have their own machines and servers to play with. My view is somewhat biased since I work for a small consulting firm where we dont really work on 'internal' projects. Everything we do is billable to a client, or is being done to try and win a new project. The seperation avoids the inefficiency of large offices where daily memos about 'office policy' get sent around and generally annoy the crap out of people just trying to get something done without making 3 copies of all outgoing correspondence and putting them in 3 seperate desks where they are filed away never to be seen again until the file cabinet is full and they get thrown out. Sysadmins should provide network services, IE file servers, email, etc... but when it comes to getting a DB running on SQL Server for a development box, developers should deal with that, and maybe 'buy' time of the sysadmins to tune it or get a hand if they are incapable. Time is money. And departments should even be selling it internally as such.
"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."
Well, that sounds like most internal helpdesks that I've run across. The fundamental problem is that the frontline tier of people are often thick as bricks. Calling them up is just as bad as any other so-called tech support operation. You spend 20 minutes providing tracking information to someone who reads to you off some idiotic diagram that you should reboot. Lets face it, some helpdesk people, while eager and pleasant, are totally ignorant of the underlying mechanisms of the products they support and possess neither the faculties nor the ambition to diagnose a problem. Worse, if you attract too much attention from them they might disk-blast your system and ruin hours of customizations you might have set up.
Well, obviously my advice should never be applied in a formal business setting, because it is entirely coming from the point of the admin or developer who gets stuck taking up the slack of a bad helpdesk.
But, if you want to hear it anyway, here's what you do:
1. Don't hire helpdesk staff. Hire admins and junior admins that share helpdesk duties as part of their "apprenticeship".
2. (pipe dream) Put a computer in a room, loaded up with your company standard software. When you interview potential new hires, give them a simple task to do on the system. It should be something unfamiliar to them, but easy enough that they could figure out with 5 minutes of minimal effort. If the person does not at least make an attempt to solve the problem themselves, do not hire them.
3. Train your helpdesk staff to show users how to solve their own problems. Do not solve the problem for them while they are at lunch. If they call a helpdesk member over to do something, that person should stay at their desk and watch the entire time. They shouldn't go get coffee or talk with their neighbor. If you diagnose something over the phone, insist on an accurate description of symptoms. Don't settle for "It doesn't work" or "It's acting up". Let people know that you're there to help them, but that they have to be willing to help themselves. This is hard to do at first, but once you get going no one thinks anything of it, and users solve their own problems a lot more often.
4. Set up an intranet site/phone number where you can put status updates. Train people to visit it instead of each employee individually calling the helpdesk every 5 minutes when something goes wrong.
5. Have semi-annual fun training classes, where the helpdesk staff teach people to filter spam, use google, use tabs in mozilla, and generally introduce new pieces of consumer-level technology. Use these sessions to re-educate everyone about electronic security issues.
6. If you get users that intentionally break their computers hoping to get new systems, give them even older systems as replacements to set an example.
7. Have a published, fair system for replacing systems as they become obsolete. Don't play favourites.
8. Don't institute draconian anti-privacy policies that can be used to spy on users's desktops and/or read their email.
If you do even some of these things, your helpdesk will be efficient and respected vehicle for streamlining your entire business. If you go the traditional route you'll end up with a cost center full of what amounts to cheery office assistants.
A few suggestions:
1. Create a knowledge base for the help desk describing how to fix common issues, and then have an escalation procedure for how to resolve issues that are not covered. Even if you think that everybody should know how to solve issues this will help you by ensuring that constant procedures are being followed, that you don't have problems where one person fixed a problem before and now another person cannot. It will also help you get a good feel for what kind of issues you know how to deal with, and which you need more information in.
2. Use a ticketing system and make sure everybody uses it. If you cannot track how many issues you have received they never happened. A good ticketing system will also guide your reps in what important data needs to be recorded for every call. A ticket system make it easier for one tech to take over where another left off. Finally, it can provide statistics on problem trends that your developers can use for correcting problems, or for proving to the programers that a problem does exist.
3. You need management buy in to get the development team to stop accepting requests from end users without going through the help desk first. This will be hard at first since your users don't trust the help desk, but they will never trust it unless they are made to use it.
4. Make sure your front line has the tools and training necessary to resolve the bulk of the issues they get. If problems can get solved by the front line peoples the customers will have more respect for them and there will be shorter waits for upper levels to help with common issues. If you have common tasks that are too complicated for your first tear team then create scripts, batch files, or small programs to automate the process.
5. Train your help desk on how to respond to questions they don't know the answer to. They should avoid telling the customer "I don't know how to do that" and say something like "Hold on while I research that issue for you". The costumer doesn't need to know if they are solving the problem themselves or talking to someone more experienced. As soon as the user thinks they are taking to someone who cannot help them, they will not be likely to cooperate and will try to get right to the person they think can resolve the issue (second tear, development, etc).
Good Luck
People have suggested some great resources, but your company may need to invest in the helpdesk.
How much do you have to spend? 1-4 above are all costly in money, talent or time. Good people aren't cheap, any more than good processes or docs.
The people issues can be alleviated, but only in direct proportion to the quality and applicability of your processes and documentation.
Good docs are hard to write, so you can't just farm it out to your developers, or to the HD techs who don't have the confidence of the users. You're talking about as much work as writing a Dummies book for your company, and if it's less readable, it's less useful. Besides, there may be a reason for the user's lack of confidence in the helpdesk.
If you don't have good processes, your people have to be generalists. My observation has been that a HD person is eligible for a substantial promotion as soon as they become a good HD person. Of all the people I've personally seen and worked with who were laid off from HD roles (over a dozen) those who were good at the HD job got better jobs. The ones who were marginal had difficulties, but most found similar HD jobs where hopefully they can learn enough to become better techs. This is frontline user support in the SF Bay area after the economy tanked.
Truly talented & experienced troubleshooters with the social skills for customer service, can get work that is better compensated and better regarded than front line user support.
With good clear docs and cultivated customer service skills, the less skilled could be good first level support, but how often do you see docs of that quality? How much did those docs cost?
Assembly is the reverse of disassembly.
I have been working for a major IT company who outsources companies helpdesks, consequently I have a fair bit of experience of both good and bad helpdesks.
I think you have identified all the key areas to concentrate on.
Credibility
Is very important, if users don't trust the helpdesk then they will not be willing to provide the helpdesk with the information required to get the problem fixed - "stop asking questions and just put me through to someone who can fix this".
The best way of increasing your credibility is to ensure that the Helpdesk staff have a good understanding of the business and can appreciate what effect a problem is having for the user. They must then be able to tell the user how long that problem will take to resolve and what the user can expect to happen next, i.e. a call or visit from IT within x hours etc The key to this is honesty, if the problem may take weeks to fix and it could be two days before they hear anything back from anyone then the Helpdesk should state this ( if this is unacceptable then management will get involved to streamline the process somewhere ) because after a calling a couple of times users will soon work out whether what the Helpdesk says will happen does happen or not as the case may be.
The Helpdesk should be responsible for chasing Support Teams to ensure they meeting deadlines for fixing things and responding to users, they should manage the call so it meets the expectations they have given to the user.
The Helpdesk should know the current situation of any problem currently logged and be able to appraise the user of exactly what is happening with the problem at any time.
Users should get through to the Helpdesk after 1 or 2 rings, anything else and they immediatley start thinking bad things about the helpdesk. Do not ever give users the direct number for support teams, all calls must come through the helpdesk.
Poor Processes
Your helpdesk shouldn't need to be technical experts ( although knowing common simple fixes is helpful ) but they do need how to deal with customers and more importantly they need to know exactly who fixes what and what the process to arrive at a fix will be for any given problem. The job of the helpdesk is to manage calls and provide an interface between the users and the processes and people responsible for resolving their problems.
If you have a lot of problems like, how to underline in Excel etc then a seperate team should be set up expressly to deal with those calls which will be routed through the helpdesk.
A good Call Logging system is vital for communication between support teams and helpdesk staff, we use Remedy which I think is quite expensive but there are many others which do a similar job. A call logging system will give the helpdesk accurate information about how a call is progressing at all times, it will them check which calls are in danger of breaching the deadlines given to the user and will allow you gather statistics on the type and quantity of calls you're getting.
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 have spent a year designing various knowledge bases for clients helpdesks and the key things to bear in mind are:
Information is accurate and up to date - totally vital, if staff can't 100% trust the information in the knowledge base they won't use it.
Information is structured in a sensible manner to suit the structure of the information or processes. You staff need to be able to find the right information for the problem within 1-2 clicks, they need to be sure the information is for the problem they are experiencing and they need to be sure that a problem they are dealing with is not covered in the knowledge base ( if it isn't covered in it ) and know what to do with in that situation.
Rather than relying on people to add things to your knowledge base on an ad hoc basis find someone who is good at expressing ideas clearly and understands the systems to work full time updating and managing your knowledge base.
Allow no ambiguities, the worst thing from a helpdesk analysts point of view is amiguities in the information they are working from, they do not want balance up the pro's and con's of which is the right course of action to take they want to know - do A or do B.
Poor Follow Up
Using a call logging system will help with your follow up, it can provide statistics about common problems and alert the helpdesk to calls which have been fixed so they can call the user back and check that the fix has been successful and to the users liking.
Escalations
The analysts should be able to contact the necessary support teams at all times, if they can't you should have a series of escalations up the chain of command so any major problems are not 'waiting on John to get back from lunch, or somewhere' but being dealt with by someone promptly.
Overall you need to decide how the helpdesk should be structered from the point a user gets a problem through to it being fixed and re-organize your staff and support teams into that mode. Communication routes between the helpdesk and everyone is else is critical, they need to provide users with accurate up to date information at all times and so they need to be able access that information themselves.