It’s hard to believe that it has been almost a decade, but a while back I was in charge of an IT help desk for a 500+ employee organization. I was cleaning up some old files and ran across reports that I produced during my time as the help desk coordinator. Reading back through my old reports got me thinking – what kinds of conclusions could be drawn from the data I had been gathering?
Ticket data I gathered included:
- Date and time request was *entered* into the system
- Location of the requester/trouble
- Technician assigned to the ticket
- Current status of the ticket
- Completion date of the ticket
- Technician who completed the ticket
- Category and subcategory of the ticket
In its entirety, I had data associated with 15,799 tickets that spanned nearly a decade. As I picked through the data I was able to see how many tickets were created each day, which locations had the most requests, which technicians closed the most tickets, what the busiest time of day was, and which technicians had the “fastest” close rate.
But none of those conclusions are meaningful!
The data I gathered had several flaws. First, I could only see when each request was entered into the ticket system. Because tickets could only be entered by the help desk – employees could not submit their own tickets – there is no way to determine when help was actually requested. For this reason, any conclusions about timeliness of service are moot. This also means that the “busiest” time of day – between 7 and 9 a.m. – only meant that the highest number of tickets were entered at that time, not that the most requests came through at that time. So there can be no conclusions about what really was the busiest time of day. The data I gathered also represented *only* requests for help that reached ticket status. Speaking from personal experience, there were many requests that were 1) taken care of immediately by the Help Desk, or 2) passed along verbally or through email rather than the ticket system, or 3) some other reason why a ticket wasn’t created. So it’s not even a complete record of all requests, only tickets created. I also found that as staff members left the organization their tickets were deleted from the system, so over the span of nearly 10 years I’d be willing to bet that many tickets never made it into the final data I was reviewing.
So what’s the point of all this?
I’m not just telling a story about how I wasted about eight hours on a bunch of old help desk data. If you run a help desk, or are thinking about starting a help desk, this is a cautionary tale in two ways. First, if you collect data, make sure that you’re drawing meaningful conclusions from it. Tickets entered may not represent requests for help received, etc. And second, if you aren’t collecting data, then maybe it’s time to start collecting meaningful data. Without it, you have no way to measure whether you’re doing a good job or not. We definitely fell into the subjectivity trap during my tenure at the help desk.
All of this leads me to my suggestions for meaningful Key Performance Indicators for a help desk.
Are your customers satisfied?
Waaaaaaait a second! I thought this was supposed to be about measurement and objectivity!
Well, it is. Satisfaction will always be subjective, but at the very least there should be some feedback received from the customer to determine whether they were satisfied with the service they received or not.
Case in point: Pete the Pizzamaker. I promise, this all make sense in a second…
Pete the Pizzamaker lives on the Domino’s website and appears after you place an order for delivery. While you wait for your pie to be delivered, Pete shows you where you are in the process. He tells you who is prepping your pizza, who put your pizza in the oven, who performed the quality check, and who will be showing up at your door.
Pete also asks several satisfaction-based questions:
- how likely are you to recommend them?
- how was the online ordering experience?
- was your delivery person polite and punctual?
- how was the quality of the food?
They also offer a text box for other comments and a phone number to contact the local store for urgent matters.
Believe me, when I order a pizza I fill out their form. Even when I have a bad experience, I get some satisfaction out of filling out the form. Does anyone actually read it? I have no idea. But I don’t know what I would do without Pete the Pizzamaker, and Domino’s is asking the right question: are their customers satisfied?
As an IT help desk, are your customers satisfied?
What constitutes a job well done?
Externally, it’s feedback from the customers stating that the job was well done. This is where you need a Pete the Pizzamaker, but for your IT department. Do clients know who is helping them, when to expect help to arrive, and do they have a channel for sending feedback? But internally – and I think this is where most KPIs are pointed – we have to be able to determine whether processes are working optimally or not. Let’s start at the beginning of the process and work out from there.
For the help desk, a contact is any incoming communication. It could be a phone call, an email, an instant message, a social media message, or a face-to-face visit. All of these should be logged. No, you don’t have to record “water cooler” chatter or idle conversation. But when customers reach out to the help desk, it’s a contact. Record the date/time and the sender. Why do you need to log contacts? So that you can distinguish between contacts and…
…requests for help. A contact becomes a request for help when a specific issue is identified. Requests for help fall into a taxonomy of categories and subcategories…is it hardware or software? On-premises server or cloud-based? Desktop, laptop, tablet, or phone? You already logged the date/time and the sender, so now you’re simply waving a magic wand and turning a contact into an official request for help. In addition to assigning a category/subcategory, you need to assign someone to provide the assistance. You also need to record the details of the request so that the problem (and the future solution) can be added to a knowledge base.
A technician is now assigned to the ticket. Hopefully your ticket system allows some communication between the technician and the requester. This is where the technician can let the requester know when to expect assistance…think of Pete the Pizzamaker. Pete says the Joe put the pizza in the oven at 5 p.m. Pete says that Suzie performed the quality check at 5:10 p.m. Pete says that Billy left the store with your pizza at 5:15 p.m. Likewise, your customer should know when the ticket has been entered, when the technician was assigned to the ticket, and when assistance will be arriving. Be like Pete.
If there are obstacles that could prevent speedy troubleshooting, this is where they need to be identified and logged. Is there travel time? Do certain locations only receive service according to a particular schedule?
Once help has arrived and the problem has been solved, it’s time to log a resolution to the request. “Problem X was solved by technician Y by doing Z.” Again, a date/time entry must be made.
I already talked about this – see Pete the Pizzamaker. But add into the mix a date/time entry for feedback as well. What if the feedback says the job wasn’t done right? You’ll need to go back to the beginning and make sure that the issue was properly documented in the Requests step, and that troubleshooting was correctly performed.
If all of those steps are performed correctly, then internally you have done a good job and you should have KPIs that reflect your efficiency:
- smallest possible gap between contact and resolution, taking into account any obstacles like travel time, scheduling difficulties, etc.
- ratio of tickets assigned to tickets closed by technician – is anyone having trouble with their areas of responsibility?
- number of tickets that had to be reopened after resolution – similarly, is anyone having trouble completing work accurately?
- ratio of contacts to requests – is the help desk answering a lot of unnecessary calls, emails, etc.?
- busiest time of day for contacts – make sure staffing is in place to handle heaviest load.
There are plenty of other KPIs to use…the more meaningful data you gather, the more meaningful conclusions you can draw. But don’t assume that your current KPIs are providing you with meaningful information!