The service desk interacts with literally every single person in your company – and is thus the most visible part of your IT department – and so it’s important to track how well it’s doing from the collective success levels down to aspects of individual performance. But it’s not good enough just to measure, you need to be measuring the right things – from what’s important to key business stakeholders, through the identification of improvement opportunities, to measures that can ensure that service desk employees remain motivated in their roles.
If you’re unsure what to measure relative to your IT service desk, or whether you’re currently measuring the right things, then here are some top tips for service desk metrics to guide you.
1. Understand What You Need to Report on For the Service Desk
It can be tempting to leave reporting to one side, or to deliver a portfolio of metrics as an afterthought, as the service desk tackles its day job. But having an optimized and credible performance reporting framework can benefit both IT and its customers.
So before arbitrarily choosing a set of random service desk KPIs from a book, understand what you need to achieve with the metrics. For instance:
● Benchmarking company performance against industry peers
● Identify service desk strengths and weaknesses
● Diagnosing and understanding the underlying drivers of availability or performance gaps
● Identifying opportunities for improvement across both IT services and operations
● Establishing performance goals for both individuals and the overall service desk
● Promoting or marketing your service desk within the organization – showcasing “wins” and positive results
● Monitoring the overall health of incident management and request fulfillment capabilities/processes
● Supporting audit and compliance activity
● Accounting for consumed resources and justifying future scalability
● Acting as a source of support for future decision making related to both IT services and operations
● Tracking and trending performance over time.
The important thing is to choose metrics because they help, not just because they’re popular elsewhere or easy to gather data on. It starts by understanding what you need to report in and why.
2. Formalize Your Reporting at the Outset and Continue to Question Metric Relevance Over Time
When planning which service desk metrics to use, bear in mind a number of key questions and performance management parameters:
● What do you want your reporting to look like? A simple update that’s bright and breezy capturing the headlines of the day or a more detailed approach? And realize that different use cases might dictate different reporting needs.
● How often do you want/need to report? Daily, weekly, monthly? What’s the right fit for your organization? What have your key business stakeholders asked for? Ultimately reporting is about the data/information consumers rather that its collators.
● Don’t just report for the sake of it. Just because you can run a particular report in your ITSM toolset doesn’t mean that you have to. Ask yourself: “Does it add value?” “Can it act as an input for service review meetings?” “Can it highlight any knowledge gaps or improvement areas?” And other pertinent questions related to the value of certain reports and/or metrics.
● Know your audience. Who will the reports be going to? The service desk management? Senior IT management? Business stakeholders? Figure out who your audience is and tailor your reports accordingly – from the content, i.e. the metrics used, to how the data/information is delivered.
● Proactively review your metrics. Because the metrics that you start with might not be needed/appropriate over time. This could be changing the targets or changing the metrics themselves.
3. Agree What to Measure at First
When initially pulling together a metrics pack for your service desk, or redesigning an existing pack, start with the basics. You can always build up your reporting portfolio over time, but keep it simple and achievable at the beginning.
Consider reporting on the following (but remember that each metric needs to have a legitimate purpose in the context of your organization’s needs):
● New tickets. The number of incoming requests for support. A ticket creation report shows you the volume of support requests your service desk is managing. Once you get a sense of how many incidents and requests your support team can handle in a day, week, or month, you’ll be able to plan staffing and shift patterns much more effectively (and drive efficiencies over time).
● Tickets by channel. How many contacts are via the phone? Email? Self-service? Understand what your most popular contact channels are so you can resource them appropriately. Also look to improve the channels that provide a better user experience relative to cost (if important).
● Incidents/requests by service. If you see that a specific type of incident has been reported multiple times, it may require further investigation (problem management). This will help in improving root cause resolution and reducing the future incoming ticket count.
Similarly, if you’re suddenly seeing a spike in particular service requests: has there been an influx of new hires? A major project? A new standard that the company must adhere to? Getting a handle on the root cause means you can get proactive and plan in advance to fulfill requests quickly before they start to affect support and business performance.
● Response times and wait times. How long does it take from an incident or request being logged to an acknowledgement that someone has picked it up and is working on it? Or how long do people need to wait to get through to a human either via telephone or walk up?
● Fix rates. What are the resolution rates at the first line (or first contact)? Second line? This metric helps you manage how long customers are waiting for their issue to be resolved. But be warned, first contact resolution doesn’t always equate to speed of fix.
● Major incidents. AKA the serious stuff. What percentage, or number, of your incidents are classified as “major”? Is this being reduced over time? Are major incidents being prevented from repeating?
● Aged incidents. What’s your work backlog like? If your ticket queues are getting longer and longer, this may be a sign of either a resourcing or a training issue.
● Reassignments. Also known as the “bounce count.” How many different teams is the incident or request assigned to before it gets resolved? Is it higher for particular types of incident? Could there be a categorization and routing training issue that’s causing delays and unnecessary work?
● Customer satisfaction. AKA the single most important metric you have. What do your customers and end users think? What’s going well? What could be improved upon?
These are commonly used within the ITSM industry as IT service desk benchmarks, but if comparing your performance with other organizations be careful to ensure that you’re comparing apples to apples. For instance, when looking at volumes or fix rates – are you still dealing with password resets manually or using an automated tool? It will make a big difference to both metrics (and potentially others).
How do you measure and report on your IT service desk performance? How has this changed over time? Would you add anything to our list? Please let me know in the comments!