When was the last time you took stock of your IT service management (ITSM) and service desk metrics? Have you taken the time to understand whether the metrics and key performance indicators (KPIs) are still fit for purpose? Or perhaps whether they ever were? And even if they are (still relevant) – are your targets still fit for purpose?
Then, how are they reported? Hopefully it’s in a way that inspires people to look at them (and take some form of action). And, ultimately, what’s achieved through the metric data you produce and share? Are your metrics merely a mechanism to applaud good performance or to assign blame? Or are they the platform to identify and address improvement opportunities?
It’s a lot of questions, I know. But they need to be asked – and regularly. As my good, and incredibly wise, friend Ivor Mcfarlane is keen to point out:
“If you measure the wrong things, then you’ll get better at the wrong things.”
It makes sense, doesn’t it.
Making sense of ITSM metrics
I’ve written about this in the past, probably multiple times, but it’s one of those ITSM and service desk staples that need to be revisited (in the same way that your metrics do).
A key point is that you need to understand that metrics are not your goal. And to quote myself, if I may:
“Measurement is essential. It tells us about trends, it helps us to identify improvement opportunities, and it provides a framework for discussion with customers. But we must never forget that achieving the KPI is not an end in itself, and that our work is not done until we meet our customers’ expectations.
So, it’s fine to use KPIs for planning, understanding, and discussion, just remember to maintain a focus on your real goals and don’t confuse the goals with your KPIs!”
So, what should you measure?
Of course, this is the wrong question for me to ask and generically answer. Well, at least directly.
It shouldn’t be a third-party telling you – the person who really knows what’s important for their service desk, IT department, and wider organization – what the important metrics and KPIs are.
A better question for me to ask and answer here is something like: “Which common metrics might be appropriate for your organization?” As you’ll ultimately know far better than me as to which aspects of your IT operations drive the required IT and business outcomes.
Which common service desk metrics might be appropriate for your organization?
I appreciate that you don’t have all day (to read this), so I’m going to focus on a couple of areas to get you thinking:
You can follow these links to find out more too – as I’ve already written more detailed blogs on each of these. Plus on problem management and change management.
What to consider with IT help desk/service desk metrics
It’s all about what you are trying to achieve – your critical success factors (CSFs). And stealing from my earlier service desk blog, I consider the following a good example to model your organization’s help desk/service desk KPI and metric requirements on:
- CSF: We make it easy for users to contact IT to request help, ask questions, or provide feedback
- All user interactions can be initiated via phone or web-based form (Yes/No)
- Percentage of phone calls to service desk answered within 30 seconds
- Percentage of phone calls to service desk abandoned before they are answered
- Result for survey question “How easy is it to contact IT when you need to?” on annual customer satisfaction survey
- CSF: We communicate well with our users, keeping them informed, and meeting their expectations
- Percentage of incidents where user contacted the service desk to ask for an update
- Percentage of incidents that were reopened by the user after being closed by the service desk
- CSF: We resolve user incidents quickly and efficiently
- Percentage of incidents resolved within agreed SLA targets
- Percentage of incidents resolved using web-based self-help
- Percentage of incidents resolved during the initial customer contact
- CSF: We fulfil user service requests quickly and efficiently
- Percentage of service requests fulfilled within agreed SLA targets
- Percentage of service requests fulfilled using automation with no manual steps from IT staff
- CSF: We achieve high levels of customer satisfaction
- Percentage of users giving a score of 4 or 5 on post-incident satisfaction survey
- Increased satisfaction with service desk on annual customer satisfaction survey
In terms of the above, it’s important to note (and understand) that:
- Every KPI supports an important objective; and achieving the KPI will indicate that the objective is being met.
- Every KPI can be measured.
- Every KPI has a clear and unambiguous target.
- These are just examples – NOT exactly what your organization will need.
What to consider with incident management metrics
The same approach should be applied for incident management too. So, for example:
- CSF: We resolve incidents quickly, so they don’t have a significant impact on our customers
- Percentage of Priority 1 incidents resolved within SLA agreed target
- Percentage of Priority 2 incidents resolved within SLA agreed target
- Percentage of Priority 3 incidents resolved within SLA agreed target
- CSF: We prioritize incidents appropriately, based on their impact and urgency
- Number of incidents where the priority was changed after logging
- Number of customer complaints or escalations due to disagreement over incident priority
- CSF: We communicate well so that customers and users understand what is happening and when they can expect their incidents to be resolved
- Percentage of incidents where customer contacted the service desk to ask for an update
- CSF: Customers and users are satisfied with the way we handle their incidents
- Percentage of users giving a score of 4 or 5 on post-incident satisfaction survey
- Increased satisfaction with incident management on annual customer satisfaction survey
- CSF: We recognize repeating incidents and log problems to help reduce future business impact
- Number of problems logged by the service desk
- Number of problems identified by analysis of incident data
- CSF: We make efficient use of our incident management resources
- Percentage of incidents logged via self-service
- Percentage of incidents solved by self-service
- Average cost to resolve incident (by priority)
Hopefully this blog has whet your appetite to learn and do more about your ITSM and service desk metrics. It’s an eternal topic of interest for ITSM pros and, because of this, I’ll be presenting on the topic at the 2018 Service Desk Institute Conference.
If you wish to join me – and of course bring your tricky metrics questions – then more information about my session (I’m presenting on Tuesday, March 13, 2018 at 2:40PM) can be found here. It’s not too late to join a great group of people at a great ITSM and service desk event. Plus, as an ITSM.tools reader you’re also entitled to 10% off the entry price, so be sure to use the code “TOOLS18” at checkout.
Stuart Rance is a consultant, trainer, and author with an international reputation as an expert in ITSM and information security. He was a lead architect and lead editor for ITIL 4, and the lead author for RESILIA™: Cyber Resilience Best Practice. He writes blogs and white papers for many organizations, including his own website.
Stuart is a lead examiner for ITIL, chief examiner for RESILIA, and an instructor for ITIL, CISSP, and many other topics. He develops and delivers custom training courses, and delivers presentations on many topics, for events such as itSMF conferences and for private organizations.
In addition to his day job, he is also an ITSM.tools Associate Consultant.
I feel stupid for even asking this but don’t servicedesk actually performe incident managment so how can you measure them separately?
A service desk usually does some incident management work, but they do many other things as well, and many other groups also perform incident management.
If you measure incident management only then you will not understand how well your service desk has performed request fulfillment, or handling general requests for information, or proactively updating users about changes and planned downtime. Also many aspects of incident management are outside the control of the service desk.
Measuring how quickly a development team delivers patches to resolve software errors is important for incident management, but not a good measure of your service desk.