Service level management I: SLAs, SLOs and agreements

Every service carries expectations. Users expect the shipment portal to be available when customers book freight; managers expect password resets to take minutes, not days; the finance team expects month-end reports on time. Unless those expectations are discussed and written down, the provider and its customers will judge the same service by different yardsticks, and both will be disappointed. Service level management is the practice that turns vague expectations into clear, agreed targets and then checks whether they are met.

This lesson covers the purpose of service level management, the kinds of agreement it produces, how to design good service level targets, and the arithmetic of availability and downtime that sits behind many of them. Lesson 3 covers measuring, reporting and reviewing service levels, including the watermelon effect.

Purpose of service level management

In plain words, the purpose of the service level management practice is to set clear business-based targets for service levels, and to ensure that delivery of services is properly assessed, monitored and managed against these targets. Each phrase matters. Clear means both sides understand the target in the same way. Business-based means the target reflects what the customer needs to achieve, not merely what is easy for IT to measure. Assessed, monitored and managed means the practice does not stop when an agreement is signed: it watches performance and acts when it slips.

Service level management is about more than documents. ITIL 4 emphasizes that it requires engagement: listening to customers, understanding their business, capturing their experience and building a shared view of what good looks like. A provider that writes agreements without talking to customers usually ends up measuring the wrong things.

Kinds of agreement

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. An SLA can be a formal contract with an external customer or an internal agreement between IT and a business unit. Internal SLAs are not usually legally enforceable, but they are still valuable as a shared statement of expectations.

An operational level agreement (OLA) is an agreement between two parts of the same organization, for example between the service desk and the network team, setting out what each will do to support the SLA. An underpinning contract is a legally binding agreement with an external supplier that supports the provider's commitments, such as a cloud provider's availability commitment or a hardware vendor's four-hour on-site repair. If the targets in OLAs and underpinning contracts do not support the SLA, the provider has promised something it cannot deliver.

Structuring SLAs

Organizations structure their SLAs in different ways. A service-based SLA covers one service for all customers who use it, for example a single email SLA for the whole company. A customer-based SLA covers all the services used by one customer group, for example everything LTS provides to the finance division. A multi-level SLA combines the two: a corporate level covers issues common to everyone, a customer level covers issues specific to a customer group, and a service level covers issues specific to a service. Multi-level structures reduce duplication and make updates easier in large organizations.

What a good SLA contains

A useful SLA is short, written in plain language and focused on outcomes. It typically includes a description of the service in business terms; the hours of service; the service levels, such as availability, performance, support response and resolution targets; how service levels will be measured and reported; the responsibilities of both the provider and the customer; how changes to the agreement are made; and how and when the agreement is reviewed. Some SLAs also include service credits or other consequences when targets are missed, especially with external customers.

The customer's responsibilities are often forgotten. A provider cannot meet a resolution target if the customer's staff do not respond to requests for information, or meet an availability target if the customer installs unapproved software on supported devices. Writing these responsibilities down makes the agreement fair.

SLIs, SLOs and SLAs

Site reliability engineering (SRE), a discipline that began at Google and is now widely used, adds useful vocabulary. A service level indicator (SLI) is a carefully defined quantitative measure of some aspect of the service, such as the share of portal requests that succeed or the share served within 300 milliseconds. A service level objective (SLO) is a target value or range for an SLI, such as 99.9 % of requests succeeding over a rolling 28 days. An SLA, in SRE language, is an agreement with consequences, usually commercial, that applies when an SLO is missed.

The SRE vocabulary fits well with ITIL. SLOs are often set internally at a tighter level than the external SLA, so the team has warning before the agreement is breached. ITIL-140 lesson 9 showed how SLOs and error budgets drive monitoring thresholds. Here the focus is on choosing the right indicators and targets in the first place.

Designing good service level targets

Poor targets are one of the most common failures in service level management. A target can be easy to measure but meaningless to the customer, such as server uptime when users care whether they can complete a booking. It can be impossible to measure, such as "the system will be fast". It can be set without regard to cost, such as five nines of availability for a service whose users would accept far less. Or it can be one of dozens of targets that nobody reads.

Good targets share several features. They are expressed in terms the customer recognizes, measured from the user's point of view where possible, specific about what counts and what does not, achievable at a cost the customer accepts and few in number. A helpful test is to ask the customer: if this target were met, would you be satisfied? If the answer is "not necessarily", the target is measuring the wrong thing.

Availability, nines and downtime budgets

Availability is the most common service level, so every service level manager needs to be comfortable with its arithmetic. Availability is usually expressed as the percentage of agreed service time during which the service was available. Agreed service time matters: a service promised from 06:00 to 22:00 on weekdays has far fewer hours to protect than one promised around the clock, and planned maintenance outside agreed hours does not count against it.

Targets are often quoted as nines: 99 % is two nines, 99.9 % is three nines, 99.99 % is four nines and 99.999 % is five nines. Each extra nine cuts the allowed downtime by a factor of ten and usually raises cost sharply, because it requires redundancy, automation, testing and around-the-clock staff. The downtime budget is the amount of unavailability allowed by the target over a period.

# Downtime budgets for common availability targets
periods = {"30-day month": 30 * 24 * 60, "quarter (91 days)": 91 * 24 * 60, "year (365 days)": 365 * 24 * 60}
targets = [99.0, 99.5, 99.9, 99.95, 99.99, 99.999]

def fmt(minutes):
    if minutes >= 60:
        return f"{minutes / 60:.1f} h"
    if minutes >= 1:
        return f"{minutes:.1f} min"
    return f"{minutes * 60:.0f} s"

print(f"{'target':>8} " + " ".join(f"{p:>18}" for p in periods))
for t in targets:
    cells = [fmt(m * (1 - t / 100)) for m in periods.values()]
    print(f"{t:>7}% " + " ".join(f"{c:>18}" for c in cells))

  target       30-day month  quarter (91 days)    year (365 days)
   99.0%              7.2 h             21.8 h             87.6 h
   99.5%              3.6 h             10.9 h             43.8 h
   99.9%           43.2 min              2.2 h              8.8 h
  99.95%           21.6 min              1.1 h              4.4 h
  99.99%            4.3 min           13.1 min           52.6 min
 99.999%               26 s            1.3 min            5.3 min

The table shows why a jump from three nines to four is a big decision. At 99.9 % a 24×7 service may be down for about 43 minutes a month, which a well-run team can absorb with one incident and a careful change. At 99.99 % the budget is about four minutes, which leaves no room for a slow manual recovery. A service that needs four nines needs automated failover and very safe change practices, and the customer should understand that cost before agreeing.

Composite availability

Services are built from components, and the availability users experience depends on how those components are combined. ITIL-130 lesson 11 showed that suppliers in series multiply their availabilities. The same logic applies inside the provider. When components are in series, all must work, so the service availability is the product of their availabilities and is lower than any one of them. When components are in parallel, the service works if at least one works, so the unavailability is the product of their unavailabilities and the service availability is higher than any one.

Real services combine both. The Larchmont portal depends on a network link, a pair of load-balanced web servers, an application server and a database. The web servers are in parallel with each other; the whole chain is in series. Working out the composite availability tells LTS whether its 99.9 % SLA is realistic and where redundancy would help most.

# Composite availability: series of blocks, where a block may be redundant (parallel)
def parallel(*a):
    u = 1.0
    for x in a:
        u *= (1 - x)
    return 1 - u

def series(*a):
    p = 1.0
    for x in a:
        p *= x
    return p

net, web, app, db = 0.9995, 0.995, 0.999, 0.9995
designs = {
    "current (2 web, 1 app)": series(net, parallel(web, web), app, db),
    "add 2nd app server": series(net, parallel(web, web), parallel(app, app), db),
    "add 2nd app + 2nd network link": series(parallel(net, net), parallel(web, web), parallel(app, app), db),
}
minutes = 30 * 24 * 60
for name, a in designs.items():
    print(f"{name:<32} {a * 100:8.3f} %   expected downtime {minutes * (1 - a):6.1f} min per 30 days")

current (2 web, 1 app)             99.798 %   expected downtime   87.4 min per 30 days
add 2nd app server                 99.897 %   expected downtime   44.3 min per 30 days
add 2nd app + 2nd network link     99.947 %   expected downtime   22.7 min per 30 days

These calculations assume components fail independently, which is often not true. A power failure, a bad change or a shared software bug can take down both web servers at once. Redundancy helps only against failures it actually separates. That is one reason service level managers work closely with availability management, change enablement and service configuration management.

Support targets: response and resolution

Alongside availability, most SLAs include support targets: how quickly the provider will acknowledge and resolve incidents and fulfill requests. ITIL-140 covered how these targets connect to priority. The service level manager's role is to make sure the targets are agreed with customers, supported by OLAs and underpinning contracts, and expressed in a way that can be measured fairly. Targets stated as percentages, such as 90 % of priority 2 incidents resolved within 8 business hours, are more honest than absolute promises, because a few outliers are inevitable.

Negotiating and agreeing service levels

Agreeing service levels is a negotiation, but a cooperative one. The service level manager brings knowledge of what the provider can deliver and at what cost; the customer brings knowledge of what the business needs. Good negotiation starts from business outcomes: what happens if the portal is unavailable for an hour on a Monday morning? How much revenue or reputation is at risk? From there, the parties can discuss whether the cost of higher availability is justified.

Some customers ask for the highest possible levels without considering cost. Showing a simple table of targets, downtime budgets and costs often helps. A customer who learns that moving from 99.9 % to 99.99 % would triple hosting costs and require a second data center may decide that 99.9 % with faster recovery during business hours is a better deal.

Legal and public-sector context

In the United States, agreements with external customers are governed by state contract law and, for goods, the Uniform Commercial Code. Federal agencies buying IT services set service levels in contracts under the Federal Acquisition Regulation (FAR), often using performance-based acquisition with measurable standards and quality assurance surveillance plans. Accessibility targets, such as conformance with the Section 508 standards, can also appear as service levels for public-facing digital services.

Whatever the jurisdiction, an SLA that will be legally binding should be reviewed by people qualified in contract law. This course teaches the service management side, not legal drafting.

ITIL (Version 5) note

Published summaries of ITIL (Version 5), checked in October 2026, list service level management as a product and service management practice, as it was a service management practice in ITIL 4. Its name and core purpose are unchanged in those summaries.