If you are implementing Incident Management for the first time—or trying to improve a process that has become difficult to manage—there is a temptation to start with the measurements.
How many incidents did we have?
What was our MTTR?
What percentage met SLA?
How many were reopened?
Those numbers matter. But they are not where you should start.
Before you decide what to measure, you need to agree on what success actually looks like.
That means starting with your Critical Success Factors (CSFs).
First, What Is a CSF?
A Critical Success Factor (CSF) is a necessary condition that must be achieved for the intended result to be successful.
In plain English:
A CSF tells you what must be true for your Incident Management practice to succeed.
For example:
Restore normal service quickly while minimizing business impact.
That’s a CSF.
It doesn’t tell you exactly how many minutes are acceptable. It tells you what you are trying to accomplish.
ITIL 4 uses the term Practice Success Factor (PSF) for this concept. Earlier ITIL versions commonly used Critical Success Factor (CSF).
For this article, we’ll use CSF, because it remains a familiar and useful term for ITSM professionals.
CSF First. KPI Second.
Once you know what success looks like, you can decide how you’re going to know whether you’re achieving it.
That’s where the Key Performance Indicator (KPI) comes in.
A KPI is an important metric used to evaluate success in meeting an objective.
Think about the difference:
CSF:
Restore normal service quickly while minimizing business impact.
KPI:
Mean time to resolve Priority 2 incidents.
The CSF tells you what matters.
The KPI tells you how you’re going to measure it.
And this distinction matters. If you start by picking numbers because they’re easy to report, you can end up measuring something that has very little to do with whether Incident Management is actually succeeding.
What Makes a KPI SMART?
When you turn a metric into a KPI, it should be SMART:
- S — Specific
- M — Measurable
- A — Achievable
- R — Relevant
- T — Time-bound
For example:
Not very useful:
Reduce incident resolution time.
Much better:
Reduce mean resolution time for Priority 2 incidents by 15% by the end of Q4.
Now everyone knows:
- what we’re measuring,
- what improvement we’re expecting,
- what number we’re trying to achieve,
- and when we’re going to evaluate it.
And importantly, ITIL does not give every organization one universal number to use.
Your targets need to reflect your organization’s context, services, priorities and tolerance for disruption.
That’s a feature of ITIL—not a weakness.
So What Are the Incident Management CSFs?
The following list combines Incident Management success factors found across ITIL guidance, including earlier ITIL CSF material and ITIL 4 Incident Management guidance.
The order is a practical ranking, not an official ITIL ranking.
Most organizations will find the factors near the top more fundamental than those near the bottom. But most organizations are not the same.
A hospital, a bank, a university, a software company and a government agency may have very different priorities, services, risks, staffing models and tolerance for disruption.
That’s one of the things that makes ITIL useful:
ITIL is adaptable and adoptable.
You don’t have to force your organization into somebody else’s process.
You determine what matters to your organization and build the practice around that.
1. Restore Normal Service Quickly While Minimizing Business Impact
This is the heart of Incident Management.
The objective isn’t simply to close tickets quickly. The objective is to restore normal service and minimize the impact of the incident on the business.
Why it matters
A fast ticket closure means very little if the business is still unable to work.
SMART KPI examples
- Reduce mean time to resolve incidents by X% by the end of Q4.
- Resolve ≥ X% of Priority 1 incidents within X hours each quarter.
- Resolve ≥ X% of incidents within their agreed resolution target each month.
- Achieve ≥ X% first-contact resolution by the end of Q4.
- Reduce average business-impact duration by X% year over year.
2. Keep Incident Volumes Under Control
Incident Management isn’t successful if the team resolves incidents efficiently but the organization keeps generating more incidents than the team can handle.
You need to understand what is entering the system, what is leaving the system and what is accumulating in the middle.
Why it matters
A growing backlog can indicate problems with capacity, service quality, prioritization, routing, skills, tooling—or the underlying services themselves.
SMART KPI examples
- Reduce total incident volume by X% within 12 months.
- Keep monthly incident volume below X incidents per 1,000 users for six consecutive months.
- Reduce recurring incidents by X% by the end of Q4.
- Maintain an incident backlog below X open incidents at month-end.
- Maintain a resolution rate sufficient to prevent backlog growth for X consecutive months.
- Reduce incidents older than X days to less than X% of the backlog by Q4.
3. Detect and Record Incidents as Early as Possible
The earlier you know about an incident, the earlier you can begin responding to it.
Modern Incident Management increasingly uses monitoring, event management and automation to detect incidents before users report them.
Why it matters
You can’t effectively manage an incident you don’t know about.
SMART KPI examples
- Reduce mean time to detect to ≤ X minutes by Q4.
- Detect ≥ X% of qualifying incidents through monitoring before user notification by year-end.
- Automatically detect ≥ X% of qualifying incidents by Q4.
- Log ≥ X% of reported incidents within X minutes of notification each month.
4. Maintain the Quality of IT Services
Incident Management doesn’t exist in isolation.
If a service continually generates incidents, resolving each individual ticket faster doesn’t necessarily mean the service is healthy.
You need to look at the pattern.
Why it matters
A service generating hundreds of recurring incidents is telling you something that individual incident-resolution statistics may hide.
SMART KPI examples
- Reduce incidents per service/user by X% year over year.
- Reduce major incidents by X% within 12 months.
- Reduce repeat incidents by X% by Q4.
- Keep reopened incidents below X% of resolved incidents each quarter.
- Reduce customer-impacting incidents by X% by year-end.
5. Have the Capacity, Skills and Service Desk Capability to Handle the Work
You can have a beautiful Incident Management process on paper and still fail if you don’t have enough people with the right skills to operate it.
Why it matters
A process cannot consistently outperform the people, skills and capacity available to execute it.
SMART KPI examples
- Maintain staffing capacity sufficient to resolve ≥ X% of monthly incident volume within target.
- Keep incidents per analyst below X per month while maintaining resolution targets.
- Maintain ≥ X% required competency/training coverage by Q4.
- Keep resource-related target breaches below X% each quarter.
- Achieve ≥ X% first-contact resolution by year-end.
6. Prioritize and Route Incidents Correctly
An incident that lands in the wrong queue can spend hours—or days—getting passed around.
That isn’t just frustrating. It directly affects resolution time and customer impact.
Why it matters
The right incident in the wrong queue is still a delayed incident.
SMART KPI examples
- Achieve ≥ X% correct prioritization each month.
- Keep incorrectly categorized incidents below X% each quarter.
- Keep incorrectly assigned incidents below X% each month.
- Reduce reassigned incidents by X% by Q4.
- Assign ≥ X% of incidents to the correct support group within X minutes of logging.
7. Maintain Accurate, Useful Incident Information
Good Incident Management depends on good information.
If the analyst has to spend the first 20 minutes figuring out what happened, which service is affected, who is affected and what has already been tried, resolution is going to suffer.
Why it matters
Poor information creates unnecessary investigation, reassignment and delay.
SMART KPI examples
- Ensure ≥ X% of incident records contain all required information at closure each month.
- Reduce incidents requiring information rework by X% by Q4.
- Link ≥ X% of applicable incidents to the relevant service or CI by year-end.
- Achieve ≥ X% knowledge-assisted resolution for applicable incidents by Q4.
8. Use Effective Tools and Automation to Support the Process
Tools don’t create good Incident Management.
But bad tools can certainly make good Incident Management much harder.
Why it matters
Automation should remove unnecessary work and help the organization detect and resolve incidents more effectively.
SMART KPI examples
- Automatically detect ≥ X% of qualifying incidents by Q4.
- Resolve ≥ X% of eligible incidents through automation by year-end.
- Resolve ≥ X% of eligible incidents through self-service by Q4.
- Maintain Incident Management tool availability of ≥ X% each quarter.
- Reduce manual handoffs per incident by X% within 12 months.
9. Maintain User and Customer Satisfaction
Here’s an important warning:
Fast does not automatically mean good.
You can close tickets quickly while frustrating everyone who uses the service.
Why it matters
Incident Management ultimately exists to support people and the business—not simply to make the dashboard look good.
SMART KPI examples
- Achieve an average incident satisfaction score of ≥ X/5 each quarter.
- Maintain ≥ X% satisfied users each quarter.
- Reduce incident-related complaints by X% by Q4.
- Keep incident reopen rates below X% each quarter.
10. Communicate Clearly and Keep Stakeholders Informed
An incident can be technically under control while the organization thinks IT has completely lost control.
Communication matters.
Especially during major incidents.
Why it matters
People can often tolerate an outage better when they understand what is happening, what is being done and when they will receive the next update.
SMART KPI examples
- Provide required incident updates for ≥ X% of applicable incidents each month.
- Deliver ≥ X% of major-incident communications within X minutes.
- Reduce communication-related complaints by X% by Q4.
- Achieve ≥ X% stakeholder satisfaction with incident communications each quarter.
11. Align Incident Management With Business Priorities
Not every incident has the same business impact.
A five-minute interruption to an internal test system isn’t necessarily equivalent to five minutes of downtime for the system that processes customer payments.
Why it matters
Incident priority should reflect business impact—not simply technical inconvenience.
SMART KPI examples
- Resolve ≥ X% of incidents within business-approved targets each month.
- Maintain ≥ X% priority accuracy each quarter.
- Reduce high-business-impact incidents by X% within 12 months.
- Review Incident Management priorities with business stakeholders at least quarterly.
12. Continually Improve Incident Management
This brings us to Continual Service Improvement (CSI), the term you’ll recognize from earlier ITIL guidance.
In ITIL 4, continual improvement is built into the Incident Management practice itself.
The terminology evolved across ITIL versions, but the underlying idea remains:
Measure. Learn. Improve. Measure again.
Why it matters
Incident Management shouldn’t simply repeat the same mistakes faster every year.
SMART KPI examples
- Reduce recurring incidents by X% within 12 months.
- Complete ≥ X% of approved Incident Management improvement actions by their target dates each quarter.
- Reduce repeat incidents by X% by Q4.
- Improve defined Incident Management performance indicators by X% year over year.
13. Maintain Effective Agreements and Escalation Relationships
Incident Management frequently depends on other teams, suppliers and support organizations.
If the Incident Management team has a target but the teams it depends upon don’t have workable agreements, the process can break down quickly.
Why it matters
Your team can only resolve an incident as effectively as the broader support structure allows.
SMART KPI examples
- Meet OLA targets for ≥ X% of applicable incidents each month.
- Maintain supplier response-time compliance of ≥ X% each quarter.
- Maintain supplier resolution-time compliance of ≥ X% each quarter.
- Reduce OLA/UC breaches by X% within 12 months.
- Complete ≥ X% of required escalations within the defined timeframe each month.
14. Maintain Effective Knowledge, Known Errors and Workarounds
Finally, don’t make every incident a brand-new investigation.
If you’ve solved something before, the organization should be able to benefit from what it already learned.
Why it matters
Good knowledge can turn yesterday’s difficult incident into today’s routine resolution.
SMART KPI examples
- Resolve ≥ X% of applicable incidents using documented solutions or workarounds by Q4.
- Increase knowledge-assisted resolution by X% within 12 months.
- Review/update ≥ X% of active Known Error records each quarter.
- Increase the percentage of eligible incidents resolved using knowledge by X% by year-end.
How Many KPIs Do You Actually Need?
This is where organizations can get themselves into trouble.
When you’re starting a new practice, my general rule of thumb is:
Start with about 3–5 KPIs.
That’s enough to give you a useful picture without creating a reporting monster.
But Incident Management is complicated.
So if you start with a Service Desk or Incident Management practice and discover that you genuinely need 5–8 KPIs, that’s okay.
Don’t throw away useful information just because somebody told you that every practice should have exactly three metrics.
And there’s another complication.
Some practices are systems of interconnected things that depend on one another.
Incident Management is a great example.
You may need to look at:
- incident volume,
- backlog,
- backlog age,
- detection time,
- assignment time,
- reassignment,
- resolution time,
- first-contact resolution,
- target compliance,
- customer satisfaction,
- repeat incidents,
and several other measures at the same time to understand what is actually happening.
That’s okay too.
The goal isn’t to have the fewest KPIs possible.
The goal is to have enough meaningful information to make good decisions without drowning the people who have to collect, interpret and act on it.
Incident Management naturally has a particularly high number of potentially useful metrics because it sits in the middle of so many other activities and value streams.
And No, Zero Incidents Is Not the Goal
This deserves its own warning.
If someone tells you their Incident Management goal is:
Zero incidents.
That’s certainly an ambitious goal.
Unfortunately, if they actually achieve it, I would immediately check whether the system is still turned on.
We would all love fewer incidents.
But Incident Management does not exist to make incidents disappear.
Its purpose is to ensure that when incidents occur, they are detected, recorded, prioritized, communicated, managed and resolved effectively—and that the organization learns from what happens.
A sudden drop to zero incidents might mean improvement.
It might also mean that incidents aren’t being reported.
Or monitoring isn’t working.
Or the service isn’t available for anyone to use.
Context matters.
So Where Do You Start?
Before you start changing the process, buying another tool, creating another dashboard or demanding that the Service Desk close tickets faster, take a step back.
First, make sure everyone agrees on what Incident Management is supposed to accomplish.
Then define what success means for your organization.
Then identify and agree upon your CSFs.
Then—and this is often the harder conversation—agree upon the KPIs that will tell you whether those CSFs are actually being achieved.
Then make those KPIs SMART.
Only after that should you start working on how to make the numbers better.
That’s the beginning of improvement.
You cannot improve what you haven’t defined.
And you can’t meaningfully measure success until you and the people who depend on Incident Management agree on what success actually means.
That is why the first step in improving Incident Management isn’t necessarily another process diagram.