Article updated on 29/07/26

The five key incident management KPIs for modern service desks are:
1. Reopen Rate,
2. Incident Response Time,
3. Total Cost Per Contact,
4. Level 0 Success and Failure Rates, and
5. Incidents Related to Problems.

Each metric is defined, calculated, and explained in detail below.

Why Incident Management KPIs Matter: Business Impact and Operational Value

Incident management is one of the highest-stakes functions at the service desk, and the cost of getting it wrong is measurable. According to Gartner, IT downtime costs organizations an average of $300,000 per hour in lost revenue, employee productivity, and recovery expenses. Major outages can far exceed that figure. The majority of service desk leaders understand the exposure: according to the 2021 State of Service Management Survey conducted by ITSM.tools, 84% of respondents across organizations of all sizes recognize the adverse impact their service issues and failures have on business operations. However, understanding the risk and having the metrics to manage it are two different things.

Delivering seamless and effective incident management can improve the experience of the service desk customers, which trickles down into a positive experience for the external business customer. Taking a realistic look into your incident management process and performance from start to finish can also help you identify areas to optimize costs and increase efficiency. It also helps provide insights into the maintenance and prevention of greater problems, ultimately reducing overall downtime.

Incident management KPIs can also help your team shift to a more agile mindset as you gain the ability to change plans and roll out new changes quickly and easily. But, to make that a reality, it takes a thorough look at your incident management processes.

IT Service Management (ITSM) KPIs for Incident Management

The following five KPIs give service desk leaders a structured lens for evaluating incident management performance, not just as a snapshot, but as a trend over time. Organizations that move from ad hoc metric tracking to a disciplined KPI framework consistently report meaningful gains in efficiency and cost reduction. The specifics vary by organization size and maturity, but the pattern is consistent: what gets measured gets managed, and what gets managed gets improved. Here is where to start.

1. What Is Reopen Rate and How Do You Calculate It?

Tracking tickets opened and tickets closed is a baseline. But tracking whether tickets are being closed and reopened within a short window of time reveals something more important: whether incidents are actually being resolved. Tracking the reopen rate is important because a high rate may indicate that agents need additional training or that resolution quality needs improvement.

The reopen rate (RR) represents the percentage of tickets previously marked as resolved which have been reopened at a customer’s request. This can either happen due to a customer replying to a previously closed ticket response or requesting that the same ticket be reopened due to the same issue happening within a short time span. Reopen rate is slightly different from first contact resolution (FCR) because it examines the flip-side of that metric, not whether an issue was resolved on first contact, but whether a resolution that appeared complete actually held.

You should look at this number at two levels: that of the individual agent and then the organization as a whole. Further you should take into account the following positive and negative factors:

• The initial response and resolution of the ticket

• Possible agent responses that contributed to reopening a ticket vs. creating a new ticket or learning self-resolution

After you’ve taken these factors into account, you can use a simple formula to calculate your RR.

Formula: RR% = (Reopened Tickets / Total Tickets Solved) x 100

If this number is high, you may need to consider implementing training for either agents or customers (or sometimes both), or perhaps implementing a knowledge management database to educate customers on how to resolve some of the recurrent issues. According to HDI’s annual Support Center Practices research, high-performing service desks typically maintain reopen rates below 5%, a useful baseline when evaluating your own results.

2. How Do You Measure Incident Response Time?

Incident response time is crucial in improving productivity and reducing unplanned downtime due to system outages. This is different from a similar metric that is often incorrectly included as incident response time, which is called “mean time to resolve (MTTR).” Incident response time measures how long it takes an agent and a department, on average, to acknowledge and begin working a new or reopened ticket – it is a measure of speed of engagement, not end-to-end resolution.

MTTR, by contrast, measures the total elapsed time from when an incident is first detected to when the affected service is fully restored, making it a broader, end-to-end metric. Confusing the two leads to misleading performance reports: a team can have excellent response times but poor MTTR if diagnosis and resolution steps are inefficient or poorly documented.

You’ll need to take into account a few factors to understand the average incident response time. These include:

• Average handle time at both an agent level and an organization level

• Incident volume and type by department

• How many of these incidents are considered critical and how many are considered low priority

The formula to find your average incident response time is as follows.

Incident response time (in minutes, hours, and days) = Sum of all first response times / number of resolved tickets

This is not a comprehensive look at the amount of time it takes to resolve a ticket, just the amount of time it took an agent to work the ticket. Remember, you’ll have to consider how many of these tickets are low vs. high priority. Segment response time by priority level – P1 and P2 incidents warrant tighter targets than lower-severity tickets – to avoid a blended average that obscures critical performance gaps.

3. How Do You Calculate Total Cost Per Contact?

In this context, “contact” refers to any interaction between a user and the support team, including phone calls, emails, chat sessions, and formal tickets — making it a broader measure than cost per ticket alone. The total cost per contact is crucial when you’re trying to shift your mindset to build on a better IT-business relationship while optimizing costs.

Unfortunately, this metric is one of the most misunderstood and miscalculated metrics when it comes to incident management because it often fails to take into account some of the less obvious factors and often focuses only on the cost per ticket, not necessarily accounting for the times an agent resolved an issue without creating a formal ticket.

When you calculate the total cost per contact or incident, you should account for:

• Support staff costs, like salaries, medical benefits, and company incentives

• The cost of the IT service management tool through which the ticket was logged and worked on

• The cost of any self-service portals and tools

• The volume of calls, emails, and support tickets

Then, you can calculate the total cost per contact with this formula:

CPC = Total operating costs / Total number of calls, emails, support tickets, and other means of contact

This calculation can give a greater view of the ROI of the tools being used and ways to optimize these costs with self-service initiatives. Additionally, you can compare this figure to the number of users who resolve their tickets via self-service, as well as the total cost per ticket to understand where the majority of time is being spent on non-ticket related contacts. Industry benchmarks from MetricNet indicate that average cost per contact across service desks typically ranges from $15 to $25, with self-service interactions costing a fraction of agent-handled contacts – context that makes the ROI case for self-service investment concrete and defensible.

4. What Are Level 0 Success and Failure Rates in ITSM?

Level 0 refers to the tier of support where end users resolve their own issues without agent involvement, typically through self-service portals, knowledge bases, or automated tools. If you’re looking to optimize costs at the service desk, Level 0 self-service is one of the most effective levers available. But just because you have your self-service portal in use doesn’t necessarily mean you’ll be seeing immediate ROI.

You’ll need to track the utilization or adoption of the self-service portal, which can be done through the measurement of Level 0 success and Level 0 failure rates, sometimes called Level 0 Solvable (LZS). Level-0 tickets are support requests that were attempted through self-service channels, and Level 0 Solvable (LZS) is the industry term for the rate at which those self-service attempts succeed without requiring agent escalation.

Your Level 0 success and failure rates should include the utilization of automation, use of self-service portals, dwell time, click counts, and knowledge article access metrics. You can also gain additional insight to these metrics using feedback portals.

Your Level 0 success and failure rates will effectively tell you how many Level-0 tickets were deflected as a result of self-service adoption and utilization, as well as how many users attempted to resolve their own problem but ultimately failed and required the help of an agent. This will help you identify areas of concern to refine knowledge or procedures.

The formula for these figures is less straightforward than other metrics. You can read a detailed breakdown to help you calculate these numbers here.

5. How Do Incidents Relate to Problems in Incident Management?

The final piece of the incident management puzzle comes from understanding the relationship between current incidents and problems and how those may impact both the end user and the service desk team.

Incident management and problem management are two separate functions, but incidents can link together to become a problem. The simplest way to track this metric is to track the rate of incidents related to problems within your ITSM solution and looking for trends. You can also look at which departments are linked to higher rates of problems and incidents to understand where the roots of these problems lie in order to address them.

Formula: Problem-Linked Incident Rate (%) = (Number of Incidents Linked to a Known Problem / Total Incidents) x 100.

A rising rate over time may indicate systemic infrastructure issues that require root cause analysis through problem management rather than individual incident resolution. For example, if VPN-related incidents spike 40% over a two-week period, that pattern warrants a formal problem record, not repeated individual incident closures. Tracking this ratio week-over-week or month-over-month gives service desk leaders an early warning system for emerging infrastructure failures before they escalate into major outages.

Conclusion

Incident management KPIs give service desk leaders something more valuable than a performance report, they provide a diagnostic lens for understanding where processes are working, where they are breaking down, and where investment in training, tooling, or automation will generate the clearest return. The five metrics covered here – Reopen Rate, Incident Response Time, Total Cost Per Contact, Level 0 Success and Failure Rates, and the Incident-to-Problem Ratio – are not exhaustive, but they are a practical starting point for any organization looking to move from reactive firefighting to proactive service management.

The organizations that use these metrics most effectively are not just tracking numbers; they are building a culture of continuous improvement grounded in evidence. That shift – from measurement to action – is where mature ITSM operations are built.