Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Bug Businesses

Improving Operations in a Small Helpdesk System? 110

Posted by Cliff 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.

Improving Operations in a Small Helpdesk System? More

Improving Operations in a Small Helpdesk System?

Comments Filter:

  • Bring down the hammer. (Score:5, Insightful)

    by PhxBlue ( 562201 ) on Tuesday December 26, 2006 @03:37PM (#17369246) Homepage Journal

    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)

      by PhxBlue ( 562201 )

      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)

        by tacarat ( 696339 )
        In more real terms, explain that raises and getting more people (essential for taking vacations) are based off of these reports. As mentioned earlier, you can also explain who the boss is. There are non-confrontational ways of doing it, and you should consider what you say carefully to avoid "hurt feelings" because they get defensive or puff up their pride.

        Or you could link this article and point at them. "That's you".

      • Re: (Score:1)

        by Blikkie ( 569039 )

        I do in-house helpdesking work quite often and believe it or not, logging what you've done is useful, so break that in their brains. Not only from an ITIL kind of workflow, where an IT department has to document their work in order to get their funding, but it can help in problem solving as well. If someone says that he had that problem 5 months ago, you can just look up the solution from that time, instead of solving that again, and now I don't even mention continuity. What if the IT department drives down

        • My company is iSeries based so we use Aldon because it integrates tickets and codemanagement... you can check out code against a ticket kind of like Bugzilla. My trouble is getting people to write GOOD tickets! Like you, I was one of the first in my company to try to embrace it, and do it right and really "get" that you can use the ticket system to troubleshoot calls and save time, that makes it stop being a meaningless paperwork task and something that actually makes you better at your job... my problem

    • Re:Bring down the hammer. (Score:4, Informative)

      by TheWanderingHermit ( 513872 ) on Tuesday December 26, 2006 @03:44PM (#17369324)
      There's a time to be a buddy, and there's a time to be a boss.

      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.
      • I never was a big fan of documentation - until I worked in an environment where 5 tickets a month were randomly pulled and audited. If enough of your tickets didn't meet department standards, then your supervisor was notified; enough write ups and you were fired. This was only at a tier 1 level though, as tier two had already proven themselves. The main reason Tier 1 needs to be so explicit (step 1, remoted to pc. step 2, renamed user's profile. 3. had user log back in and verified profile was recreated

      • Re: (Score:2)

        by kjs3 ( 601225 )
        if you've got an employee that does 90% of the job well, then you're damned lucky

        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)

          by silas_moeckel ( 234313 )
          Funny run a small consulting company though a midsized company CTO and I would have to wonder if it makes sense to fire the hotshot. If they generate billable hours and the customers love them it sounds like they need an assistant to deal with paperwork drudgery. I would rather add on 30k of salary expense for a low end secretary to deal with time reporting than loose a top gun guy. Technical documentation is a different story as it's billable but can still be given to a jr person to do.

          • Re: (Score:3, Insightful)

            by kjs3 ( 601225 )
            Frankly, this is utter rubbish. You've clearly never had P&L responsibility. I'm supposed to take 30k profit out (obviously much more with loaded costs) just because I've got someone who can't be bothered to account for their time? Right.

            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

            • The 30k unloaded costs is for a low level admin to get the documentation out of the whole team of 20+. I'm talking about actual engineers billing out at 250+ an hour not break and fix or I'll configure your single ms exchange server today guys. The admin provides that nag factor, sure some hot shots will not even respond to that but the point is to insulate your high priced people from doing mundane functions. The ones that do not respond may have to leave or be moved to a 1099 sub, nothing motives time

              • Re: (Score:2)

                by kjs3 ( 601225 )
                Forgive me, I was a bit strident there. Obviously, you don't assign admins 1-to-1, you've probably had a P&L responsibility, and we certainly agree on some things (good admins are a perk and worth much coin to a team).

                That said, I stand by my personal, direct experience that the guy who won't do something for his manager, because it's his job, won't do it for the admin. And while moving them to 1099 might seem to be the way to deal with it, I've found that in practice (dealing with hundreds of extrav

        • It's always possible to tie in raises and job performance evals with the documentation. If it's not documented, it wasn't done. But then, I'm a pain that way. The pass/fail rubric they're using for you is absurd, doesn't serve you or the company, and is something I'd never tolerate, but that helps only me and my people. I want to make sure I'm working with people that know what they're doing, but can be flexible according to the situation, but I'm also a pain about some things, like documentation of wha
      • Mod up Hermit's comment.

        I would guess that the best people hit around 90 percent. Redundant systems provide the difference between 90 and 100 percent.

        Helpdesk documentation helps move the department towards 100 percent.

        I'd also add that thorough documentation is essential for identifying patterns, especially if you're dealing with older machines.

        Which machines are chronic problems?
        What time of day does the machine turn weird?
        What users have the touch of death - whatever machine they use, breaks down?
        W
    • 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.
      That's is the best advice you'll ever get

      ... and part of your job is to motivate your people. Otherwise (sadly) you may find that you're the first one to get chopped. While it's nice to have a small team that all get on together and to have your subordinates like you, don't let this become the dominant feature of your team. Once

    • Re: (Score:1)

      by izm ( 592666 )
      How tedious is it to log every call? I know with Remedy help desk, a ticket will take 5 minutes to write at the least, and if you are logging and then resolving a ticket, you need to write it, submit it, then go into the queue and close it. 10 minutes down the drain. A big deterrent for Help Desk people towards logging every single call is that often times a simple password reset (which is recorded in logs anyway), or a case of user error doesn't seem to warrant a ticket because it would take longer to wri

      • Re: (Score:3, Insightful)

        by itwerx ( 165526 )
        I know with Remedy help desk, a ticket will take 5 minutes...

        That's more of a reflection on how badly Remedy sucks than anything else. :)
      • two issues with that:

        first, those "two minute" calls really add up.. having a lot of them shows that your staff does something during the day... even if it's just answer the phone for a user, sometimes you have to get it on paper to prove to management.

        Second, tickets for your department should be habit, part of workflow, not against it! The system should "lead" you thru the work to be done and all the steps.. the goal of a good system should be to make it EASIER to do it the right way, using the syste

      • Believe it or not, Remedy is the best tracking software I've used as a Tier 1 Help Desk Analyst. It takes awhile, but it's thorough. If you're on a desk where you get back-to-back calls I admit it kind of, sucks, but it helps the analyst cover their butt and gives management a good picture of what's going on.

    • Re: (Score:1)

      by kyliaar ( 192847 )
      You don't need to bring in the Big Damn Hammer(TM) the first time you bring this up for someone.

      There needs to be a progressive counseling approach on this.

      First step, make people aware of things and the way they need to be and why.

      Second step, do an inspection at some in the near future and bring up any problems found to the person directly in a semi-formal, verbal warning style.

      If things progress further, your company probably has a written warning policy in place and further counseling steps all leading
  • 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.

  • Be straight with them (Score:3, Insightful)

    by Rastl ( 955935 ) on Tuesday December 26, 2006 @03:40PM (#17369274) Journal
    Are they aware that the call logs are one of the few objective measures of productivity for your department?

    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.

    • The peoblem is lack of perceived value. You're combating "Why bother logging it, it's fixed now anyway?" - or to put it another way "What's in it for me?"

      Tell your staff what you're trying to get for them (more hands? more budget? more ThinkGeek toys?), and let them know that logging calls will convince the Big Boss that you really do need it.

      Posting stats is a great idea. Throw in some competition, and then you've got an inventive. To start, how about an award/bonus/go home early prize for the most [legit]
    • 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."


      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.

    • "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.

    • Re: (Score:2)

      by ocbwilg ( 259828 )
      Are they aware that the call logs are one of the few objective measures of productivity for your department?

      If not, make them aware. Charts hanging on the wall will reinforce that a bit in the beginning.

      Especially if those charts have lines showing the number of tickets/calls that each member of the team fielded, broken down by team member. When the big fat zero is hanging on the wall staring them in the eyes, and they know that anybody walking by can see it, they will start documenting.

      We had a s
  • 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...
    • Getting people to see the use in something doesn't mean that they'll do it. Plenty of people see the use in having a reasonable amount of personal savings (or backing up their data), but look at how few actually do.
  • 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.

    • Re: (Score:1, Offtopic)

      by NateTech ( 50881 )
      As soon as you start down that slope, people will only work to the level dictated by the metrics.

  • Two ideas (Score:5, Informative)

    by imidan ( 559239 ) on Tuesday December 26, 2006 @03:50PM (#17369384)
    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.

    • Re:Two ideas (Score:4, Interesting)

      by martyb ( 196687 ) on Tuesday December 26, 2006 @06:57PM (#17371154)

      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?

      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:

      1. StartTicket implement a small program whose sole task is to log the start of a ticket. Record: Date, Time, Caller, Technician, Severity, Short Description

        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.

      2. LogAnActivity Simply record a text or voice update to the current task. Along with the current date, time, and tech.
      3. StopTicket Again, implement a small wrapper program which captures the information you need. Date, Time, resolution, followup required.
      4. Write a TASK utility that uses these wrappers.
        1. invokes the StartTicket wrapper,
        2. opens a new shell / window,
        3. tech uses shell to perform requested action; all shell output is logged to a log file whose name is based on the tech's name and the current date time in ISO-8601 format. Take a look at Date (Unix) [wikipedia.org] for details. Don't have a unix date command on your system? Take a look at the GNU utilities for Win32 [sourceforge.net]. So, now you can construct an easily sortable date/time stamp;

          export right_now = $(date "+%%Y%%m%%dT%%H%%M%%SZ")

          or, under windows:

          SET UnxUtils=C:\TOOLS\UNXUTILS\USR\LOCAL\WBIN

          COPY CON: right_now.bat
          %UnxUtils%\date "+SET right_now=%%Y%%m%%dT%%H%%M%%SZ" > %TEMP%\right_now2.bat
          CALL %TEMP%\right_now2.bat
          ^Z

          right_now

          I just ran it on my PC and got:

          right_now=20061226T175320Z

        4. tech closes the shell / window
        5. on shell close, invoke the LogAnActivity wrapper
        6. invoke the StopTicket wrapper.
      5. Permeate your workflow Leverage these wrappers as a framework and as it becomes clear, write other TASK wrappers as needed.

      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

  • Take charge (Score:2, Funny)

    by sinij ( 911942 )
    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.

    • Re:Take charge (Score:4, Funny)

      by p!ssa ( 660270 ) * on Tuesday December 26, 2006 @04:16PM (#17369622)
      Yes, good point, dont forget to nail a kitten to a board and strangle it in front of them too. Dont kill it, just let it pass out... and stangle it again after you poke it in the eyes with needles to wake it. Keep repeating this until one of the weaker employees cry (it may take a while or require multiple kittens if they are used to abusive callers), then lock the kitten in a dark box with no food or water, leave it close enough to thier work area that they can always hear the muffled crying. The key is to let them know there will be alot of pain but no death, morale and productivity will sky rocket. You will most likly get a bonus when the CxO's get news of your "Balanced Kitten Card (tm)" management methodology. The kitten will make for great holiday cards too, remind them again and again at easter etc., 1 kitten can go a long way. If that doesnt work, just shoot them in the face.

      Best Regards & Happy Holidays,
      Dick Cheney
  • 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.

    • Re: (Score:3, Interesting)

      by CaymanIslandCarpedie ( 868408 )
      Another way to do this which has helped me tons, is to get away from using phones ;-) Our help desk would recieve requests via phone, email, IM, or just stoping by in person. Performance matrix weren't an issue, but just keeping track of all the tasks was a nightmare and I was too busy to be logging everything properly.

      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: (Score:1)

        by MrEkted ( 764569 )
        Ditto that! We simply made it clear to our customers (the other departments) that phone calls would be handled at a lower priority than email. All email goes to helpdesk, and therefore is logged. The phones hardly ever ring now, and the environment still feels supported because a helpdesk email gets answered within seconds.

      • Re:change their phones (Score:4, Insightful)

        by citking ( 551907 ) <jay.citking@net> on Tuesday December 26, 2006 @07:37PM (#17371626) Homepage
        I can't agree with this more.

        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 .asp scripts in place on our web server. One of these scripts is hooked into AD and sits on the Outlook Web Access login page. If someone needs help, their name/dept/phone/etc is all filled in for them and all they have to do is say what's not working. This keeps the person from having to fill in too much (which means they'll sometimes spend a bit more time on details rather than just saying "e-mail don't work."), it gives us accurate information, and it's conveniently located right below the login box!

        -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!
  • There's a simple answer, even if it includes a conditional:

    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
  • 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 fig

  • Your softwqre is letting you down (Score:3, Insightful)

    by Gorm the DBA ( 581373 ) on Tuesday December 26, 2006 @04:08PM (#17369554) Journal
    Find out why they aren't logging.

    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.

    • 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.
      • 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 q
  • 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
  • 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.

  • If management asks, you must deliver (Score:3, Insightful)

    by farker haiku ( 883529 ) on Tuesday December 26, 2006 @04:11PM (#17369580) Journal
    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.

  • 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 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 activiti
  • 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.

    • Re: (Score:2)

      by Knara ( 9377 )

      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."

      • No, because that affects everybody equally. Also, if you lower the call volume, that'd be taken into account.

        As Professor Harold Hill once said, "Now think, boys, think!"

        • Re: (Score:2)

          by Knara ( 9377 )
          I think you're giving management a little too much credit by assuming they'd put both those "1"s together and get "2".
          • My idea was that as the manager of the helpdesk you'd be doing the evaluations. If so, you can not only adjust for changes to the call volume, you can improve the rating of whoever came up with a way to lower it.

  • Alternatively, you could face facts (Score:4, Interesting)

    by $RANDOMLUSER ( 804576 ) on Tuesday December 26, 2006 @04:24PM (#17369706)
    "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.
    • Good answer but it doesn't seem appropriate to this case.
      You just simply don't take the next call until the current call is logged. The call queue times will increase, but that's to be expected. If they're too busy, charts and graphs isn't going to help them staff up. But a VP waiting on the phone an extra few minutes will. Thats the point where you need to have the numbers to back things up. If they're not so busy that the queue times rise, then they're not too busy to log calls.

      • Re: (Score:2)

        by Knara ( 9377 )
        Actually, rotating phone coverage I've seen work great in a number of organizations. If there isn't a dedicated tier-1 incoming call screen in front of the hands-on techs, divvying up the phone coverage allows time for people to actually get things done (not to mention take a breather from having to talk to users).
  • 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/ [oneorzero.com] (GPL'd)

  • Auto-create trouble ticket upon phone call (Score:3, Interesting)

    by falzbro ( 468756 ) on Tuesday December 26, 2006 @04:34PM (#17369792) Homepage
    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 [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
  • Productivity of helpdesks across the nation plummets while everyone scrambles to put their $0.02 into this thread.
  • 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 havin
  • 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 Goo
  • 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
  • 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 unoffi

    • Re: (Score:2)

      by Knara ( 9377 )
      Pretty much. Some managers are very concerned with making sure that every minute of every day is going towards some project. Some places are now realizing that the project getting done by a certain date is the key, but *how* it goes done doesn't need to be explicitly railroaded. Granted it takes a strong team lead / supervisor to explain to upper management that doing metrics is no excuse for management that knows whats going on in their area, but that requires _effort_, unlike excel spreadsheets that ca
  • Base part of their salary on the helpdesk software statistics.

     

    • Re: (Score:2)

      by Knara ( 9377 )
      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.
      • Ehm. Base it on relative numbers rather than absolute numbers. Clearly you haven't done percentages in your math class yet.

         

        • Re: (Score:2)

          by Knara ( 9377 )
          As I said to the other guy, I think you place far too much confidence in management's ability to implement such a thing.

  • Get the customers to log the calls (Score:3, Interesting)

    by Marcion ( 876801 ) on Tuesday December 26, 2006 @05:48PM (#17370480) Homepage Journal
    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.

    • Re: (Score:2)

      by Knara ( 9377 )

      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

  • 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.
  • 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 w

    • 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.

      We're forced to do the same thing (logging calls). The question is do yo

  • 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
  • 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

  • Well... (Score:2)

    by Knara ( 9377 )

    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

  • Cant win the game? Change the game!

    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)

      by Knara ( 9377 )

      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

      • Tell ya what; Any company that would not agree to go this route, I would leave.

        Why push a boulder uphill? Very dumb to not force users to generate their own tickets. I actually agree with having a single person from a department fill out the tickets, as long as the system schema differentiates between ORIGINATOR and ENDUSER on the web form.

  • 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,
  • 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
  • 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.

    The first person to pickup the ticket assigns it to himself, then must update the ticket to close it, or elevat
  • 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,
  • 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 motivat
  • 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.
  • 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 tr
  • 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 w
  • 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 pro
  • 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. b

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close