What is 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.
The cost of an incident can be related to the business issue itself, so if a laptop hard drive fails and you need to replace the laptop, the cost of the incident is the £1,200 you spend on a new computer. However, the often overlooked value is the overall cost of the ticket.
First of all, let’s look at the agent time. So perhaps it took 3 hours of trouble shooting to establish that the hard drive was indeed dead. Then it took another 1 hour for all the purchasing processes to be followed and then another 2 hours to configure, test and release the new laptop once it arrived. So in total we have 6 hours of IT’s time, if we price that at £100 an hour, then that is now an extra £600 on top of our replacement laptop.
Next, we have lost work time from the employee who’s laptop got fried. Let’s say from the moment their laptop failed to the moment they got back to useful work, that person lost 17 hours. It is quite likely that this also creates further delays to other people’s work and projects… but that’s another blog post, for another time! So again, ‘finger in the air’ at £100 an hour, we have now lost a further £1,700 to this ticket. So in total, this could actually be a £2,900 ticket. Ouch!
Why is it useful to understand the Service Desk cost per ticket?
I appreciate that things are never as straight forward as 1 hour = £100 in business value. Sometimes it will be a lot more, sometimes a lot less. However, it is important to have a measure in place (even a basic one) in order to start understanding the business value created and lost by having a timely and effective approach to incident management.
As any good service organisation should be, the main reason for having data like this is in order to prioritise and manage your approach to improvement. Data such as how much is incident type A vs incident type B costing the business, allows you to prioritise your ideas and opportunities for service improvements based on real risks and costs to the business and IT.
What sort of improvements can you make when you have this level of data?
When you work this way, you quickly start to see trends that you had quite likely never thought of or seen before. For example, something simple such as fixing a recurring issue with a printer. A new printer might cost £1000, so if you can evidence that not replacing the printer actually 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 of it, 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 to problem management to just become routine.
However, look at the data, understand the cost created by it and the strain caused by that one application fault starts to look more significant that you thought. And so then, the training required or the upgrade needed to resolve the issue for good, now starts to look like the favourable option, which is not only now a cost saving but a huge enabler for that design team and the overall workflow involved with rendering their designs.
How can you get started on improving in this area?
It’s important to establish some baseline data or a benchmark to work from. At HappySignals we have collected data from over 100,000 service desk tickets in order to create some extremely accurate benchmark data, which is publicly available from our website.
Once you have started to generate some benchmarks of what an appropriate cost is for a ticket in your organisation, you then need to regularly look at the tickets which exceed your set baseline. It is always easier to assess this data as a team, you want to be able to compare the transactional data with people’s real experiences, in such a way that wraps more context around 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 CSI (Continual Service Improvement) techniques in order to start logging how these trends, problems and reoccurring costs can be resolved, and within what priority.