Every strategic conversation I sit in these days includes the phrase “data-driven”, the ITIL Measurement and Reporting practice provides the tools to make IT performance visible, meaningful, and actionable.
This isn’t about collecting numbers for the sake of it. It’s about telling the story of IT—how it’s performing, where it’s adding value, and where it needs to improve. When done right, measurement becomes a lever for change. Reporting becomes the evidence behind decisions.
“You cannot control what you have never defined, and you cannot measure what you cannot control.” — Trevor Wilson, ITIL Trainer
Contents
Why ITIL Measurement and Reporting Matters
Measurement and Reporting help you:
Track service performance – uptime, resolution time, satisfaction scores
Spot trends and issues – before they escalate
Align IT with business goals – show how IT contributes to outcomes
Drive accountability – through transparent, data-backed reporting
Enable continuous improvement – by turning results into action
It gives leadership clarity, teams focus, and the organisation a clearer sense of how IT is doing—beyond anecdotes or gut feeling.
What ITIL Means by Measurement & Reporting
In ITIL 4, this practice is about using data to inform decisions and improve services. That means:
Defining what matters
Choosing the right things to measure
Collecting data consistently
Interpreting it in context
Reporting it in ways people can understand and act on
It’s not just about KPIs. It’s about purpose, outcomes, and the behaviours you want to drive.
From Purpose to Performance: What You Measure and Why
ITIL 4 encourages a disciplined approach to measurement—start with the why, then decide what to measure and how to use the results. Here’s how it all fits together:
1. Purpose: Why Are You Measuring?
The purpose is your starting point. It’s not about dashboards or SLAs—it’s about what outcome you’re trying to achieve.
Ask:
What are we trying to improve, prove, or understand?
What decisions do we want this data to support?
What behaviour do we want to influence?
If you can’t link your measurement to a business outcome, ask whether it needs to be measured at all.
ITILs Planning & Evaluation Model
2. Objectives: What Are You Trying to Achieve?
Once you’ve got your purpose, define objectives—specific, measurable targets that will help you achieve it. Objectives give your measurement activities direction and focus.
A vague objective like “improve service” is useless. “Resolve 90% of priority 2 incidents within 8 hours” gives you something to work with.
3. KPIs: How Will You Measure Success?
A Key Performance Indicator (KPI) is a high-value metric tied to a strategic goal. KPIs help decision-makers monitor success and prioritise improvements.
Not every metric is a KPI. Only the ones that:
Directly support your objectives
Drive decisions or actions
Reflect what “good” looks like
4. Metrics: What Are You Actually Measuring?
Metrics are raw data points—volume, time, cost, satisfaction, etc. They’re valuable, but not all are strategic. Many support operations rather than decisions.
Think of it this way:
Purpose = why we care
Objective = what we want
KPI = how we track success
Metric = the data that feeds the KPI
Example: IT Service Desk
Let’s break this down with a real-world example:
Element
Example
Purpose
Ensure users receive fast, effective IT support
Objective
Resolve 90% of issues on first contact within one business day
KPI
First Contact Resolution Rate (FCRR)
Metric
% of total issues resolved on first contact
This clear line from purpose to data ensures that what’s being measured supports decisions—and keeps IT aligned with what the business cares about.
25 Key KPIs and Metrics for IT Service Measurement & Reporting
Not every metric belongs in a board report—but every good report starts with meaningful data. These KPIs are grouped to help you focus on the areas that matter most to your ITSM goals.
1. Service Performance & Availability
KPI
Description
Formula
Service Availability
% of time a service is available for use
(Uptime / (Uptime + Downtime)) × 100
Mean Time to Repair (MTTR)
Average time to recover from a failure
Total downtime / Number of incidents
Mean Time Between Failures (MTBF)
Time between failures
Total operational time / Number of failures
Mean Time to Acknowledge (MTTA)
Average time to acknowledge an incident
Time from report to acknowledgement
Network Downtime
Total time the network was unavailable
Cumulative downtime over period
2. Incident & Request Management
KPI
Description
Formula
Incident Resolution Time
Average time to resolve incidents
Average time from opening to resolution
First Contact Resolution Rate (FCRR)
% of incidents resolved at first contact
(Resolved on first contact / Total incidents) × 100
Repeat Incident Rate
% of incidents that recur
(Repeat incidents / Total incidents) × 100
Escalation Rate
% of tickets escalated to higher tiers
(Escalated tickets / Total tickets) × 100
Ticket Volume Trend
Change in ticket volume over time
Period-on-period comparison
3. Change & Project Performance
KPI
Description
Formula
Change Success Rate
% of changes implemented without disruption
(Successful changes / Total changes) × 100
% Emergency Changes
Proportion of changes labelled as emergency
(Emergency changes / Total changes) × 100
% Projects on Time
% of projects completed as scheduled
(On-time projects / Total projects) × 100
% Projects on Budget
% of projects delivered within budget
(On-budget projects / Total projects) × 100
4. Customer Experience
KPI
Description
Formula
Customer Satisfaction (CSAT)
Average satisfaction score
Average survey rating
Net Promoter Score (NPS)
Measures customer loyalty
% Promoters – % Detractors
User Error Rate
% of incidents caused by users
(User-error incidents / Total incidents) × 100
5. Cost & Efficiency
KPI
Description
Formula
Cost Per Ticket
Average cost to handle a ticket
Total support cost / Number of tickets
IT Spend as % of Revenue
IT cost compared to revenue
(IT spend / Revenue) × 100
Downtime Impact on Revenue
Financial cost of outages
Revenue loss from downtime / Revenue
6. Infrastructure & Application Health
KPI
Description
Formula
Application Load Time
Time it takes apps to load for users
Average load time (seconds)
CPU Utilisation Rate
% of CPU being used
(CPU time used / Total CPU time) × 100
Memory Utilisation Rate
% of memory in use
(Memory used / Total memory) × 100
Storage Utilisation Rate
% of storage used
(Storage used / Total capacity) × 100
These KPIs support a wide range of decisions—from improving service performance and optimising IT spend to demonstrating value to the business.
How to Make Measurement & Reporting Work: 10 Practical Recommendations
Measurement and reporting only create value if they lead to insight, action, and improvement. Here’s how to build a meaningful and effective practice in your ITSM environment.
1. Start with the Business in Mind
Don’t measure everything—measure what matters. Align your KPIs to business goals, not just technical performance. For example: “Reduce time lost to outages” is more useful than “Average packet loss”.
2. Don’t Drown in Data
More data isn’t better—better data is. Prioritise a core set of metrics that offer insight, not just numbers. Focus on trends, exceptions, and behaviour drivers.
3. Integrate Across Practices
Measurement should support all key ITIL practices—incident, change, availability, capacity, and more. Avoid siloed dashboards and make sure reporting informs cross-functional decisions.
4. Standardise for Consistency
Agree definitions, formats, and collection methods for each metric. A KPI is only credible if everyone knows exactly how it’s measured and reported.
5. Turn Data into Action
Train your teams to go beyond observation. Encourage them to ask “What does this tell us?”, “Why is it happening?”, and “What should we change?”
6. Link IT to Business Outcomes
Where possible, connect KPIs to revenue, productivity, customer experience, or risk. This helps IT show its value and secure support for change and investment.
7. Use Both Leading and Lagging Indicators
Lagging indicators show results (e.g. CSAT, availability). Leading indicators predict future risk or performance (e.g. backlog size, missed patch windows). Use both for a full picture.
8. Present Data for Impact
Use dashboards and visualisations to make reports easier to read and faster to understand. Tailor what you show depending on who you’re showing it to.
9. Embed Continuous Improvement
Use measurement as a trigger for review, not just reflection. Feed reporting outputs directly into your improvement planning cycles—monthly, quarterly, or by exception.
10. Explore Automation & AI
Consider tools with built-in analytics, forecasting, and anomaly detection. AI and machine learning can help spot patterns and predict issues before they happen.
Implementing Measurement & Reporting: A 8-Step Approach
You don’t need dozens of dashboards to get started. What you need is a structured, purpose-led process. Here’s how to do it right:
Step 1: Define What Success Looks Like
Start with purpose. What are you trying to achieve? Are you improving service speed? Reducing downtime? Supporting a business transformation? 📌 Tip: Every measurement goal should map to a business or ITSM outcome.
Step 2: Choose the Right KPIs & CSFs
Identify the critical success factors (CSFs) for your goals, then define a few meaningful KPIs to track them. Make sure your KPIs are SMART—Specific, Measurable, Achievable, Relevant, and Time-bound.
Example: If your CSF is “Reduce user downtime”, a KPI might be “First contact resolution rate” or “Average incident resolution time”.
Step 3: Establish Baselines and Set Targets
You need to know your current state before you can measure improvement. Start with a baseline—then agree short-term and long-term targets that reflect your capacity to change.
Example: Uptime is currently 97.5%. Set a realistic six-month target of 98.5%.
Step 4: Select Tools and Technologies
Use platforms that can gather, store, and report on your chosen metrics efficiently. Whether you’re using an ITSM platform like ServiceNow or building your own dashboards, the tools must integrate well with your environment.
Step 5: Define Data Collection Methods
Be clear about where your data will come from—and how it will be kept accurate and up to date. Automate where possible. Avoid manual tracking unless absolutely necessary.
Good data fuels credibility. Poor data undermines trust.
Step 6: Analyse the Data Regularly
Don’t wait for quarterly reports. Build in monthly or even weekly reviews of the numbers. Look for trends, anomalies, bottlenecks, and exceptions. Ask “What’s changed?” and “Why?”
Step 7: Report Insights to the Right People
Tailor your outputs:
Executives want outcomes
Managers want performance trends
Front-line teams want actionable insight
Use visuals where possible. Keep the message focused. Avoid data-dumps.
Step 8: Review and Refine the Approach
Make this a living practice. Regularly review what you’re measuring and whether it’s still useful. If a KPI stops driving decisions—retire it. If a new priority emerges—introduce something new.
Conclusion: Make the Data Work for You
Measurement and Reporting aren’t just ITIL checkboxes—they’re how IT proves its value, drives better decisions, and stays aligned with the business.
Done well, this practice helps you:
Focus on what matters
Catch problems before they escalate
Justify investments with hard data
Show how IT contributes to growth, stability, and service excellence
But none of that happens just by collecting numbers. It happens when you turn data into action—and use it to continuously improve.
The organisations that thrive are the ones that learn from their data, not just report it.
FAQs
What’s the difference between a metric, a KPI, and a CSF?
A metric is any data point you can track—volume of tickets, uptime, average resolution time. A KPI (Key Performance Indicator) is a high-value metric directly tied to strategic goals. It tells you whether you’re succeeding. A CSF (Critical Success Factor) is the condition you need to meet for your objective to succeed.
Think of it like this: – CSF: “We must reduce user downtime.” – KPI: “First Contact Resolution Rate” – Metric: “% of issues resolved on first contact”
All KPIs are metrics, but not all metrics are KPIs—and CSFs come first.
How many KPIs should we track in IT service management?
As few as you can get away with—and no more than you need. More KPIs don’t mean more insight. In most environments, 8–12 core KPIs per team or function is a reasonable number.
Each KPI should: – Link to a business or ITSM objective – Influence decisions or improvement actions – Be consistently understood and reported
If you’re not using the data, you’re just collecting numbers.
Who should be responsible for defining KPIs in ITIL Measurement and Reporting?
It depends on context, but ideally it’s a shared responsibility:
– Leadership defines strategic goals and desired outcomes – Service owners and process managers propose meaningful KPIs aligned to those goals – The reporting function or measurement lead ensures consistency, quality, and governance
The key is collaboration. Don’t let KPIs be handed down without engagement—or bubble up without business context.
How often should KPIs be reviewed or adjusted?
Review your KPIs at least quarterly. Ask:
– Are they still relevant? – Are they still influencing decisions? – Is the data reliable and timely?
If a KPI hasn’t triggered a conversation or an action recently, it may need to be retired or replaced. Just like services, KPIs have a lifecycle—review them as part of your continual improvement efforts.
What’s a good way to visualise KPI data for impact?
Use dashboards that are audience-aware:
– Executives want high-level trends and business outcomes – Managers want performance trends and team-level summaries – Teams want root cause, exceptions, and actionable next steps
Use simple visuals: bar charts, trend lines, RAG status indicators. Don’t overcomplicate. Highlight what’s changed, what needs attention, and what’s improving.
The goal is clarity, not decoration.
Final Thought & Further Reading
You don’t need hundreds of KPIs to get this right. You need a clear purpose, a few well-chosen measures, and a team that knows how to act on what they see.
In ITIL 4, Measurement and Reporting isn’t a dashboard—it’s a discipline.
Alan Parker is an experienced IT governance consultant who’s spent over 30 years helping SMEs and IT teams simplify complex IT challenges. With an Honours Degree in Information Systems, ITIL v3 Expert certification, ITIL v4 Bridge, and PRINCE2 Practitioner accreditation, Alan’s expertise covers project management, ISO 27001 compliance, and service management best practices. Recently named IT Project Expert of the Year (2024, UK).
