Consistently meeting your Incident Management KPIs and matching SLAs is something we all contend with on a monthly, weekly and sometimes daily basis. Meeting Incident Management targets is integral, but what targets should you aim for? And what metrics should you be focusing on? Let’s have a look at KPIs: the classics, some new ones and some overall best practices.
Focus your KPIs
What KPIs are the best to track your incident management success? Well, first of all, not everything is a key indicator of your performance, and some metrics deserve more attention than others. Some of the most common KPIs used in Service Desks include:
- The amount of tickets logged per day
As a base-line, how busy is your Service Desk, and how does it evolve over time?
- Amount of repeat incidents
Which indicates a need for a standard solution, or escalation to a Problem.
- Average response time
How fast are Incidents picked up? Is there a bottle neck?
- Average solution time
This is especially powerful in conjunction with the above metric
- Tickets breached
How many tickets breach your SLAs?
- First-time fixes
Conversely, how many tickets are handled quickly? This, along with solution time, could indicate efficiency.
These are some KPI classics, but as with anything – there is more to the story.
First of all, keep in mind is these are performance indicators. If you find that something is pivotal to tracking the Incident Management performance of your Service Desk – track it, but make sure your reports are clear and actionable. And don’t track everything.
Read more about my thoughts on creating meaningful reports here
Is a high average on my KPI enough?
This is an interesting question. Is it all just about smashing targets? Not really.
Say you have a 5-star rating system, and people are mostly rating you around 4/5 for good Service, but a few people are rating you a 1. Yes, it’s bringing your average down – but you can easily bring it back up!
Don’t be happy that your average is around 4.5. Look at the reviews that are bringing the score down as well. That’s where the interesting stuff is, and where there’s changes to address!
Monitor your averages as a incident management KPI, but do occasionally drill into the outliers. Especially when it comes to things like user experience.
Tracking the user experience
On the topic of user experience: if you read my previous post on XLAs (which you find here) you’ll know how important they are for fleshing out the black and white numbers of SLA stats. At surface level all SLAs might be being met and most incidents processed in good time. But are you keeping your customers happy? TOPdesk, for example, has a 5-star rating system which means you can gain consistent and useful feedback on what you’re doing.
One recent example I’ve experienced is a firm where changing your password required calling IT. The password reset process took up to ten minutes for every employee. The SLA of ten minute password resents were continually met, but their XLAs were not. Users were, understandably, upset with the lack of efficiency.
Moral of the story? Don’t get blinded by numbers.
Just getting started with targets for your departments? These are the things to consider.
Adding Customer Experience KPIs
We wrote a whole blog post on customer experience KPIs recently, but here are some additional KPIs to track that indicate how the customer finds your service:
• A certain customer satisfaction rating (CSAT) (for example, 4 stars out of 5)
• Track lost productivity (downtime) and try to make sure you minimise it
• Ensure clarity about products and services the department can supply
• A good Net Promoter Score (30-40%)
Customer Experience isn’t fully intangible, so don’t ignore it in your KPIs.
Did you know that you can also measure customer loyalty? You do this with the Customer Effort Score (CES).
Quick tips: breaking down your KPIs
And finally: meeting or exceeding your KPIs is always an achievement, but sometimes it’s important to take a step back and view things from a grassroots level.
Viewing KPIs from a top-down level won’t give you the information to change and improve individual aspects of your team. Delve into your individual team reports to analyse, for example, if the difference in the time taken to process Incidents across your 1st and 2nd line teams could be shortened by automation. Consistently check to see if the priority of Incidents reflected the difficulty of solving them. This granular approach can often be lost in larger teams but should always be a key aspect of your analysis.
Have a look at my colleague Will’s tips on how to create reports with actual actionable take-aways here
Look at different time lines
Varying your incident management KPI deadlines across contrasting time-frames will allow you to analyse both long-term and short-term trends so no worrying incidents are lost in the data. ‘Zooming in’ to check things across combined timeframes will allow you to present snapshots you can learn from, particularly any outliers in your data. Utilising this approach will also allow you to become more proactive, for example you can prepare for anticipated dips or increase in tickets noted from previous data.
Consider the end user
We did already mention this, but factoring in a customer-centric attitude will inject a bit of that oft-forgotten human experience into the numbers led world of Incident management. Worth looking into!
Follow these best practices to make the most of ITIL incident management
Get more out of your ITSM Processes
Learn more about marrying classic ITIL and ITSM-processes with a customer focused approach in our free Best Practice Service Management e-book.
November 29, 2018
Using a baseline measurement to achieve service excellence
Are you planning an improvement project within your organization? Consider performing a baseline measurement first. You’ll increase the chance of success.
September 12, 2017
Making your IT Service Level Agreements more flexible
SLAs are great for reporting to management but too much focus on that may risk long term damage to your organisation. The solution? A shift towards XLAs.