Working around the process
Ziggi, the writer over at Help Desk Talk posted a follow up to a comment I had left over there earlier in the day, and I had a few more thoughts on the subject on help desk folks working around a process that doesn’t fit what we’re trying to accomplish.
One, this is one of the obvious problems with having metrics to measure the “success” of your help desk that your help desk folks don’t have input into. I’ve yet to find a ticketing system that accounts for all the work we do effectively. There are always projects or activities that don’t have a corresponding “ticket”. For example, something like getting a pool laptop patched takes time and resources, but since our ticketing system is based on “user” requests, it doesn’t fit. So if they’re using just tickets closed as the metric to measure help desk folks in our case, as the guy who’s responsible to make sure our laptops get updates, they’re missing a lot of the work I do.
The flip side of that, naturally, is that if someone were to decide to measure me solely on the number of tickets I close, guess what I’m not going to spend any time doing? Getting laptops updated, or any other project that keeps me away from working user issues that are documented.
Secondly are the processes we simply work around. Not necessarily things that don’t fit the metrics, but cases where we do something contradictory to the established processes because the processes don’t work. That’s a problem that occurs in many places because, again, management decides what the correct process is to be, without ever asking their help desk folks whether the processes make sense. You’ve all seen those I’m sure, the cases where a user simply needs to do something, doesn’t have rights, and the established process is to have them email the network admin explaining why they need those rights, so that he can check with the CTO as to whether to grant them and then get back to the user with a response, but the reality is that they just need those rights to do one simple thing that needs to be done right now, so your help desk folks just do it for them and don’t document any of it.
Luckily, for me, we don’t just use ticketing metrics to measure the work done by the help desk folks. Unluckily for me, there’s no concrete measurement to know how I’m doing at any particular time. I really have to rely on management feedback to know. Depending on your manager, that could be problematic.
Some managers don’t really know what goes on at their help desk. Some rely solely on user feedback to determine how their support folks are doing. That makes no sense. Users are always more likely to contact management to complain than to praise. That’s just human nature. Plus, helping users is the job. Most users accept the help but feel no need to contact your manager when you “do your job” 100 times. But fail to satisfy them one time, and they sure will.
Really, my point here is that measuring the efficiency of internal help desk folks is very difficult. You need a ticketing system to get some, but not all, of an idea of what they’re dealing with. You need to communicate with them about what processes make sense an which don’t, you need to empower them to work around the things that don’t make sense, you need to know the users as well as they do so you know what “complaints” are valid and which aren’t, you need to give them ownership of the whole process, and you need to be acutely aware of not burning them out. (Which may be impossible, but is a subject for another post)
BTW, I haven’t seen all of that in a job or manager yet. It may not exist.
Follow these topics: HelpDesk
As a field services person myself, I agree about difficulties in measuring performance of support personnel. IMO, ticketing system must be combined with user and peer feedback.
Number of tickets closed, on its own, is a poor measure. It says nothing about quality of support, only how good you are in getting rid of people with problems.
Within the ticketing system, several parameters need to be considered, like number of tickets handled, number of tickets closed, number of tickets closed with unresolved issues, amount of time spent on tickets, severity of issue, etc.
There is no one factor that can show efficiency/effectiveness in its entirety.
I think you were very close to the mark here. Some things are impossible to measure. But quite often the metrics become much more important in the system than what is to be measured, what should be measured, and what can be measured.
Some metrics become so tight and restrictive that they can handcuff a staffer or at a minimum place them in the chronic dilemma of- Should I do what can be measured or should I do what needs to be done? It’s almost a loose-loose self prophecy.
Sounds supiciously like what I wrote in KM Metrics, January 2002:
. If you’re in a helpdesk or call center, for example, and you’re measuring your people on the number of calls they’re taking, that’s what they’re going to do – take calls.
(the URL will change later this week as I move from Blogger to WordPress)
anil’s comment is 100% correct, though we often found that those who were consistantly closing the highest number of tickets were almost always the support specialsts who were also the best at both technical competance and customer interaction. Maybe something about the cream rising to the top?
updated URL: Knowledge Management Metrics
Steven,
The metric does measure something, so it’s not necessarily surprising that the best performers would more than likely close the most tickets. In any situation there is value is a simple metric like that, but there’s more value in having that simple metric be part of a larger evaluation process. Like you said, when it’s as simple as closing tickets, that’s what we’ll do, even when that’s not the most useful thing to do.