“In service management, if you don’t measure, you guess; if you measure, you decide.”
Introduction
Evaluating performance in IT service management isn’t about collecting pretty charts; it’s about separating noise from signal so you can decide with less friction and more predictability. When availability, response time, and customer satisfaction become trustworthy numbers, the conversation leaves “I think it got better” and enters “the value delivered went up by X%.”
Here, we go straight to what matters: five methods that actually move the needle — service monitoring, customer satisfaction, key performance indicators, regular reviews, and trend analysis — plus the elements that usually go missing and are needed to close the loop measurement → decision → continual improvement. The idea is practical: what to measure, why to measure, how to read it, and what decision to take next. No swapping tools for the sake of it; the focus is services flowing, people aligned, and results showing up.
Dramatic pause: I look at you and say — measuring poorly is worse than not measuring. Let’s measure right?
Table of Contents
- 1) Purpose and scope
- 2) Instrumentation and data quality
- 3) Baseline, targets, and error budget
- 4) The 5 decision‑making methods
- 5) DORA metrics and day‑to‑day connection
- 6) Cost per service (light FinOps)
- 7) Minimum KPIs by process
- 8) Lean post‑incident (PIR)
- 9) Governance cadence (pocket RACI)
- 10) Visualization and narrative (1 page, 3 lines)
- 11) Classic pitfalls and how to escape
- 12) Benchmarking and maturity
- 13) Improvement backlog (CSI Register)
- Wrapping it up
1) Purpose and scope
Start with the why (easy — we’ll get to the how). What business problem are you trying to solve: reduce cost per service, shorten time to restore, improve user experience? Define the scope (which services are in), the analysis period, and who is responsible for collecting and validating the data.
If “service” still feels abstract, take an internal pit stop: What is IT service management and what is it for.
2) Instrumentation and data quality
Minimum sources for measurement to make sense:
- Ticketing platform (categories, priority, times).
- Observability (metrics, logs, traces) and synthetic monitoring.
- Satisfaction surveys sent after resolution.
Indispensable hygiene: required fields, standardized taxonomy, change tags, and consistent collection times. Without this, any “average” becomes fiction. If availability is a recurring pain, this internal support helps organize things: Service Level Management.
3) Baseline, targets, and error budget
Let’s set the indicators so it all makes sense in the end. Here we go:
- Baseline: 90 days of history (mean/median) to anchor reality.
- Target: quarterly goal (e.g., MTTR –20%).
- Error budget: acceptable slack (e.g., 0.1% monthly unavailability).
- Threshold/alert: yellow (attention), red (immediate action).
MTTR = mean time to restore; MTTA = mean time to acknowledge.
4) The 5 decision‑making methods
The aim here is simple: connect what to measure with which decision to take and when to take it. No list for the sake of listing — each method below comes with practical use.
4.1 Service monitoring
Look at what the user feels first: availability, response time, time to restore, and integration health. Combine synthetic monitoring (the “robot‑user”) with real telemetry. A base guide helps align terms and practices: What is ITIL 4? — The definitive guide. What is ITIL 4? — The definitive guide. .
4.2 Customer satisfaction
Three different lenses, together:
- CSAT (interaction satisfaction): “was it good?”
- CES (customer effort): “was it easy?”
- NPS (loyalty): “would you recommend us?”
Good practices: short survey, right after resolution, with minimum sample and no forced response — this reduces bias and increases the data’s usefulness for prioritization.
4.3 KPIs by audience
It’s not a collection of numbers; it’s a collection of decisions.
- Executive (one page): service level objectives (SLO), CSAT/CES, cost per service, top risks.
- Management: 90‑day trend, improvement backlog, bottlenecks, and DORA metrics (lead time, deployment frequency, change failure rate, time to restore).
- Operations: queue, ticket age, reopen rate, peak hours.
SLA/ANS = service level agreement (contract). SLO = service level objective (operational target). XLA = experience objective (user perception). ITIL’s official guidance for cascading goals is well summarized in Axelos’ Direct, Plan and Improve material — align objective → indicator → metric, and only then pick the tool. Read the logic of cascading goals at Axelos: ITIL 4 DPI — cascading goals.
4.4 Regular reviews
- Daily (operations): service health, queues, risks.
- Weekly (management): trends, improvement hypotheses, blockers.
- Monthly (executive): goals, cost, initiative prioritization.
4.5 Trend analysis
Trend ≠ average. Look for seasonality (hours/days), recurrence by category, and effect after changes. Use fixed windows (e.g., 4 weeks) to compare fairly and avoid misleading “peaks.”
5) DORA metrics and day‑to‑day connection
To connect engineering, DevOps, and operations without process fights, track four metrics: lead time, deployment frequency, change failure rate, and time to restore. The 2024 DORA report highlights that AI adoption is already massive and affects productivity — but what really sustains improvement is platform + consistent metrics over time. See the official hub and report summary: State of DevOps — DORA.
Pro tip: when an SLO is breached, DORA metrics help explain why (e.g., spike in urgent changes, drop in test automation, review queues).
6) Cost per service (light FinOps)
Build a simple cost‑to‑serve: (infrastructure + licenses + people) divided by service consumption. Use it to decide where to automate, decommission, invest, or renegotiate. This ties in with service management fundamentals here: What is IT service management and what is it for.
7) Minimum KPIs by process
Yes, indicators again. Boring? A bit. Necessary? Absolutely — they matter, period.
Objective: use indicators to act — not to decorate the dashboard.
- Incident: MTTA (mean time to acknowledge), MTTR (mean time to restore), % within SLO, and 7/30‑day recurrence.
- Problem: time to root cause, time to countermeasure, % of problems that reduce incidents.
- Change: % success, rollback, cycle time by type, and urgent changes (risk indicator).
- Request: cycle time by category, % automation, and user satisfaction.
If planning is a bottleneck, this internal guide helps clear the path: Lack of planning when implementing ITSM: how to handle it.
8) Lean post‑incident (PIR)
No endless minutes. Answer: what happened, why, what changes, who owns it, when it’s reviewed. Publish the action and deadline on the same dashboard that shows the failure — this reduces recurrence and keeps the team accountable.
9) Governance cadence (pocket RACI)
- Who measures, who analyzes, who decides, who executes.
Bring product/business to the monthly table: “where to invest one euro to reduce friction and increase predictability?”
10) Visualization and narrative (1 page, 3 lines)
A good dashboard fits on one page: 5–7 KPIs, traffic lights, 90‑day trend, and a three‑line executive blurb (“what changed, why it changed, what we’ll do”). If the dashboard doesn’t change decisions, it’s ornament.
11) Classic pitfalls and how to escape
Uncle Adriano’s golden tip:
- Goodhart’s Law: when a metric becomes a target, teams “game the number.”
- Gaming: closing tickets without fixing causes to “improve” MTTR.
- Unfair comparisons: services with very different complexity on the same scale.
Antidote: clear definitions, decent sampling, and light auditing.
12) Benchmarking and maturity
Compare you with yourself (quarter vs. quarter) and, when it makes sense, bring in external references. Axelos, in Direct, Plan and Improve, reinforces the link between strategy and operations using cascading goals — objective → indicator → metric — and distributed governance. A good starting point is this material: ITIL 4 DPI — cascading goals.
Here, avoid looking at the neighbor’s lawn first… take a good look at your own backyard 😉
13) Improvement backlog (CSI Register)
For each bet: hypothesis → experiment → expected impact → owner → deadline → ROI. Prioritize with ICE (Impact, Confidence, Effort). Cut initiatives that don’t move KPIs — no mercy! ITIL has been saying this for years.
Obviously I’m not suggesting you ditch classic PDCA, but this is a more practical, growth‑oriented way to keep motion.
Wrapping it up
Good performance evaluation does one thing: turns data into decisions. Five methods, a bit of instrumentation care, a simple cadence, and a living backlog. Result? less friction, more predictability — and more focus on what matters: satisfied customers, stable services, and a team at peace with the dashboard.
If you need to level vocabulary and have a clear mental map to implement this consistently, start with the basics: the ITIL 4 Foundation course by PMG Academy. Complementary reading that helps connect the dots: What is ITIL 4? — Definitive guide. What is ITIL 4? — The definitive guide. .
Want quick help? Describe your scenario in two lines (service, pain point, and where you measure today) and I’ll reply with a draft of first steps.
Categorias
Artigos Relacionados
Performance Evaluation in Service Management
“In service management, if you don’t measure, you guess; if you measure, you decide.” Introduction
Avoid the 5 most common mistakes in implementing ITIL 4 or any ITSM framework with these helpful tips and practices
Value first, then the tool — less friction, more predictability. Introduction Let’s agree on one