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.
Read and apply to your situation
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
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.
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d? s: a-- C++++ UL++++ P++ L+++ E- W++ N o-- K- w--- O- M+ V PS+ P
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
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.
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
"The purpose of argument is to change the nature of truth." -- Bene Gesserit Precept
1: First off, pay the bare minimum. You dont want to pay much for help, your it infrastructure isnt that important anyway.
2: Dont offer any raises or decent incentives to retain employees, you can hire new ones cheaper anyway.
3: Never offer any training, theyll just take that and go somewhere else.
4: Always hire from outside for advanced positions, hiring from the current employee pool isnt as cool as getting a new outside consultant in.
5: Micro manage, micro manage, micro manage: I cant stress enough, how making sure that employees account for every minute of their time is more impostant then getting the job done, or customer satisfaction. REmember, keeping the remedy stats up is far more important than satisfied customers.
6:Certs ae more important than experience.
7:Hire only the youngest people possible, anyone over 35 cant possibly understand this computer nonsense.
8:You want 1 manager per 2 employees. See the micromanaging bit.
9: Oh, and make sure you never allow the techs to do anything besides slap a hasty patch on someone elses mess, they can just fix it again in 2 days.
10: MsOffice XP
Oh, wait, you wanted to improve the helpdesk. REverse that, then.
Oh, and if youre serious about getting stuff changed, and somewhere in the D.C. NOVA Area, drop me an e-mail at unknown_poltroon@yahoo.com. My company might be able to give you an evaluation.
All Troll + "offtopic" mods are meta moderated as "Unfair", because you abused the system.
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. 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.
Life is like surrealism: if you have to have it explained to you, you can't afford it.
"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
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.