Managed IT service levels: what a useful SLA should measure

Begin with the business service

A useful service-level discussion starts with what people need to accomplish. “Keep the servers running” is less precise than “staff can submit and retrieve customer orders during agreed operating hours.” The latter helps identify the application, network, identity service and support coverage that matter. List the critical workflows and give each an accountable business owner before setting targets.

Google's Site Reliability Engineering workbook distinguishes a service-level indicator, which measures behaviour, from a service-level objective, which sets a target. A service-level agreement adds a business agreement and its consequences. [1] These terms provide a vocabulary; the practical contracting checklist below should be adapted to the actual service and reviewed by the people responsible for the agreement.

Separate three different clocks

An acknowledgement confirms that a request reached the support process. A response means an appropriate person has engaged with it. Restoration returns a usable service, potentially through a workaround, while permanent resolution addresses the underlying fault. An agreement that uses only “resolution time” can hide very different expectations about these stages.

Specify when each clock starts, whether it measures elapsed or supported business hours, and what pauses it. If supplier action or customer approval is required, record that dependency explicitly. Avoid allowing an unexplained ticket status to stop the clock. The ticket history should show what is needed, from whom, and when escalation becomes appropriate.

Write a severity matrix using impact

Describe severity through affected users, essential functions and available workarounds. A complete loss of a critical customer workflow may deserve a different response from one employee losing a convenience feature. Urgency also matters: a reporting issue during a deadline can have a greater impact than the same issue during a quiet period.

Agree who can declare or change severity and how disputes are handled during an incident. Provide examples drawn from real operations, then test the matrix with a tabletop exercise. The goal is a rapid shared decision, not a lengthy argument about terminology while the business is waiting. Keep security escalation separate where an incident needs specialist handling.

Choose measurements that reveal user impact

Define the observation point and calculation for each metric. Monitoring whether a process is running does not prove that users can complete a transaction. An availability measure should state the service boundary, observation interval, exclusions and treatment of maintenance. A latency target should say which transactions it covers and how slow results are counted.

Use both technical telemetry and support evidence. Compare monitoring alerts with incident tickets to find gaps, but avoid claiming that either source is perfect. Record missing data as a limitation. Review performance by service and severity rather than relying on a single average that can conceal a small number of serious failures.

Make escalation operational

The agreement should name contact routes, coverage periods, escalation roles and communication expectations. Define who coordinates multiple vendors when the failure crosses organisational boundaries. Include a fallback contact method for incidents that disable the normal ticketing or messaging platform. Maintain access procedures so responders can act without sharing personal credentials.

Specify what an incident update should contain: current impact, actions underway, any decision needed and the next update time. Estimates should be identified as estimates. After a material incident, capture contributing factors and corrective actions with owners. Closing the ticket should not erase unfinished preventive work.

Use the review to improve the service

Hold a periodic review of missed targets, recurring incidents, capacity concerns and outstanding actions. Ask whether the measurements still reflect business priorities. A provider can meet an initial response target consistently while users remain unable to work for too long; the review should make that mismatch visible and lead to a revised operating plan.

Evo's Managed IT Services can support monitoring, maintenance and service coordination. Bring a list of essential workflows, current suppliers and support hours to the discussion. A useful outcome is an agreed service catalogue, severity matrix, escalation map and reporting example that both sides understand before they need to rely on it.

Frequently asked questions