When considering ITSM KPIs (Key Performance Indicators), organizations typically consider two types of metrics, technical-based and experience-based. Technical-based metrics could be; first-pass resolution, response, and resolution times. Experience-based KPIs, on the other hand, would revolve around NPS (net promoter score) and other CSAT or customer satisfaction metrics. No one would argue that both groups of KPIs should be measured, but how should they be measured and used?
Trying to define which ITSM KPIs are crucial for your organization can be difficult. The best place to start is by identifying the practices or processes you are looking to improve. Typically, service desks will separately monitor KPIs based on the interaction or practice type (incident, service request, change, etc.). To keep things a little simpler, let's use Incident Management as an example, but you can adopt the same concepts to virtually every other ITIL practice.
So, what could be some relatively standard technical-based and experience-based KPIs for Incident Management? If you are looking to define technical KPIs, a great place to start would be those included within ITIL. When it comes to experience-based KPIs, typically, your best bet is to brainstorm with a few colleagues, “what was a good and bad customer interaction I had in the past year and why." Often when you are trying to figure out what to track, the best place to start is with your own perceptions. The only real “requirement” when considering KPIs is that they should follow the SMART principle and be specific, measurable, achievable, relevant, and time-bound.
|Technical-based KPIs||Experience-based KPIs|
|Average incident response time||Response timeliness|
|Average incident resolution time||Response completeness|
|First pass resolution percentage||Employee perceived competence|
|Average conversation length||Employee perceived friendliness|
|System availability||Net promoter score (NPS)|
Example of technical-based and experience-based KPIs
Now, the KPIs above might seem like they are measuring similar and, in some cases, the same metrics. But when you take a closer look, you will see that they are actually looking from different perspectives. When considering the technical-based KPIs, these metrics are more related to SLAs (service level agreements) and other metrics that are much more objective. The experience-based KPIs look more at the customers' perception of the technical KPIs, making them far more subjective.
One good example of this difference is with average incident resolution time and response completeness. Both of these metrics will track whether the incident is solved, but only response completeness will take into account the user's point of view. To help make this crystal-clear, let's consider a real-world situation. An employee spills water on their computer, and it stops working. They create an incident, their computer is checked, and they are told to create a service request. At this point, the incident is "resolved," but do you think the employee would agree? In this case, they would still be at the same point, not having a working computer, and now they still have to make two requests. First for a new temporary replacement computer, and then a second for a new computer. This is why it is essential to consider the "human" aspect of what your KPIs are measuring.
When you have an idea of what you should be tracking, how should you make sure that you can follow these KPIs? To answer this question, you must first consider three crucial elements: how is this information collected, how does your ITSM solution report the results, and what should it be measured against? The easy way to solve these three questions is through the digitalization of your services through an ITSM solution (but you already knew that, or you wouldn’t be here). But what does this mean in practice, and what features and functions should the ITSM solution have?
Most ITSM solutions will allow you to define your SLAs and use this to calculate the "target" resolution and response times automatically. You can also use automations to record the time when service personnel changes the status of an incident from “waiting” to “in progress” to “completes” and calculate the total processing time. But both of these measure technical-based KPIs we talked about earlier. What about the experience-based KPIs? Even ITIL warns about the "watermelon effect" if you don't properly consider customers' experience when evaluating SLA related KPIs.
Simplifying ITSM KPI data collection with integrated feedback
To help get a better understanding of how the person who created the incident gauged their experience, you need to ask them. The easiest way to do this is to send a simple questionnaire about their interaction with your service desk. This brings up an important feature when looking for an ITSM solution. What feedback capabilities does it have? Does the solution include a feedback form that is automatically sent with every interaction, or is this something else you will have to buy, manage, and integrate? How easy is it to give feedback? What information needs to be collected?
Let's continue with the idea that digitalization is good when it comes to ITSM KPIs and reporting. So, the next question to answer is, how does the ITSM solutions process and report the results? Ideally, all of your KPIs are in a single dashboard or multiple dashboards for each role or department. Now, almost every ITSM solution includes some form of graphic views and dashboards to help managers track KPIs. But does the ITSM solution allow managers or even service desk personnel to create their own dashboards? How about the possibility to create customized and personalized views to track your personal or team tasks? If you are interested in following and improving your ITSM KPIs, you need to be sure to select an ITSM solution that is flexible and agile enough to meet both your managers and service personnel needs.
The last topic we will look at surrounding tracking and reporting ITSM KPIs is, assessing and evaluating the data. The evaluation and assessment of KPIs should always be handled with care. While KPIs can be a great motivator, they can also inadvertently promote behaviors, which can help improve metrics but risk security, compliance, or any number of other areas. This is why you should never place to much focus on targeting a specific KPIs. KPIs are best used for evaluation, not target setting.
When you do start evaluating your KPIs, you should always look at a team level when trying to understand best practices and identify areas of improvement. A great way to do this is to assess a particular team's technical-based and experience-based KPIs against the company average. This will help you better understand each teams' strengths and weaknesses. It will also provide you with a great place to start looking for improvement ideas. To help this evaluation process, you should have standard views or dashboards to evaluate the KPIs, which can then be used to generate detailed reports when needed.
The final point surrounding ITSM KPIs that is crucial to understand is that KPIs should be used to improve practices and processes. It is often easy to set targets and goals based on KPIs, but this can often do more harm than good by creating a feeling of, "I have to meet my goal at all costs." This can often be forgotten since KPIs will give you tangible metrics. But anyone who has any experience working with analytics knows you can always find a figure to prove your point, and a handful of statistics will never give you a complete view.
Find out how Efecte ITSM helped Musti Group chart their ITSM KPIs of business continuity, customer experience, cost, and service quality & speed.
September 17, 2021
It’s been another information-packed day at Efecte’s virtual event ‘Digitalize and Automate’, and it’s time to highlight the second day’s sessions..
September 15, 2021
After last year’s roaring success, the second edition of Digitalize and Automate has a lot to live up to. Having evolved into the number one ITSM..
August 19, 2021
Returning to normal, hybrid, or... During a very relaxing summer break, I was thinking about which kind of working environment we will return to in..