Slashdot Mirror
Improving Operations in a Small Helpdesk System?
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?"
You're the department head, which makes you the boss of the other two? Sounds like you need to break out the iron fist. Hard as it may be, that is your job.
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.
!#@%*)anks for hanging up the phone, dear.
To paraphrase Shakesphere:
The first thing we do is kill all the lusers.
on second thought, that doesn't exclude killing all of the lawyers.
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.
If you developed the logging software in-house, it was probably developed with some goal in mind. Either this goal was not of any use to your colleagues, or they don't see it yet.
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...
As the department head, you have to justify their continued employment in the company. If you don't have the statistics to prove that they're needed, then the financial side of the business can decide to cut the budget for your department.
Which means either pay cuts or loosing one (or both) of them.
Tell them that, and I bet you that they'll start logging tickets.
mgcady
(who'd get her password and log in if her company didn't have her webmail sites blocked)
Have them get a bonus (small, probably a percentage of their salary) based on their logging. Measuring metrics are left as an exercise to the submitter.
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.
Watch the Teaser Trailer for "The Lightning Thief" Her
Two things from my prior helpdesk experience:
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.
Seems like you have leadership problems, failure to log is only one symptom of much bigger problem. Good thing - you have an easy way out of it. Hire somebody you can trust, shortly after that hold a meeting on keeping notes, have new person use 'too busy' excuse and fire him on a spot for it.
You're the boss and asking them to do something not only reasonable, but important for operations of the company as a whole. Your boss needs to measure your department and you need to measure your team.
Don't ask them to do it...tell them to do it. ( Be assertive, not aggressive )
Not wanting to state the obvious, but change their phones to ensure that each call that comes through to their extension in fact goes through their pc, which will be logged, and therefore is a performance metric. In the absence of IP telephony you can still accomplish this with good old modem technology. By changing the environment, you can easily ensure that they will perform their job as expected. All calls that come to them will go through the PC and will be monitored and correlated to the helpdesk logs. Sometimes policy is not enough, you need to force the issue by locking down the environment. As a good help-desk administrator, I'm sure you're able to make the necessary mods required to tighten down the situation. Enjoy, and happy boxing day.
if I claimed I was emperor just because some watery tart lobbed a scimitar at me they'd put me away!
You must always provide 3 things to be a leader.
1 Purpose. Tell them why they are doing it.
2 Direction. Tell them what to do
3 Motivation. Tell them why they want to do it
There's a simple answer, even if it includes a conditional:
:) I have that problem all the time myself. I've found that a combination of politicing with my peers and superiors, and browbeating those over whom I should have authority (but don't) is a decent combination.
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 Your Problem(tm). At most you can inform their manager that they aren't "acting in the best interests of the team" or some similar poppycock.
If you have the responsibility to ensure that the help desk acts as it should, but you don't have the requisite authority, then Welcome To IT(tm)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
I've had a few bosses that would just bark orders and expect instant compliance which works for a bit but kicks moral in the teeth. The best always explained how important the call logging is not only for higher management but for intercommunication between the department the team. This should work both ways though, if the workers have genuine gripes like the calls are all the same so not worth logging you may want to look into certain templates rather then waste time. Respect is only earned when you fight for your teams views just as much as ones from middle management.
"I disapprove of what you say, but I will defend to the death your right to say it." - Voltaire
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.
You're the boss, don't forget that. You might consider reading some books on leadership if you're uncomfortable in that role or getting people to do what you ask them, but regardless you're still in charge.
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 they are supposed to. Small departments are more difficult because its harder to differentiate between co-worker and boss in that situation, especially when everyone is essentially doing the same work, but handling it properly shows you're ready and capable for larger responsibility.
Don't be afraid to reprimand them if they still won't follow the policy. Keep a paper trail and make sure the reprimand fits the problem.
Based on my own experience being on a one-woman help desk with an Access db for call tracking, I suggest first making sure the tracking software is not part of the problem. If necessary, invest in a better system. Then make it absolutely clear that raises and the job depend on tracking calls. Let the pieces fall where they may. Good luck.
My karma is excellent.
Be like Steve Ballmer by throwing chairs at the problem. If your department is a small hole in the wall like most IT outfits, throwing a chair can hurt for everyone involved. But the problem person usually figures out that having a chair thrown at him or is usually not a good sign.
Simply tell management that your current tools are not up to the job that they require. State to management in no uncertain terms that while you could write a program to document the calls, or come up with a way to do it that enhanced the performance of your team, you can't set aside additional time to do that and still stay on top of your work. State that it would take you x number of hours to develop the tool to track tickets at y$ per hour, where x*y>z (z being the cost of the ticketing system you want for your helpdesk). This is called stalling.
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.
Your sig(k) has been stolen. There is a puff of smoke!
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 your call-logging system...
B
I unfortunately never found a solution for myself.
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 activities. I was burned out, so it was do-or-die.
Lighting a fire under them is really the only way. I hate to say it, and it is not a job I would do, but that's how to get it done.
put on your salesman hat and point out why it's beneficial or how it can come back to bite them. like several other posters have said, they need to understand the consequences/rewards of this logging system. nevermind the greater benefit to the company or upper management, make it matter to them on an individual level (stats determine bonuses, raises, service level agreements, headcounts, etc). no one wants to do something just because the boss says so (tho that may be the reality of office politics).
Tell them that from now on, their annual performance review will include the average number of calls per shift and the average amount of time spent per call. If the call isn't logged, it didn't happen. You'll be amazed how fast the percentage of calls logged rises, especially if you let each of them know, privately, how their performance would be graded based on their current lack of logging.
Good, inexpensive web hosting
"Too busy" isn't an "excuse", it's the "truth". You and your guys are understaffed and overworked, running around like chickens with your heads cut off. Anything that decreases your productivity or slows you down is doomed to failure. Time sheets (whatever you call them) are a perfect example. "What did I do today?" Errrmm. "How about yesterday?" Ahhhh. "Last Tuesday?" Not a clue.
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.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
I've got to say, not knowing very much about your systems, procedures or staff, that you need to look into the difficulty in logging calls. We use a thing called Clarify, and while we have to use it, its a real PITA. So much, that we now have 3 different logging systems for different departments - everyone wants to use something else, if they can.
So, check out what it takes to log a call, and don't be afraid to change the system.
Tell them that their bonus will be based on the number of calls they've logged. ;p
But seriously, you should explain to them why it's so important to be able to measure what your team is doing. How else can you explain to upper-management that you need extra resources, for example? But if management is requesting full stats anyways, it sounds like your team doesn't have much choice.
Maybe let them compare and choose which system they like to use.
http://www.oneorzero.com/ (GPL'd)
Two options.
1) If you are using analog phones, this likely will not apply to you
However, if you use VoIP based on something like Asterisk, 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 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
Productivity of helpdesks across the nation plummets while everyone scrambles to put their $0.02 into this thread.
Your sig(k) has been stolen. There is a puff of smoke!
Unless you have to, of course. Don't make logging calls your responsibility *after the fact." Make it one of their prime responsibilities, AKA "a critical personal metric." Have them rotate the daily responsibility so they have a reason to help each other.
I evaluated some bug tracking software a while back for a software development group (granted, we had some different requirements than your situation) and settled on FogBugz. One of the features that should help your situation a lot is it's ability to accept "bugs" via email. You can auto-assign these issues to your staff depending on some variables, which may also help (different people can be the auto-assignee based on work type (server, code, etc.). It seems like the issue here for your staff is having them track all this data, and that setting up the problem description, notes, resolution bits are just too tedious and seem unrelated to their work (to them). I'd set up an "issues" email address and have FogBugz manage it. That way, the problem is described by the user themselves, making notes or asking further questions about the bug is super simple and done within the tool. It integrates into a screen capture utility (for windows) too, which is helpful in many cases. Take a look at it... it's very reasonably priced and does the things it's supposed to do very well...
In the past, I've run helpdesks, and I now work for a IT consulting company that provides help desk solutions as part of our repretoire.
It sounds like you haven't actually identified the problem, and you need to look at the whole picture to determine the solution.
I'd start with doing some research on best practices for help desks. While ITIL might be a huge stretch for your needs, it certainly is a great source of information about *HOW* and *WHY* a help desk should be run. Buy a book, or at least hit Google and figure out what your help desk needs to provide the best service to your company.
Next, take a good hard look at your processes. I will guarantee that, as some other users have pointed out, your call statistics are an incredibly important measurement of your success. Having access to that data will help you make the right decisions on providing service to your company. Without it, you don't have a clue about what you are doing or why.
A few examples:
How do you prioritize the duties you have to fulfill? Is it more important to build a new server, or to spend 30 minutes researching a users problem? How much time should you be allocating for the different functions? How many people do you really need to do your job properly?
How do you identify problems that interfere with your job duties? Do you actually know which users are uselessly sucking up time with repeated calls about the same problem? With 3 people, you might have 2 users in your company that are consistently consuming large percentages of your help desk resources and no one has really identified that. Being able to spot trends (the same problem occuring on the server over and over, clueless users, bad desktop software after an upgrade, etc.) will help you keep your own stress down while benefitting the company.
Have you actually taken a good hard look at your homebrew help desk software? If your average call is 1 minute, and it takes 1 minute to log all the call information, its no wonder your people aren't logging things. Can you link the PBX to the software to auto-identify and populate user info fields? Does your software have the ability to auto-complete all extra fields once the user is identified?
How much time are you spending on password resets? Can that be automated or simplified to the end users to save you time?
Today, there are quite a few good help desk packages available. From low end off-the-shelf packages to the commercial packages. A full-blown professional system will still run you less than $30k fully installed and will probably up your productivity by 50% or more. The lower end packages will be considerably less and have similar effects, but your choice will be made by the functionality you really need.
Also, you should be tracking *EVERYTHING* your employees do. Not just help desk calls. The only way for you to measure your actual performance will be to treat server builds (or any other function) as if it were a help desk call. This will give you *REAL* statistics to carry back to the bosses and make actual decisions. If you only log help desk related tasks, then a huge percentage (possibly more than 50% of your time) could be black hole time that has no quantification. If you spend 4 hours one week coding, it should be logged. If one of your techs spends the entire week building new servers, it should be logged. Again, a halfway decent help desk software will allow you to parse functionality and see what you are doing, and help forecast and justify your time and see the problems.
And you need to remember, this isn't about "Big Brother" watching. Its about having a true measurement of effectiveness and function. This information will let you go back to management and say, "Look, we're spending 10 hours a week each working overtime, which is costing you more than an additional tech and we've been doing this for 4 months," to justify the fact that you need help. Or finding out that your on-call guy is spending 20 hours a week wo
You might try stessing the importance of logging calls. Explain that by logging calls, negative trends can be tracked and justifications for better systems can be made. Call tracking also allows you to identify persistent, problem users and you can go to their managers to deal with those types. Finally, it is a good troubleshooting record. If the same person calls again with the same problem, the help desk technician only need look at the history rather than starting troubleshooting from scratch. He or she can see what ground has been covered and try something else. If these steps do not encourage better record keeping, well, the Big Iron First(tm) may not be so bad. Hey, there are more people with IT skills than there are jobs for them. If your particular two folks don't want to work, I am sure you will find, without difficulty, someone that does want to. Maybe I am old fashioned, but when a supervisor makes a reasonable request, you do it. Now, if the reason was legimtimately forgetting to log a call, that's different. I happen to like Track-It as a call logging system despite it being IE and Windows centric.
I was the helpdesk/IT department for our regional branch of a large multi-national company. One day my boss told me that his boss wanted to see logs of customer call-traffic/work done, etc.
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 unofficial 30-second phone fixes (did you check to make sure the printer isn't out of paper) were too numerous and time-consuming to keep track of. My boss agreed. Case closed.
A few months went past and my boss asked me again to "log everything you do in a day".
Sigh, here we go again.
So I filled out the logs.
Logging EVERYTHING.
I high-lighted the time-blocks that involved "filling out Time Log", some days that alone counted for 30% of my clock-time.
A week later me, my boss, and the General Manager had a meeting. They gave me hell for writing in my bathroom breaks, asked why I was spending so much time writing out logs, and why were people now complaining that they had to leave a voice-mail as opposed to talking to me.
If you cannot "log" what your techs are doing non-invasivly, then you will not get an accurate measurement of what they do.
Try setting up a security camera if you are worried that they are playing WOW on company time. If the job is getting done properly, LEAVE THEM ALONE.
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
I've always had good results with Request Tracker, which does a lot of this for you and is time-tested open-source:
http://www.bestpractical.com/rt/features.html
Base part of their salary on the helpdesk software statistics.
Deleted
I worked at a Helpdesk for what seemed an eternity (although I always enjoyed it).
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.
My little Linux and tech blog
I must agree with the posters who are saying, Be the Boss. You must do this.
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.
Being that I worked at various support companies and ISPs, from an outsourcing company to a web hosting company, from a tech support rep to a systems administration position (currently), let me ask a few questions:
- How many users do you support?
- Is there a online web knowledge base (i.e. a wiki or a sharepoint) that end users can go to for common fixes?
- How many projects is your team currently handling right now? Which ones are a priority?
- How is your help desk system? Does it take a few minutes just to log a call?
- How many calls per day do you actually get per person?
It sounds like all you are doing are fixing problems as they come up, regardless of what type of issue they are (I could be wrong). That model works if you are just managing incoming phones for an ISP; but since you are also apparently a system admin + engineer, it may be that best thing to do is to ensure that you try to ELIMINATE as many phone calls as you posibly can, so that you can do the More Important Stuff (TM).
Call logging is not the most pleasant part of helpdesk - it can be used by managment against your department; however, but it can work for you as well, as a means to:
- automate fixes (Passwords resets? Write a tool to reset the logins).
- trace problems (people complaining about the website going out at certain days for the last few months?).
- Create tutorials (People need help with Word? Create a document with common howtos and/or links to word web sites).
Besides reducing the calls to your deparment, the above step (and other proactive efforts; i.e. change control notifications) may provide needed visibility to upper managenent (and end users at large) - that your people are actually doing their jobs and not slacking off. Obviously, it doesn't look like they are slacking off (from what I can from your post), but it doesn't look like everybody else in your company knows that.
Hence, if you approach your colleagues with that angle, it would probably go a long way in ensuring that they will log the calls, rather that threatening them with termination. They probably have to deal with unreasonable people every day - they should at least deserves an explanation that is reasonable.*
*Of course, this assumes that you will go out of your way to follow up on making call logging less necessary in the long term.
It is really frustrating, however, the reality is that in many organizations it doesn't matter to management how much you or your people actually work. If you cannot quantify everything you do in easily digestible bits of information you aren't really doing it as far as upper management is going to be concerned. You're already at a disadvantage being in operations as everything you do costs money and it is unlikely that you bring in revenue to the company. If your people are in fact "too busy" to log the work you it becomes even more important for them to actually log everything. You need to explain to them that logging is important not because you are a jerk but because it justifies their continued employment and future headcount increases. On the other side of things you need to support them taking the time to log all of the incidents and projects they work on even though they will probably get less actual work done each day because of it. Companies don't keep unnecessary people on the payroll make sure you can show why your team is needed.
Your helpdesk question sounds like two issues. A technical issue and an employee issue. I used to run IT for a 200 person firm with a team that had 2 AS/400 guys, 1 desktop PC guy, and myself. I had a very similar issue you are describing, the IT staff didn't get measured and the business management felt IT was way too expensive considering the value they received. Previous post is right - you can be friendly but you are no longer a buddy, you run the team. Here is what I did =
Technical issue = I installed OTRS/Apache/MySQL on Linux. 100% open source, no software costs to company. Tied to Active Directory LDAP for authentication. Users can do tickets by telephone call, email, or enter via web interface, tickets auto-generated by Nagios (again - 100% open source on Linux) monitoring for critical alerts. OTRS notifications to IT staff via email and SMS messages to phones. Used existing instance of MS SQL Server reporting services (this is a great reporting tool) to query Mysql and to send eye-candy pdf pie charts via email of IT helpdesk activities to Business Management. PC guy and I like the system, AS/400 guys grumble about learning new technology. Used OTRS as poor man's change management system as well. Rewrote job descriptions to include helpdesk activities.
Employee issue = Both AS/400 guys have history of refusing to do anything that isn't RPG - unbelievable. We only have 4 IT staff, that kind of IT bigotry isn't going to cut it. Incredibly, consultants do the major work for the ERP system (customizations, upgrades, reporting, OS patching). What do these guys do? When I ask the guys to document daily tasks it sets off my BS detector. As the new leader of IT I know it's my butt on the line if I don't fix this issue. It becomes very clear that one guy doesn't contribute. He is not looking good on the charts, many tickets open, no activity on tickets assigned to him, everyone sees it now in measurable terms. Subsequent counseling sessions and write ups for this guy and the writing is on the wall. Other AS/400 employee gets the picture, becomes more productive, contributes to Intel support. HR is impressed; we have a documented history of poor performance for the bad apple.
An effective helpdesk is a good way to provide proof of IT value to the SMB (small/medium business) as well as a way to identify and weed out folks that are dragging down the team.
Note - I have worked with very good AS/400 staff at other companies who knew java wasn't just a drink, knew how to setup LPARS, ran apache on the 400, etc. These guys were abusing a small company that didn't understand IT.
I'd carry a hard-bound lab notebook and pen with me whereever I was to write down short notes of what I was doing and who I was doing it with. I also kept key phone #'s. I figured soon or later someone would ask me what I've been doing and I could use the notebook to write a quick report. This became a career-long work habit, invaluable during OS upgrades (what did I do), being on a help desk, and when I was writing utilities or code. Those notebooks also came in handy when I wrote up my year-end review (most managers were lazy).
It also helped me write a help desk program (Filemaker on a Mac back in the early 1990's). They used it even though it became clear that some calls would remain open or when the call queue just kept getting longer and longer.
Your fellow tech should get in their heads that if they can't answer "What have you been doing all week?" with a concise list of tasks, they probably not going to be around much longer. How they do it--old school (my lab notebook) or 21st century (IMs to a centralized database) is left as an exercise to the reader. But it has to be done.
OK, this is 2006, what is the status of speech to text? Can this logging be automated to the point where you are recording the calls and it automagically keeps both that audio record plus at least makes an attempt at a speech to text transcript? Then all the calls need is a quick categorization and a date/time stamp which can be done on the fly by the person sitting doing the help ticket. If they can't do that..why again are they there, to just collect a check for showing up? There are a lot of folks looking for work right now, we see it all the time on the outsourcing threads. My take is, in this economy, a job is better than no job.
OK, here's another one, take them off salary and put them on some sort of pay as you fix a problem deal instead. They would have to log calls then if they wanted any pay.
Go get and install Request Tracker from http://http//bestpractical.com/rt/
Step two: No one makes a move without creating a ticket for the job in RT. This works even better when the users can simply email their requests to rt@yourdomain and have the ticket automatically generated in the "new" queue.
Step two point five: share the joy of satisfaction at closing tickets in RT.
Step three: bask in the glow of happy management when you can show how busy yet efficient everyone is!
I know you said you wrote your one ticket system. I'd say swallow your pride and scrap it, and use RT. It's made our workflow really efficient, and upper mgt. loves seeing the work done laid right out. Remember, it doesn't matter how well you do a job if your boss (and his boss, and her boss!) don't know about it.
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 they could.
The problem is that ticket systems should be used to track and record problems, not serve as metrics of what people are and aren't doing. Almost always the reason that the ticketing system is getting used as a metric is because management isn't involved enough in that aspect of the business to know what happens on a weekly basis, much less a day-to-day basis. This frustrates me to no end because it benefits no one (until management is looking to do layoffs, of course).
So, while I feel your pain (I was in a very similar situation recently), I can't say that I'd behave much differently. Often I'm too busy doing my work to exactingly record every ticket. If I was recording every ticket, I'd get much less done.
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 their business. If they need more information on a ticket, they request it online as well. This way, EVERYTHING is logged, and you cut way down on time wasting interaction with users while trying to fill out a ticket.
As users discover what is involved in reporting a problem, they will cut way back on bugging you with stupid stuff, or stuff they could figure out on their own if they tried. If you are managing things correctly as far as user rights go, you can keep them from doing more harm than good.
Filling out tickets by phone opens you up to misinterpretations, unlogged calls, and stupid user interactions undocumented. By moving the whole thing online, you eliminate 90% of your problem right off the bat, and the auto-reporting will make it clear to everyone who is productive and who is not.
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."
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
There's a basic formula to keep in mind...how busy is the desk? It's simple. The average amount of notation time should be half at maximum of the average amount of time between calls. Assume that for one reason or another on-call notation is impossible. (For doing this sort of phone support you need to be totally focusing on the little things that the end user says, or you might be at their desk).
So if you're following this rule. Things should be logged. No argument there. But if this math isn't adding up, (which is usually the case), then you need to either do one of three things.
Reduce the number of calls. Don't bother trying
Hire more people.
Make the ticketing system faster. Do they have web interfaces or direct access to databases? How long does it take for a window to load? Again, speed is the key. How much detail do you want on the cases/resolutions. And so on.
If it were up to me, I'd have a simple 3-prong dialog that automatically generated a number (to give to the user), and 3 fields. User (best if this is auto-populated), Problem and resolution. Offer a lot of space if needed for those things, but allow..natch encourage quick log notation for common issues. Back-end access is necessary for pulling up previous cases. So the workflow...
1)Call comes in. Logging window appears on tech's screen, with the ID filled in. (Have an ID number typed in at the beginning of the call IVR before it reaches the tech)
2)Call is handled
3)Notes are finished, when accepted, the person is available to take the next call, and the time is stopped and recorded.
That's the ideal situation.
Its really easy if your phone system supports SMDR. Get it set up for you, setup a call accounting software package and start logging the calls. You can do some extras like assigning an ACD pilot number for the help desk, and putting all your agents in an ACD queue to balance the call load. BUt just having the call accounting their so you can on the 12th, I was called by these extensions, xxx,xxx,xxx,xxx etc for a combined total of XXX.X minutes for support, which you can cross referrence with your helpdesk ticketing software for even more info.
In my organization, we do not have a telephone number for the help desk. If someone has an emergency, they come running. Otherwise, they go to a web site dedicated to the IT department, where they log in with their domain username and password, then submit a helpdesk ticket. Once they submit the ticket, the system sends an email to all helpdesk responders notifying that a new ticket has been added.
/bit/bucket ...
The first person to pickup the ticket assigns it to himself, then must update the ticket to close it, or elevate it, or whatever. I could not get anyone to log anything when someone would call in and whoever answered would simply jump and go fix the problem. But, since now we are notified when new tickets are added, we handle it much easier. There really wasn't any problem setting it up either, and what I've found is the people who just don't get it and can't fill out the helpdesk form, which is as simple as you can get considering all the user info is supplied when they log in, they ask someone else to help them...
It may not be perfect, and it can still slip sometimes, but if you just put a board outside your office door with a web address, include it in your signatures, people will catch on, start informing your users to use this and tell them they will get speadier responses if they use it, also, if they show they have a high call volume and things aren't getting resolved quick enough, it is proof to management you need to hire more help. THe users usually really like this as it makes them feel more involved. Even if we, the BOFH's, really know their requests are simply dumping into the
"A free society is one where it is safe to be unpopular" --Adlai Stevenson
If you are unwilling to be the hard man, there is another thing you can try. If you have good relationships with your two helpers, you can let them see you take an ass-chewing for their failures.
-Your boss comes into the office while they're present, invites you into the hallway and proceeds to tear you a new one. Loudly. With appropriate threats.
I used this method a couple of times when I was in the Navy. We had some junior airmen (e1 - e3) who were resistant to obeying junior petty officers (e4, e5). They were not bad guys, they just had a little trouble getting up to speed (it was a very autocratic environment and some of the senior guys would not give reasons for their orders*. Lame, I know.) I would just arrange to have them around when I knew I was going to get an ass-chewing, and let them see.
I was not the bad guy. They could see that I was under pressure from above. I got bonus points because I took an ass-chewing they knew they had earned. Net result = better obedience coupled with better team camaraderie.
You don't want to do this too much, though. It is very manipulative, and you run the risk of looking weak. A better solution is probably a combination of technical process improvement (see other comments in this thread) and aligning their goals with those of the organization.
Good luck!
* We were loading bombs onto airplanes on the flightdeck of an aircraft carrier. There is a time for unquestioning obedience, and there is a time (most of the time!) when it is appropriate to share as much information as possible. If you are reasonable about explaining why you are giving orders when you have the time, you are much more likely to get the unquestioning obedience when you need it. This is all about getting respect by being respectable. IMHO.
You could do the childish thing and make a big board that displays the worst worker in the office. You could even make it a dart board and the center of the target is the guy's future pink slip. Or you could just talk to them and allude to potential future cutbacks in manpower. Remind them that this is the real IT world, not that big bubblegum era back in the late 90's. These are called "negative reinforcement", and as a Soldier, I see this all the goddamn time. It's the easy method of dealing with motivational issues. The more difficult, but often far more rewarding alternative is to build pride in the company. Now please bear with me as I'm going to make some comparisons to the military, but it does make sense. When a Soldier is told that he's doing things for his country, that doesn't motivate him, especially when he's not even living in that country anymore. The same goes for your company. You can try to motivate your people by building their pride in the overall company, but if this isn't a small company then you probably have offices in other cities or states, and the company is large enough that they don't know all the faces that they service. This makes pride in the company difficult to achieve and they will sacrifice integrity in the pride they have in the company. When you tell a Soldier that they should take pride in the mission, then all they see is the mission getting accomplished, not the methods used to get there. Many times this leads to compromises in personal integrity or the integrity of the office to reach a goal. Within your staff, you'll notice that they may feel that the customers are taken care of, so who honestly cares about some stupid log system just so the people that are already disconnected from them can now nitpick on their work habits? They will get the job done, but they will avoid the ticket system and compromise the integrity of the boss/employee relationship. This hurts pride in the job. When a Soldier feels that they are doing their job so that the people on their fire team don't die, then they feel a sense of pride and brotherhood, and are far less likely to sacrifice integrity of the team with which they have grown close to. So don't isolate them against each other. Don't isolate them from the company a lot, but it's alright if you do a little. You can isolate them from you, but only in that way that makes a boss a boss while still being able to maintain that direct relationship and most likely friendship. Focus on making the job something they do together and that they try to help each other improve on. I know it's not life or death for IT personnel, but you can still find the same levels of motivation if you build them up properly.
1. Tell them that you understand that logging calls will take away time from fixing things and solving problems, but as insane as that seems to them, management and yourself are actually willing to make that trade off. It's the cost of doing business.
2. Tell them the documentation generated by logging calls can be used to solve problems they have been b1tching about. If upper management can't see it on paper, then it never happened. Even if they do a great job, if it's not on paper, it never happened.
3. Make quantity of calls logged a metric worth 80% of their pay raise this year. Follow up with them every Friday to see how they are doing on this. It's not fair to make it 80% of their pay raise, not follow up on it, & kill their raise at the end of the year; they obviously need some encouragement & follow up to get it done. If things go well for the first couple of months, drop it to every other week.
4. Tell them they are free to bitch & whine about having to log calls as much as they want. Consider it a boot camp type of mentality. They are being asked to do something that from their perspective prevents them from getting the REAL job done. Let them blow some steam. It will make them feel better. They will eventually get over it.
5. Tell them to direct any complaints are heat they get for not being able to get things done, or done as fast as they want to you. And actually take the heat for it instead of them. They know people are going to get pissed when things aren't done johnny-on-the-spot.
6. They may get a little pissed and start logging every damn thing they do... like wiping their @ss. Let them do it for a while. Tell them that you would prefer that go to that extent vs. not doing the job at all.
7. Come up with a plan to deal with a backlog of problems if/when they can't get everything done. Do they get paid for overtime? Can you hire an additional person or contractor temporarily to keep up with demand? Or are you going to have to b1tch them out to work faster and make them feel like logging calls is counter productive?
8. So your wrote the call logging software yourself... could be good... but maybe a professional package might be faster to use.
9. Show them some appreciation for doing something that sucks. Drinks after work to b1tch about it. Grab a couple of cups of Starbucks. A couple of gift certificates for doing a good job.
10. Show positive results for the logging of calls. Maybe management has noticed that they really do need some anti-spyware software... or that Joe Schmoe keeps having problems but insists that he has to keep in installing Bonzi-buddy... maybe a recognition that you need more staff... or that they are under compensated for the work they do.
I used Clarify way way back in the day. We were so geared towards email as opposed to phone support that we had to author our own special email processor to manage to keep working. We'd get calls, short, long, whatever, we'd spin a quick email off to Clarify and then spend 15-30 minutes at the end of the day or early the next morning cleaning our queue. We had custom rules where it sent it to our own queue if it noticed it was a Clarify technician, or just left it in the general queue otherwise to keep queue management to a minimum.
:-D One of my pride and joys, it was my first foray into i18n to support our Japanese office.
Somewhere I still have the source to the monstrosity.
Check if your PBX supports Client (or Call) Matter Codes. It's an easy way to log 20sec calls (like resetting a password, re-enabling locked out user account) at end of the call. This way you can quickly log the call as follow-up, quick change or non-problem without consuming too much time. CMCs are not replacement for service calls. If the user has a problem that cannot be fixed during the call, a service call should be opened.
At end of the week you combine the CMC statistics from your PBX and processed trouble tickets. This way you also get number of the calls without CMCs, which you can compare to number of new service calls during same periods. If the numbers don't add up, you can start investigating the reason why no service call was logged nor CMC was used.
I'd say that it's stupid to ask the analysts open a service call in Remedy or HPSD for every password reset they do during the day - it takes more time to log the service call than to fix the problem.
If it's not possible to use CMCs ask them to keep count of the quick calls using pen and paper; list number of calls to reset password and so on. No matter which way you do, "logging" a quick call wont take more than 5 secs at end of the call.
-- Reality checks don't bounce.
We had a similar problem in a much larger department (about 350 employees supporting a user base of about 15,000) and we had issues getting helpdesk tickets logged. Sure we had all the extra work to do that was much more fun than the life-sucking, mind-numbing Luser support of the help desk but there was enough time during each call to add 5 minutes on to it to write the log.
There were several people tasked with finding out how to fix the logging problem. I was one of them. We were put into a team and had weekly meetings. We tried the usual gestapo tactics that never work and just alienated the employees and ticked everyone off. What was obvious from that was that the work was getting done and getting done quite well. Out of all the calls we would get in a month, less than 5% came back on a return call for an unfixed problem. That doesn't sound very good but check those numbers above again. 350 admins to support 15,000 users and only 5% of total calls came back. Granted, that's only what was supported and given the documenting problem, that number could be dubious but overall, even if it was fudged by 50%, that's still stellar performance from a department that even if you go just by the numbers alone is woefully over-worked.
So we tried a different approach and shut our mouths about the logging. Started talking to people candidly in breakrooms, at lunch or even stopping by a desk and starting a personal conversation. What we quickly found out was the pretty much everyone HATED the tool we used for logging calls. It was cumbersome, slow and not intuitive with a horrendous UI when you actually sat down and looked at it from a user's point of view.
Needless to say, we changed the software. Someone had suggested that we write our own but in an already over-worked group, that's like telling a one-armed paper hanger that he has to tie one arm behind his back and still hang paper. So we went with a COTS solution that seemed to work better, tested it with a control group and found it much better to work with. We rolled it out and within a month, we went from 70% of calls with undocumented updates to just under 20% of calls with undocumented updates. A 50% improvement by just changing how we did something rather than standing on the typical management premise of "The beatings will continue until morale improves."
So don't look at the people as the only source of the problem. Thier lack of documenting may be the message they are trying to tell you that the tools suck. Afterall, a carpenter could use a screw driver to cut a piece of wood but a saw works so much better!
I would review the procedure. Most of the "call logging" software I've been shown is cumbersome, requiring you to log into it ahead of time. That means keeping it open.
I prefer to use a system that opens off the start menu into a ticket. When the phone rings, you answer and ask who it is. You exchange pleasantries with the person, and reach for Start -> Ticketmaster (or whatever your software is called). It opens as a new ticket, where you enter the name of the person and write one sentence about the problem. End-of-documentation. Hit save. It should already know who you are; it's your desk. If you need to change the default because you're sitting at someone else's desk, there's a drop-down you can use to change the default. (And changing the drop-down changes the default, so your next ticket is defaulted for you sitting at the desk.) Do you really need mega-security for entering logs of what you did?
Save brings the ticket up in "edit" mode. Here, you write down anything you need to take notes on. Account number? Server name? Phone number? If it used to go on a piece of paper, it goes on the handy ticket. It doesn't have to make sense; it's just a notepad.
Later, when you're closing the ticket, you edit all those notes into a short, "formal" writeup.
Systems that have dozens of fields might be good for reporting, but they score badly on "usability". If you need the calls split into fields, have an expert take the raw, logged calls and fill in your fields. It's both more efficient and produces more accurate reporting.
In theory, there's no difference between theory and practice. In practice, there's a big difference.
mod the ticketing system (or upgrade or replace, whatever) such that a ticket cannot be closed without sufficient documentation on the problem.
they've gotta write *something* in there, it's a good first step.
you can make as many required fields as you need to capture the information you want.
who was served (or maybe this is already the employee who opened the ticket)
what kind of problem was it
how was it resolved
etc.
if you aren't getting enough detail in one of the fields, replace it with a drop down list. better yet, replace it with a bad, incomplete drop down list and an "other" field. nothing encourages a geek to provide detailed feedback better than a list of incorrect choices.
don't bother trying to convince your employees to change their behavior. invent a robot to do it for you.