Improving Your Help Desk? 59
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.
Do it right (Score:4, Funny)
Some stuff (Score:5, Insightful)
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.
Re:Some stuff (Score:2, Funny)
Re:Some stuff (Score:4, Informative)
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
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.
Re:Some stuff (Score:2)
I now work as a trainer.
Training saves money and makes everyone's job easier, helpdesk-wise. The doofus who calls to find out how to use function X in his wordprocessor, or doesn't understand the filesystem on his PC, is undoubtedly wasting shitloads of time and money trying to understand the noisy beige box under his desk, and may be keeping your staff from taking a much more important call.
I know "Training is the first thing to go.", but if you've got a budget and a staff for it, it's probably worthwhile to track users with a "needs classroom time" flag in addition to everything else in your trouble calls.
Re:Some stuff (Score:2)
"In short, you should be able to print the rules on one sheet of paper to handout/post."
This is what I meant:
Shouldnt be too complicated for helpdesk employees to remember.
Ticketing problems is really the only way to go, even if that takes too much time or bothers customes a lot. Its the only mechanism that works across many days, many breakdowns and many helpdesk employees. One of the biggest frustrations of the customer is seeing a new helpdesk employee try all the old methods of fixing the problem thats been already tried. The only way out: ticket everything in a database.
About girls: we had a really nice geeky girl at our place who would lug casings herself, open em up and fix jumper problems in a jiffy. That blows gender discrimination right there, but hiring for the sake of voice or looks does suck. You call someone with a problem, get someone with a really nice voice that goes uh-huh as you describe the problem, then hands it over to a scruffy-sounding guy who ends up fixing it. In this case, remove the middleman or middlewoman and connect the customers directly to the geek. Of course if you have billing issues, or stuff other than a Technical Helpdesk, you can be choosy in this way.
We also had the 30-minute rule. Noone obeyed. Why? because 60% of the people seemed to have Pentium 1s. That means trying to run windows95 on em, installing and config itself takes an hour. For some reason they even accepted 486s, and we had to work on them. As frustrating as they were, they made time pass faster. When asked why it took me 2 hours on a prob, Id just say it was a 486dx4 with windows95. Theyd just say OK.
I remember ... (Score:1)
Oh well, nearly the whole building was laid off anyway.
Improve communication between techs and helpdesk (Score:4, Informative)
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.
Re:Improve communication between techs and helpdes (Score:3, Insightful)
Just about had a stroke... (Score:2)
Trouble Ticket System (Score:5, Insightful)
Re:Trouble Ticket System (Score:3, Insightful)
Re:Trouble Ticket System (Score:2)
Re:Trouble Ticket System (Score:1)
Re:Trouble Ticket System (Score:2)
We use it to track all sorts of things - from actual support requests to configuration changes. Good stuff.
Re:Trouble Ticket System (Score:1)
A big hint is organisation, the other guys are right, there has to be a intemediary between the "developers" that seem to know what the hell is happening, and the help(less) desk that you are running. At my current job we have a huge inventory of customised information on our clients as a
Its a Help Desk, not a crutch (Score:5, Insightful)
Ok, some questions here (Score:4, Insightful)
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.
Re:Ok, some questions here (Score:1)
If it is a product support line, as opposed to a company helpdesk, then the first step will be to install Bugzilla [mozuilla.org] to take requests, sort them, filter them, assign them, and email the user when someone answers them
There is no second step.
greater knowledge than callers (Score:2, Insightful)
Re:greater knowledge than callers (Score:2)
You're missing one of the reasons for having a helpdesk here - tracking the regular, niggling faults that plague an organisation. OK, let's say that you know how to fix that awkward printer driver problem that you have, and you know how to fix the same problem that a colleague has. Sure, it gives you a warm fuzzy feeling to fix it, but by not reporting these repetitive problems to the helpdesk it masks a deeper problem - that the driver software the organisation is rolling out to the desktops is buggy. A good helpdesk (or more likely a decent trouble ticketing system) will notice these repeated problems & flag them.
Matt
Places to examine (Score:5, Insightful)
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.
Cost in money & talent (Score:3, Insightful)
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?
My experience (Score:4, Insightful)
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.
A suggestion: don't use the "virtual" setup (Score:2)
I can't remember the nature of the question, but when I made the request of the phone support bank, she had me hold on while she sent off an email to tier 2. And we waited.
And waited.
And waited.
Finally, I just gave up, and ultimately found my answer by just hunting around. This was after 20 minutes of waiting for an email response, and trying to argbue with the front line support person that, despite her protests that this new "virtual" setup was a lot better than the original system, I was utterly repulsed by having to sit and wait for 20 minutes for a response that never came.
Political structure (Score:2)
i.e. for the claims department there is IS claims
for the sales department you have IS sales
If you have that sort of situation you may very well want your front line suppor to be coming from the applications departments. The best solution to help desk would be to make them almost 2nd tier support (i.e. for things outside of the department's scope like corporate internet access or corporate email the department IS call in the help desk). Why put a needless middle man into the mix if the most of the problems are department specific applications which a help desk can't expect to support nearly as well as the authors. If you don't like this have the help desk personal start to specialize a bit more (obviously the customers want people with more specialized knowledge).
_____
The other reason this is happening is because the developers are quite knowledgeable and the help desk people aren't. For example if you are on Windows and lots of developers are windows wizards while the help desk people know how to log on; then you solve the problem by training the help desk people.
_______
Finally ask your end users why they call the applications developers and not the help desk. Ask the developers the same question. Find out what expectations are. I've seen help desks many times get involved in situations they can't possibly help because they see themselves as first tier support. In many of those situations the best the help desk could ever hope for is little more than accurate tracking and when they started to focus on the areas where they could be helpful everyone was much happier.
trouble ticket system and USE IT (Score:4, Insightful)
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.
Bad Management? (Score:5, Insightful)
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.
Double Choco Latte? (Score:2)
This may or may not help, but if you think software might help to manage the support process, you might try Double Choco Latte [sourceforge.net].
Helpdesks I've seen (Score:5, Insightful)
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.
Re:Helpdesks I've seen (Score:2)
As for a tracking system, the last company I worked for (in IT) used Vantive as their helpdesk system.
Re:Helpdesks I've seen (Score:2)
I'm too far removed from my helpdesk days -- working in one, or closely with one -- to remember any of the specific software that was used, but just about anything that stores the data and allows it to be summarized is better than nothing.
At one point, I even wrote a quick and dirty app for the other developers in my department to use. Nothing formal, but it tracked time spent, severity, and contact information. All the info we needed to give to managers for changes to happen.
Re:Helpdesks I've seen (Score:2)
I'm sorry, but having managed a helpdesk; the guy in charge of the developers gets quite pissed when his golden children must stoop to provide support to lowly line employees. "Don't ever bother my developers by sending a client to them" is a common phrase.
However, bidirectional communication; regular comingling sessions and even formal training/feedback between the helpdesk staff themselves and the developers should be encouraged or specifically implemented in policy. The only people talking directly to customers should be the first-tier folks.
Read Limoncelli and Hogan (Score:4, Informative)
There's also a website at www.sysadminfocus.com [sysadminfocus.com], but get a dead-tree copy as there's not much on the website.
Then, get involved in SAGE [sage.org] and USENIX [usenix.org]. 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
Our Helpdesk (Score:1)
Cahnging help desk results: (Score:5, Funny)
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.
yep. (Score:1, Troll)
You've pretty much answered your own questions. (Score:3, Informative)
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.
The Obvious from a former BOFH (Score:5, Insightful)
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.
Help Desk Improvement (Score:4, Insightful)
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
Ownership, leadership, motivation (Score:3, Informative)
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.
Support isn't about computers (Score:1)
Make sure that your helpdesk staff are familiar with the processes within your company as these should be inseprable from the IT. The IT is mearly there to facilitate whatever the business does. Any techie worth his salt should be able to look at an error message and take a good guess as to what it means and how to fix it. However it takes something extra to know what the impact of system foo not working is.
Also knowing what your customers do with there IT will inspire confidence in them because when you know how they work and what they need a system to do you know what can go wrong.
The Fortune 500 Approach (Score:1, Interesting)
And no, this isn't a joke or a troll.
IT help Desk (Score:1)
my experiences of helpdesks (Score:2, Insightful)
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.
Re:my experiences of helpdesks (Score:1)
Ever hear the phrase, if it doesn't make business sense, it probably makes no sense. Well that applies especially on the help desk. I went to a school where the philosophy of 1/3 Personal Skills, 1/3 Business Skills, and 1/3 Technical skills was the philosophy for a quality candidate in any tecnical area, not just the help desk. Yes, discriminate on things that are pertinent to the business, such as history of work ethic, experience, ability to deal with problematic customers, and providing answers, even if you can't provide possible solutions. Obviously don't discriminate against age, gender, religion, or any of the usuals, but that doesn't mean that you can discriminate on things where everyone plays on a level field.
The combination of using a system such as CCE 2.0, and carefully selecting quality candidates for the role of help desk are 2 of the 3 keys to successful e-business for the next 20 years. The third key is Team work. Focusing on the team, rather than the individual is a key to understanding quality leadership and responsiblity within the modern workplace. Corporate Pyramids will only give a feeling of unmannered demeaning, and unjust qualifications of the job. Even if most members of the desk make vastly different wages, put them in a team environment, and they will learn to respect each other more as a team, and then they can effectively solve the technical problems of the company.
You don't need to improve the helpdesk. (Score:2)
I'm assuming these are entry-level, average-salaried folks that are not required to have an A+ or MOUS certificate - typical of your standard-issue helpdesk. The problem is not technical, but motivational. They are there to collect a check. I bet the helpdesk isn't even a part of the company's IRM department - it's probably attached to marketing, as many managers feel it should be. You, after all, mentioned that you needed to go to the 'help desk manager' - not a division head or team leader; but a specific manager - to offer suggestions on how to improve the helpdesk process.
First, fire your "burger boys". You know who they are; and what I mean - if everything else going on is more important than taking a call, then drop them. I don't care if they did answer more than anyone else it is attitude that counts. Second, get them all to a Fred Pryor seminar on customer service. I bet they'll be the only tech helpdesk there; but the information they get there needs to be applied immediately upon return to the cube farm. Third, get the most technically competent on that helpdesk to write your scripts, or have the 2nd-tier folks get them together; and have them ready when your helpdesk staff get back from their customer service training.
You probably have a lot of turnover on this helpdesk already from my perception that there is little morale or ambition inside the helpdesk as is; and you are going to get more turnover if and when people develop their technical aptitude when you start encouraging them to use FAQs and technical resources on their own instead of just scripting them out for them - but these are my suggestions; your mileage may vary. If they are as ill-suited to customer service - not technical skill but interpersonal, customer service service skills - as they seem to be right now, then they may be very resistant to change.
A tip ... (Score:1)
Hire the right people (Score:1)
Hire young punks still in Uni, train them in the use of the software they are supporting, sit them down with the developers to see what the helpdesk can handle and what the developers should handle, sit them down with any other tech support people to figure out what each group should handle, and give them a couple of boxes to bang around on with the software they are looking after.
Don't treat your helpdesk people like morons, and the users won't see them that way.
It's really quite simple.