Measuring, reporting and continual improvement of service levels
Domain 5 tests whether you can measure, report and improve service levels honestly, and choose the right metric for a scenario.
Measure the right things
SLM’s own effectiveness uses a small indicator set: percentage of services covered by an agreed SLA; SLA compliance against target; number and severity of breaches; restoration time versus target; customer satisfaction or service experience scores; percentage of service reviews held as scheduled; percentage of improvement actions closed on time; accuracy and timeliness of reports. Availability alone is not enough - a service can hit 99.95% while users abandon it.
Reporting rules
Match the report to the audience: executives need trends, risk and customer impact; technical teams need component detail. Report trends rather than single snapshots, report bad news as well as good, keep definitions stable so months stay comparable, and attach the action. The classic failure is the watermelon report - green outside, red inside - which usually means the metric measures infrastructure rather than the service the customer experiences.
Review and improve
Service reviews are the engine: inputs are performance reports, incident and problem trends, complaints and survey results; outputs are agreed actions with owners and dates, plus SLA changes. Breaches and repeated near-misses are improvement triggers. Apply the ITIL 4 continual improvement model - vision, current state baseline, target state, plan, act, check, keep momentum - or a simple PDCA cycle.
Worked example
Availability reports 99.95% against a 99.9% target, but satisfaction fell from 4.2 to 3.6. First verify the measurement: availability taken on servers rather than the user journey explains the gap. Add SLOs for transaction success and peak-hour response time, baseline them, run a two-week improvement iteration, then re-measure performance and satisfaction.
Traps
Reporting only green; measuring what is easy to instrument; no baseline before setting targets; improvement actions with no owner or date; tightening targets to fix a problem instead of fixing the system.