What’s the difference between an incident and a ticket? On the surface, this feels like an odd question and not one you would usually hear around the IT table. You could argue that the incident (or issue) is what the end-user experiences. Whereas the ticket is the IT service management (ITSM) tool’s mechanism for resolving the incident. This differentiation can cause IT support issues – for example, when a service desk agent is focused on closing the ticket rather than fixing the end-users incident. But it also makes it easier for IT service desks to understand the actual costs of IT support when a ticket, rather than an incident, view is taken.
A simple example of this is a hard drive failure. The incident cost can be viewed as related to the business issue itself, so when a laptop hard drive fails, and you need to replace the laptop, the cost of the incident is perhaps seen as the £1,200 you spend on a new computer. However, this view overlooks elements contributing to the overall cost of handling the ticket.
So, what’s the total ticket cost for your IT service desk? And how can you calculate it?
First, let’s look at the service desk agent time. Perhaps it took three hours of end-user engagement and troubleshooting to establish that the laptop’s hard drive was dead. Then it took another hour for the purchasing processes to be followed and another two hours to configure, test, and release the new laptop once it arrived. So in total, we have six hours of IT’s time, and if we price that at £50 an hour, then that’s an extra £300 on top of the replacement laptop cost.
Next, we have the lost work time for the employee whose laptop got fried. Let’s say that from when their laptop failed to when they returned to practical work, they lost seventeen hours of productivity. So again, “finger in the air” at £50 an hour, we have now lost a further £850 to this ticket. So, in total, this could be a £2,350 ticket. Nearly double the recognized incident cost. Ouch!
Why is it beneficial to understand the IT service desk cost per ticket?
I appreciate that things are never as straightforward as one hour = £50 in business value. Sometimes it will be more, sometimes less. However, it’s essential to have a measure in place (even a basic one) to start understanding the business value created and lost by having a timely and effective approach to incident management.
As any good service organization knows, the main reason for having data like this is to prioritize and manage your approach to improvement. Data such as how much incident type A costs the business vs. incident type B allows you to prioritize your opportunities for service improvement based on the real risks and costs to the company and IT.
What improvements can you make when you have this level of data?
When you work this way, you quickly start to see trends you had likely never thought of or seen before. For example, something as simple as fixing a recurring issue with a printer. A new office printer might cost £1000, so if you can show that not replacing the printer costs the business more than £1000 in lost work hours, both within IT and to the users of that printer, the case to replace it just became a lot stronger.
A more complex scenario might be calculating how much time is lost to resolving a specific issue within a set of applications. For example, let’s say you work at an engineering firm, and IT has to visit the design team 3-4 times a week to help overcome an issue with rendering images. On the surface, this might feel like a blip in the day-to-day life of IT. And I suspect we all know how easy it can be for a reactive style of problem management to become routine.
However, look at the data, understand the cost created by the issue, and the strain caused by that one application fault starts to look more significant than you initially thought. And so then, the training required or the upgrade needed to resolve the issue (for good) now starts to look like the favorable option, which is not only a cost saving but a significant enabler for that design team and the overall workflow involved with rendering their designs.
How do you get started on improving in this area?
Establishing some end-user experience baseline data or a benchmark to work from is important. At HappySignals, we have collected data from millions of IT service desk tickets to create accurate benchmark data, which is publicly available on our website.
Once you start to generate some benchmarks of a reasonable cost for a ticket in your organization, you can regularly look at the tickets that exceed your set baseline. It’s always easier to assess this data as a team, as you want to compare the transactional data with people’s actual experiences in such a way that adds context to the issues you are working to solve and trends you are trying to find.
From there, you’ll need to adopt or establish some basic continual improvement techniques to start logging how these trends, problems, and reoccurring costs can be addressed and the relative priority.
Learn more about how HappySignals can help you better understand where your service is winning and losing business value, time, and money by signing up for a free demo today.
