Slashdot Log In
Improving Operations in a Small Helpdesk System?
Posted by
Cliff
on Tue Dec 26, 2006 02:29 PM
from the efforts-to-streamline-operations dept.
from the efforts-to-streamline-operations dept.
El Presidente asks: "I'm the department head of a small IT helpdesk in a not-quite-so-small business. The department's small in the sense that (a) there's only three people (including me), and (b) not only do we do helpdesk, but develop all the in-house systems, build our own servers, and more. We're supposed to log every helpdesk call that comes in (we've previously developed our own software for this), log notes on each call, and log the resolution. However, although I do set a good example by logging (most!) of my calls, the other two don't, even though I've asked them to do so numerous times. Although they do the job well, this is the one area that is letting the department down, and now management wants full stats on what we do every day, so obviously a full helpdesk log for each day would go a long way to prove what we do (or don't do). I don't want to come down on them with the Big Iron Fist (tm) and check up on them every few minutes, because I've got my own work to do. How can I actually get them to buy into logging calls, and not 'forget' or be 'too busy' to log things properly?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Bring down the hammer. (Score:5, Insightful)
How can I actually get them to buy into logging calls, and not 'forget' or be 'too busy' to log things properly?
There's a time to be a buddy, and there's a time to be a boss.
You put to them, in plain terms: They will log their calls or you will find people who can follow simple instructions. Yes, it's a Big Damn Hammer(TM), and they may resent you for it in the short term; but your ass is on the line to get your helpdesk in order the way the company expects you to run it.
Re: (Score:2)
As a follow up ... you also have to follow your company's expectations yourself. They don't want "most" of the calls logged--they want all of the calls logged.
Think of it as proof that you're doing your job: if you don't have numbers to back you up when management asks what your department is doing, you can look forward to losing money and/or people from your shop. Then you'll have just as much work to do, less money to make it happen and fewer people to do it with--because even though your shop handle
Re: (Score:2, Funny)
Or you could link this article and point at them. "That's you".
Re:Bring down the hammer. (Score:4, Informative)
This is an excellent point. I don't advocate dishonesty, but you could point out to them that they are asking you to justify your time and personnel, which is essentially what is going on here. Point out that you have to show your boss what is going on and prove that you need two people. Without their logs, you can show what you're doing, but not what they're doing. It's even possible they could eliminate one or both positions unless you have proof that they are both kept active and busy -- and that proof would be their logs. If there are no logs, you can't prove they're busy.
They will log their calls or you will find people who can follow simple instructions.
I'm willing to bet that was written by someone who has never run his own department or business. It would be nice if one could do that, but in the real world, if you've got an employee that does 90% of the job well, then you're damned lucky. Sure, you can fire them, but there's a good chance their replacement won't do as well as they do. Logging and documentation are two areas programmers, admins, and other IT people are notoriously poor in. People can claim to do that in an interview, but once someone else tells them he's never done it, they won't bother with it either.
It's hard to find good employees and you don't want to replace a 90% fit with an unknown that could be 90% bad.
Parent
Re: (Score:2)
Re: (Score:2)
I don't disagree with what I think you're trying to say (good employees are hard to find and noone is perfect). However, I really dislike how you've said it, because it feeds a particularly virulent sort of egomania that technical people seem to be subject to.
In my world (both as employee and as manager), it's pass/fail. There are X many things that the job requires, and if you don't do them all, you haven't done a good jo
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
But hey...let's pretend that admin salaries are pixie dust and don't count against the bottom line.
The guy that won't produce required paperwork for his manager, per his job description, won't do it for "a low end secretary". All you're going to do is add "30k o
Re: (Score:2)
Re: (Score:3, Insightful)
That's more of a reflection on how badly Remedy sucks than anything else.
To paraphrase Shakesphere: (Score:2)
The first thing we do is kill all the lusers.
on second thought, that doesn't exclude killing all of the lawyers.
Be straight with them (Score:3, Insightful)
If not, make them aware. Charts hanging on the wall will reinforce that a bit in the beginning.
You're always going to get the "I can either fix it or log it. Choose." kind of attitude. The answer is "You're going to do both."
However, there are some exceptions.
Is there actual value in the detailed logging? Is anyone going back to use the old resolutions or report on stuff? Perhaps the answer is a streamlined logging process that gets the basics you need without making your people jump through hoops.
So the question to me is whether you have a call tracking system (pure counts) or a problem tracking system (historical data, etc.) and what value you're getting out of the time spent.
Re: (Score:2)
That works for some people. If you get the arrogant type that just doesn't want to do things your way the reply becomes, "Either find time to do both or I'll find somebody who can." If you say that, be ready to follow through because there's always one twit who won't believe you'd fire them for disobeying direct orders.
Re: (Score:2)
"You're always going to get the "I can either fix it or log it. Choose." kind of attitude. The answer is "You're going to do both.""
I thought the answer was "You can take notes, or you can find somewhere else to get a paycheck."
Behavior only changes when there is accountability.
Make the advantages obvious! (Score:2, Interesting)
I'd say: make sure logging calls is useful to them as well, or at least make it obvious how useful it is to the rest of the business in general. As long as it's just another burden on their daily work, you'll never get you colleagues to use the logging tool to its full extent without that iron fist...
Re: (Score:2)
Bonus (Score:2)
Have the bonus depend on two parts: their own logging success, and the whole group's. That way, it increases peer pressure to do it right.
Just my idea.
Two ideas (Score:5, Informative)
1) Typically, the reason management wants statistics on helpdesk call volume is so they can make staffing decisions. I was not management at the time, but was at the same tier as helpdesk management when I was asked to compile statistics for average call volume by hour. Two weeks before Christmas, management cut helpdesk staffing hours by something on the order of 25%. We managed not to fire anyone, but they certainly weren't happy. After that, we saw a significant increase in calls logged. When the employees were faced with the real consequences of not demonstrating their workload, they decided that logging calls was a better alternative to not having jobs.
2) One way to increase logging numbers is by making certain simple helpdesk tasks self-logging. For example, when a client wants their password changed, it's tempting for the helpdesk consultant to just change the password without ever opening a ticket. Why not write the password change utility so that it automatically opens a ticket, provides some minimal level of notes, and then presents this to the consultant? If you can make ticket tracking easier to do than to not do, people are more likely to do it. Don't make the logging process completely invisible to the consultant, though--the idea is to integrate these steps with their workflow so that they get used to doing them, not to hide them altogether. One presumes that for the more difficult problems, consultants are opening tickets, anyway.
Just two ideas.
Re:Two ideas (Score:4, Interesting)
I'll second that suggestion and add another: make an API that facilitates logging and merge that into your workflow. NOTE: This is all off the top of my head. I expect you'll tailor it to your specific needs. Augment as needed and/or time permits.
I'm thinking along the lines of wrapper functions that implement:
The date and time can be captured automatically from the system. Ditto for the tech. That leaves gathering who called which could also be captured automatically from the Caller-ID info from your phone system. That leaves the Severity (Urgent! Important. When-you-get-a-chance) and Short Description.
Another comment suggested carrying around a small voice recorder. With the increasing availability of IVR systems, even these could be captured with a small front-end that the person calling the help desk goes through. If techs were only permitted to work on calls that come through such a system, then everything you need is already there. Log the incoming call's audio as a BLOB in an RDBMS, use some Speech Recognition on that to get a text-formatted problem ticket. Sure, it's not going to be 100% accurate translation, but for now it's good (enough) to go. Get the minimum up and running Right Now. You can enhance, later.
You are pressed for time right now, so this is going to need to start lean and simple. Just capture enough info to show that you are way too busy. Get some wiggle room from management.
Other Approach Rigorously provide what they request in the way of documentation adn logging!!! If you are short-staffed, then LET THAT FACT BE KNOWN! TANSTAAFL [wikipedia.org]. U
Parent
Take charge (Score:2, Funny)
Re:Take charge (Score:4, Funny)
Best Regards & Happy Holidays,
Dick Cheney
Parent
Time for you to grow a pair (Score:2)
Don't ask them to do it...tell them to do it. ( Be assertive, not aggressive )
Simple answer (Score:2)
1. If these other two guys report to you, there's obviously a lack of respect for authority in the shop. Inform them that logging calls is one of their duties (a critical one at that), and if they fail to fulfill this portion of their job, they will have to seek another. This response would be inappropriate if you hadn't asked them to do so previously; however your post indicates that you have.
2. If these other two guys don't report to you, it's Not
It's the way you tell them (Score:2)
Your softwqre is letting you down (Score:3, Insightful)
Do they not log because the system just gets in their way, adds no value (suggested fixes, workflow tracking) to the process, and takes too long? Then fix/replace the software.
Do they not log because 50% of their calls are quick hit 20 second resolutions and logging takes too long? Make it so they can log a call with nothing more than "password reset - extension 2710 - Complete" and move on.
Do they not log because they are so busy taking calls they don't have *time* to log? Then you need to implement a faster system, or staff up so that they aren't overworked.
Do they not log because they're lazy? Then you need to come down with the big hammer. But don't assume it's this, it's probably one of the others.
Re:Your software is letting you down (Score:2)
So, check out what it takes to log a call, and don't be afraid to change the system.
Make it a job requirement (Score:2)
Very simply write a memo detailing the new policies of the department, even stating that this information is required further up the chain, and require they sign it to be sure they understand it.
In the end it is your ass and reflects poorly on you if you can't get the people you're in charge of to do what
If management asks, you must deliver (Score:3, Insightful)
In the meantime, while management hems and haws about spending that much money, ask your helpdesk what they'd like to see in this ticketing software. Tell your analysts that they have a choice - help decide how ticketing is most beneficial to the department, or have no say so in the whole process and have to use a tool they don't like to justify their jobs to management. They have a third option: leave before or after training their replacement to use the software they don't want to use.
Look into the following while making the decision:
1. You want to be able to identify problem users. Train them, or point out in dollars and cents how much those users cost the company by the amount of calls they make to the helpdesk.
2. You want to be able to identify common problems, so that you can proactively fix them and reduce the call volume.
3. You want to be able to identify specific hardware that is failing in the environment. This means asset tracking. This might mean changing vendors.
4. You want to be able to identify which problems are taking the most time for your analysts. Proactively fix those.
Hope this helps.
All-round benefits... (Score:2)
You have to make sure your support logging system helps your techies as well as your management and customers. How do they keep track of what they are working on at the moment? Our previous system was a whiteboard and a bunch of marker pens. Now we have RT - our techies can prioritise, file, log comments, keep a FAQ - big benefits to them. The advantages to management and customers are also many-fold.
If your call-logging system isnt benefiting your support staff then maybe something is wrong with yo
I had this problem (Score:2)
The whole ticketing process severely interfered with my ability to provide resolutions because it's utterly irrelevant to the resolution itself.
I *did* manage to log most of my calls when it came time to demonstrate our need to outsource tech support. The deal was that if I could log my calls for a period of time, we could print a chart with the call log info and convince management to outsource tech support and allow me to focus on my non-helpdesk activiti
Give them a reason to log all calls (Score:2)
Re: (Score:2)
As I said to the fella down below:
"Smart. So when I come up with a process that eliminates 10% of daily trouble ticket volume, I'm gonna get penalized for it at the end of the year. Brilliant idea, Einstein."
Alternatively, you could face facts (Score:4, Interesting)
Hand out digital voice recorders to facilitate "taking notes". You can use them as you're dashing from one fire to the next. Give each guy two or three hours a week phone free, where the other two cover for him, and he can transcribe what he's been up to. Just enforce that. "Dave, you got nothing to do but write up your notes on Tuesdays after 2:00; but at 5:00, I expect to see what you've written up."
I've used casette recorders for many years doing big HP-UX/Solaris installs/upgrades. They don't slow you down at the time, but they help you remember for next time.
Re: (Score:2)
Let them test another package? (Score:2)
http://www.oneorzero.com/ [oneorzero.com] (GPL'd)
Auto-create trouble ticket upon phone call (Score:3, Interesting)
1) If you are using analog phones, this likely will not apply to you
However, if you use VoIP based on something like Asterisk [asterisk.org], you could force-open a trouble ticket when a call comes in to the support line. This way, they are forced to go in and close it, which should lead them to putting notes in it. You could further auto-assign the ticket to them if it went to their phone.
We currently do this when someone calls our on-call number- there's a big annoying ticket setting there awaiting resolution. Once this is working, set up some automated job to spit out a text listing of who has unclosed tickets, how long they've been open, etc. Have this list sent to all techs automatically.
We use RT [bestpractical.com] for tickets, so creating new tickets in the appropriate queue can be done a few different ways. Sending an email to the account we have setup to create the tickets is the way
2) Incentives ($$)- bonuses and raises based on time/tickets/minutes logged. Nothing logged? No money for you.
--falz
And suddenly (Score:2)
Happened to me.. (Score:2)
Being a printer company, I would get between 0-100 calls in a day. (some days nothing, other days LOTS)
I complied and logged the things I did. This got annoying very quickly so I stopped. I told my boss that the "official" service calls that I did were already being tracked by another part of the system, and the unoffi
Re: (Score:2)
Performance related pay (Score:2)
Re: (Score:2)
Get the customers to log the calls (Score:3, Interesting)
Get the customers to log the calls. Save your staff's time for solving the problems and all the other fun things that you mentioned. A decent system, even the free open source ones, can guide the customer to give decent information (contact info, category of problem). You will find that these calls yield far better information than comes through email, so turn the email off. If a customer is not willing to write the call then it is obviously not a real problem.
If they ring then get the adviser to write the call while the customer is still on the phone, if the adviser explains what he is doing (explicitly, or implicitly - murmuring the field names), then the customers will learn.
Re: (Score:2)
Get the customers to log the calls. Save your staff's time for solving the problems and all the other fun things that you mentioned. A decent system, even the free open source ones, can guide the customer to give decent information (contact info, category of problem). You will find that these calls yield far better information than comes through email, so turn the email off.
This helps quite a bit, though it depends a fair amount on the user being clued enough to properly report the problem (and clued enough to use the interface, which isn't a guaranteed thing, no matter how easy the interface).
If a customer is not willing to write the call then it is obviously not a real problem.
I wish you luck in getting execs to not call on the phone.
If they ring then get the adviser to write the call while the customer is still on the phone, if the adviser explains what he is doing (explicitly, or implicitly - murmuring the field names), then the customers will learn.
Honestly, I think the better idea is to have two helpdesk tiers. One that takes calls and does first-line troubleshooting, the second that deals with problems that take more than a few minutes to resolve. Of course, "se
Grow a pair (and Implement RT) (Score:2)
One other thing to do if you can, is have your callers get used to sending you emails and have them do it to an RT server. (http://www.bestpractical.com).
The company where I work is using RT for almost every request / fullfil request scenario that we used to use email for.
Well... (Score:2)
I have this problem with Remedy. My other problem is that while there's lots of details, if its a high-volume ticket day, I end up having to jot down the problems I worked on (strangely I have a hard time remembering who I helped, but if I write down who they were and what their problem was, I almost always remember the solution without fail) and filling them out later. Now, granted, our metrics-readers don't drill down far enough to notice I put in 20 tickets between 3pm and 5pm as I go down the list, but
You are going about it all wrong. (Score:2)
Silly to even allow users to get someone on the phone. Write an Web App, and force users or department heads to fill out trouble tickets online. Users fill them out, they are time stamped, and only users can close them upon satisfaction of the issue being resolved. The time taken to do the work is logged for reports, and your management can get a report anytime they want.
Your people have access to a list of open tickets sorted by priority, and they simply go about thei
Re: (Score:2)
Works great if you can get their management chain to support a no-phone-call-helpdesk. Doesn't seem to happen a lot, though.
Funny thing I saw happen once, when we moved people to a new "self-help" system and web-ticket entering for new users. They nominated one person in their group to enter all their tickets, because they couldn't be bothered to put in their own. While amusing, one has to wonder if anyone ever looked at the reports and noticed that from that particular group, 80%+ of the problem report
Re: (Score:3, Interesting)
I just created a system instituted a policy so every request must be logged in an intranet help-desk application by the person making a request before it would be handled. Now there are n
Re:change their phones (Score:4, Insightful)
I also run a small help desk (me & 5 students) that has a lot of turnover (can't keep the students forever) and very few overlapping shifts. What this means is that automation has become our friend. Help the users to create their own tickets and it'll save your staff a bunch of time.
We do this in several ways:
-E-mailing our help desk opens a ticket and fills in as much detail as it can from the e-mail address. It attempts an AD lookup as well if the domain is ours.
-Web forms. We have a couple of
-Calls are harder, of course, but I always ask my staff what ticket they are working on. If I get a blank look, they go back and go create a ticket, then resume work.
-Desk stop-bys. If possible I ask people in the offices to just create a ticket and we'll pick it up from there. If they e-mail me or a staff member directly, I'll open one for them if I have time, otherwise I ask them to do it.
-Voicemails are sent to us by our phone system as e-mails which, when sent to the desk, open their own ticket. So not only is the entire VM archived, but it is accessible even if it gets deleted or is purged from VM after 15 days. Plus we can send the VM ticket to others as necessary.
We use Numara Footprints [numarasoftware.com] for our system and I like it. It's pretty easy to use, customizable, and pretty expandable.
My final thought to all of this is to embrace automation. Anytime a computer or another person can make a ticket for you saves you a bit of time (excluding those with the "it doesn't work" phrase in the details).
Hope that helps!
Parent
"If you didn't log it, you didn't do it." (Score:4, Insightful)
Blame it on the beancounters. "I need these stats to be able to justify our jobs. If I can't show the Guys in the Ties that I need both of you, they'll make me get rid of one. If it comes to that, we'll lose the one who logs the least hours working trouble tickets. It probably won't even be up to me at that point."
Every phone call or trip to an employee's cubicle is an 'event' or 'activity' that needs to be documented, even if just with a sentence fragment (Asked Jane to reboot her workstation and call back if further errors.). Make sure your system accounts for who you're supporting. When budget time comes, you might be able to show that the lusers in one department generate a disproportionate number of support calls, because they insist on being local admins with the power to install extra crap you haven't tested. Your fourth person's salary might come out of that department's budget.
But the big win will come when you can data-mine your system and find patterns. "That GPF is only showing up on workstations with Foo version 3.6 build 2405 using the Barf-o-matic 2010 video card with the xZyzzy chipset."
Parent