SLAs that measure what the business cares about

The monthly report says every service level agreement was met. The meeting with the business, however, opens with complaints: the mobile app was slow all through month-end close, payments failed intermittently and nobody gave notice. Both things can be true at once. When that happens, the problem is not in the operation but in what the agreement chose to measure.

The watermelon effect

The watermelon effect is the indicator that is green outside and red inside. Its causes are well known:

• Measuring the component, not the service. For example, the server was available 99.9% of the time, but the transaction the customer uses depends on ten components and a third party.
• Measuring the average, not the experience. Mean response time looks good, but some users wait much longer, and they are exactly the ones who call.
• Measuring the process, not the outcome. For example, 98% of tickets were answered within the timeframe, but "answered" means an automatic acknowledgment was sent.
• Excluding what is inconvenient. Wide maintenance windows, degradations that do not count as outages, or incidents reclassified so they do not affect the indicator.

None of these practices is dishonest in itself. The problem is the result: a report the business cannot use to make decisions, and an operation that optimizes the indicator instead of the service.

SLA, OLA and SLO: three different tools

Part of the confusion comes from using "SLA" for everything. It helps to separate three concepts:

Concept	Between whom	What it is for
SLA (service level agreement)	The service provider and its customer, internal or external	Documenting the expected level of service and how it will be measured, in terms the customer understands
OLA (operational level agreement)	The provider's internal teams (network, databases, service desk)	Making sure each team commits to what the SLA needs from it
SLO (service level objective)	Mostly internal use, within site reliability engineering practice	Setting a measurable target on a specific indicator, with a tolerated error margin

On top of these come support contracts with third parties, which must be aligned with the SLAs that depend on them. A four-hour restoration SLA cannot hold if the network carrier has eight hours to respond.

The SLO approach, popularized by Google's site reliability engineering (SRE), brings a valuable idea: the error budget. If the target is 99.5% successful requests, the remaining 0.5% is a margin the team can spend on changes and experiments. When the budget runs out, stability becomes the priority. This turns the target into a decision-making tool, not just a reporting one.

Service level management in ITIL 4 and the SLO approach do not compete. SLOs can be the technical foundation on which the SLAs agreed with the business are built.

Defining measures from the user journey

The starting question is not "what can we measure" but "what is the user trying to do, and what does it mean to them that it works". We recommend this process:

1. Identify the critical journeys. With the business owner, choose the three to five journeys that matter most: signing in, checking a balance, making a payment, issuing a policy, booking an appointment.
2. Define success for each one. For example: "the payment completes without a technical error and the user sees the confirmation in under five seconds".
3. Choose the indicator. Share of successful attempts, response time percentile or data freshness, depending on the journey. Avoid averages.
4. Decide how to measure it. Real transactions observed from the application, synthetic transactions that simulate the user, or both. The former show what happened; the latter catch failures when traffic is low.
5. Set the target with data. Look at several months of history before committing to a number. A target that is always met effortlessly tells you nothing; one that is never met demoralizes.
6. Cascade it inward. Translate each measure into commitments for internal teams (OLAs) and for third parties.

Measuring journeys requires the application to be observable: correlation identifiers, traces propagated across services and business metrics that record completed and failed operations. A monitoring platform can capture a lot, but if the application cannot tell a payment rejected for insufficient funds from one that failed because of a technical error, the indicator will not be reliable.

Experience alongside availability

Availability is still necessary, but it is not enough. A service can be "up" and unusable. Pair it with experience measures:

• Perceived performance: high percentiles (for example, the 95th) of response time on critical journeys.
• User error rate: share of operations that fail for technical reasons.
• Post-contact satisfaction: one short question when incidents and requests are closed.
• Effort: how many times the user had to get in touch to resolve the same issue.

Some organizations formalize these measures as experience level agreements (XLAs). The name matters less than the idea: include in the agreement at least one measure that reflects what the user perceives, not only what the infrastructure records.

An example SLA table

The following table is an illustrative example for an online banking service. The targets are not recommendations: each organization should set them based on its history, its risk and what it agrees with the business.

Measure (example)	Definition	Target (example)	Period
Sign-in success	Sign-in attempts completed without a technical error, out of the total	99.5% or higher	Monthly
Balance inquiry performance	95th percentile of time until the account summary is displayed	3 seconds or less	Monthly
Transfer success	Initiated transfers completed without a technical error	99% or higher	Monthly
Priority 1 incident restoration	Time from logging to service restoration	4 hours or less in 95% of cases	Quarterly
Service desk satisfaction	Average closing survey score, 1 to 5 scale	4 or higher	Monthly

Notice what the table leaves out: neither the availability of a specific server nor the first response time of a ticket. Those measures can live in OLAs or internal dashboards, where they are useful for running the operation.

Review cadence and reporting

An SLA is not a document you sign and file away. It is a recurring conversation. We recommend three levels:

• Continuous tracking (operations): real-time dashboards with the indicators for critical journeys, and alerts when error budget consumption speeds up.
• Monthly review (service): a short report with achievement, the incidents that most affected each measure, open problems and actions in progress. One page per service is usually enough.
• Quarterly or half-yearly review (business): with the service owner, to check whether the measures still reflect what matters, adjust targets and agree on improvement priorities.

For the monthly review, we recommend a fixed structure: each measure's value against its target, the trend over recent months, the two or three events that explain the deviations, the status of related problems, and commitments for the next period. Keeping the same structure every month makes comparison possible and stops the report from becoming a different presentation each time, built to justify the result.

A good service level report answers three questions: how did it go for the user, why, and what will we do about it. If it only answers the first with a traffic light, it is a compliance report, not a management one.

A useful signal for spotting the watermelon effect: compare SLA achievement each month with business satisfaction and complaint volume. If they move in opposite directions, the agreement needs a review.