Tech support, as many of you know, can be a grueling job. There are a huge variety of problems, from frozen screens to document formatting issues to malware infestations to video display madness. There are days when you are swamped with tickets. I’ve done tech support and I’ve managed tech support for most of my career, and providing good support isn’t the biggest challenge. Rather, it’s keeping the tech support staff from going over the edge.
It would be natural to assume that having good metrics on everything help desk would assist me in solving these problems. Good metrics might inform me regarding the proper staffing levels, the types of expertise needed, the gaps in our application suites, all that good stuff that can support my budgeting and strategy. But once I start collecting them I open myself up to that imminent threat that someone else in management (my boss, the board, or whomever) might want to see the metric, too. They want to see are metrics like:
Their idea is that these numbers will tell them how productive the tech support staff are, how efficient, and how successful they are at resolving problems.
Every one of these is a unreliable metric. Alone or together, they don’t tell a meaningful story. Let’s take them one by one:
This is a number that is allegedly meaningful as it rises and falls. If we have 30 tickets a day in January, and 50 a day in February, it means something. But what? Does it mean that IT is being more productive? Does it imply that there are more issues popping up? Is it because more people are feeling comfortable about calling the help desk? If we drop to 15 in February, what does that mean? That IT has stabilized a lot of problems, or that the users have figured out that others in the org are more helpful than IT?
The standard assumption is that fewer is better. And while that is generally true, it can be deceiving, because the nature of tickets varies dramatically. Some require budget approvals and other time-consuming delays. An assumption that tickets are open because the technician hasn’t gotten around to resolving them is often wrong.
This one is deadly because it is commonly used as a performance metric, and that’s based on the assumption that the quicker all tickets are closed, the better service IT is providing. The common scenario I’ve encountered where this metric is shared with management is that the tech support staff grow so pressured to close tickets that they regularly close them before the issue is truly resolved. It creates tension with staff, as the real power of a help desk ticketing system is in the communication that it enables, not the communication that it cuts off when staff are not geared toward taking a communicative approach to issue resolution.
Worse, it takes away the technician’s ability to prioritize. Every ticket must be closed quickly in order to look efficient, so every ticket is a priority. But, in fact, many tickets aren’t high priority at all. People often want to report computer problems that they aren’t in a hurry to get resolved. When every ticket is treated like a fire to be put out, staff, naturally, start getting resistant to shouting “fire”, and stop reporting that annoying pop-up error that they get every time they log in. They start living with all of the little things that are inconvenient but bearable, and as these pile up, they grow more and more annoyed with their computers — and tech support.
So what might useful metrics to assess the effectiveness of tech support entail? Here’s what I look for:
The type of person that gravitates to a tech support job is a person that likes to help. There are egos involved, and an accompanying love of solving puzzles, but the job satisfaction comes from solving problems, and that’s exactly what we want our support staff to do. Creating an environment where the pressure is higher to close tickets than it is to resolve them is a lose-lose scenario for everyone.
Photo: birgerking
