7.2 Service Level Management

Service Level Management: Purpose

The purpose of the service level management (SLM) practice is "to set clear business-based targets for service performance, so that the delivery of a service can be properly assessed, monitored, and managed against these targets." Note the three verbs the exam loves: assessed, monitored, and managed. SLM is not just about writing an agreement — it is the ongoing discipline of agreeing realistic targets and then continually checking whether they are met.

The word business-based is deliberate. Targets must be expressed in terms that the customer's business cares about, not just in internal technical language.

What is an SLA?

A service level agreement (SLA) is a documented agreement between a service provider and a customer that identifies both the services required and the expected level of service. SLAs have been used since the earliest days of IT service management, but ITIL 4 warns they are often misused — used as a way to apportion blame, or built around metrics that look good but do not reflect the customer's real experience.

A single SLA is rarely enough

ITIL 4 cautions that using a single SLA per service is usually too simplistic, because a service may support many different customers and use cases, each with different needs. Targets must reflect what each group of consumers actually requires. The exam wants you to see the SLA as a living tool for a conversation, not a contract drawer-filler: it should drive regular service reviews where provider and consumer discuss performance, expectations, and improvements together.

Requirements for a good SLA

ITIL 4 lists clear requirements for SLAs that actually work. Expect a question that asks you to pick one (or to identify a poor SLA).

ITIL 4 also recommends using balanced bundles of metrics — for example, combining customer satisfaction with critical business outcomes — rather than a single operational number that can be gamed.

The watermelon SLA (anti-pattern)

The watermelon SLA is the classic warning ITIL 4 uses. The agreement is green on the outside — every operational metric (uptime, ticket-response time) is reported as met — yet red on the inside because the customer is actually dissatisfied. This happens when SLAs measure only individual operational metrics instead of the end-to-end service outcomes the customer experiences. The lesson: measure what the customer feels, not just what is easy to count.

For example, a help-desk SLA might report that 95% of tickets were answered within target — all green — while users are furious because their actual problems took days to resolve end-to-end. The individual metric was met, but the outcome the customer cared about was not. ITIL 4 fixes this by insisting that targets relate to outcomes and by using balanced bundles of metrics that include the customer's own view of the service.

SLRs, OLAs, and underpinning contracts

SLM relies on a hierarchy of supporting agreements:

• Service level requirements (SLRs): a detailed set of the customer's needs used to define and shape the design of a service. SLRs are captured early and feed the targets that eventually become the SLA.
• Operational level agreements (OLAs): internal agreements between the service provider and another internal team (department) that supports delivery of the service. OLAs underpin the SLA.
• Underpinning contracts (UCs): external contracts with third-party suppliers whose services contribute to meeting the SLA. (UCs are managed through the supplier management practice.)

If any OLA or UC target is weaker than the SLA promises, the SLA cannot reliably be met — alignment across all three layers is essential.

Metrics, listening, and engagement

SLM is built on engagement and listening, not just measurement. ITIL 4 stresses that SLM requires two activities done well:

1. Engagement — understanding day-to-day needs, gathering requirements, setting realistic expectations, and capturing feedback.
2. Measurement and reporting — collecting, analyzing, storing, and reporting relevant metrics for the agreed services.

Good SLM uses several sources of input: customer engagement (interviews, surveys), customer feedback (satisfaction surveys, complaints), operational metrics (low-level technical measures), and business metrics (the activities the customer values). Together these give a rounded view of whether the service is genuinely delivering value — and they prevent the watermelon effect.

Skills the practice depends on

ITIL 4 notes that effective SLM needs people who can build relationships and communicate with customers, not just analysts who crunch numbers. Practitioners must understand the customer's business, listen actively, ask the right questions, and translate technical performance into business language. They also need to negotiate realistic targets and to manage expectations honestly — promising a level the provider can actually sustain.

This relationship focus is why SLM sits among the general management practices and links closely to relationship management: an SLA built without genuine engagement quickly drifts into a watermelon, where the report says success but the customer feels failure.