Service Level Management

Service levels and service quality

Every service has a quality that people notice, whether anyone writes it down or not. Kestrel Energy's customers notice when the customer portal is slow on the first of the month, when a meter reading cannot be submitted, or when a call to the service desk takes three days to be answered. Service quality is the sum of those characteristics: how well a service does what its users and customers need, judged against what they expect.

A service level makes part of that quality measurable. It is one or more metrics that describe the quality a service is expected to deliver, or actually delivered: "the portal is available 99.9% of the time", "priority 2 incidents are resolved within 8 business hours", "95% of meter readings are processed within one hour". A service level can be a target (what we aim for) or a result (what we achieved last month); the comparison between the two is where the conversation starts.

Service level management is the practice that sets clear, business-based targets for service levels, makes sure they are measured and reported, and reviews them with the customer so the service keeps matching what the business needs. Without it, the IT department and the business each have their own idea of "good enough" — and they discover the difference during an outage.

The SLA from a service management view

The Cloud topic explains the service level agreement (SLA), service level objective (SLO) and service level indicator (SLI) as engineers use them: a cloud provider's availability promise with a service credit attached. In service management the SLA is the same kind of document, seen from the other side of the table: an agreement between a service provider and a customer that identifies the service and describes the service levels both sides expect. How engineers choose the indicators and set an internal objective stricter than the SLA is on SLIs, SLOs and SLAs.

Two things make a good SLA. It is agreed, not dictated: the customer says what the business needs, the provider says what that costs, and both sign. And it is written in business language. "The billing database cluster has 99.95% uptime" means little to Kestrel's head of customer operations; "customers can view and pay their bills online at least 99.9% of the time, measured per month" is something she can check and defend to her own director.

What goes in an SLA

An excerpt, as it might appear in the agreement:

Service:        Customer Portal (portal.example.com) and mobile app
Customer:       Kestrel Energy, Customer Operations
Provider:       Kestrel Energy, IT Department
Service hours:  24/7, excluding the maintenance window
                (Sunday 02:00-05:00, announced 5 working days ahead)

4.1 Availability
    Target: 99.9% per calendar month.
    Measured: a scripted login and bill view from two locations,
    every minute. A minute counts as unavailable when both fail.

4.2 Incident targets       Response       Resolution
    P1 Critical            15 minutes     4 hours (24/7)
    P2 High                30 minutes     8 business hours
    P3 Medium              4 bus. hours   3 business days
    P4 Low                 1 bus. day     5 business days
    P5 has no target in this SLA.
    Business hours: Monday-Friday 08:00-18:00, Dutch public
    holidays excluded.

SLAs, OLAs and underpinning contracts

The IT department can promise the business 99.9% availability for the portal, but it does not do all the work itself. The service desk logs the incidents, the network team keeps the connections up, and the portal itself runs at a cloud provider. If none of them has agreed to anything, the SLA is a promise made on their behalf.

• An operational level agreement (OLA) is an agreement between the service provider and another part of the same organization that it depends on. It is internal and usually not legally binding: "the network team responds to a P1 network incident within 10 minutes, 24/7".
• An underpinning contract (UC) is a contract with an external supplier that supports the service. It is a legal agreement with money attached: the cloud provider's own SLA and support plan, or the telecom carrier's repair times for the fiber to the data center.

The targets must fit together. If the SLA promises a P1 resolution within four hours, an OLA that gives the network team six hours to respond — or a carrier contract with next-business-day repair — makes the SLA impossible to meet from the start. Supplier contracts are managed in supplier management; service level management checks that their numbers support the SLA.

Measuring: response, resolution and business hours

Two clocks run on every incident. Response time runs from the moment the ticket is logged until someone qualified starts working on it — not until an automatic "we have received your message" email goes out. Resolution time runs until the service works again for the user. Response time is easy to meet and easy to measure, which is exactly why an SLA that only measures response says little about the service.

Most targets count business hours: a P3 ticket logged on Friday at 17:30 has used only 30 minutes when the weekend starts. The highest priority usually counts clock hours, because a portal outage on Saturday morning still needs someone to fix it. Your incident management tool does this calculation for every ticket; this program shows the rule it follows:

from datetime import datetime, timedelta

OPEN, CLOSE = 8, 18  # business hours: 08:00-18:00
TARGETS = {"P2": 8, "P3": 30, "P4": 50}  # resolution target in business hours


def add_business_hours(start, hours):
    """Return the moment `hours` business hours after `start` (Mon-Fri)."""
    remaining = timedelta(hours=hours)
    moment = start
    while True:
        day_open = moment.replace(hour=OPEN, minute=0)
        day_close = moment.replace(hour=CLOSE, minute=0)
        if moment.weekday() >= 5 or moment >= day_close:
            # weekend or after closing: jump to 08:00 the next day
            moment = day_open + timedelta(days=1)
            continue
        if moment < day_open:
            moment = day_open
        left_today = day_close - moment
        if remaining <= left_today:
            return moment + remaining
        remaining -= left_today
        moment = day_open + timedelta(days=1)


tickets = [
    ("INC-21017", "P2", datetime(2026, 10, 1, 14, 30)),  # Thursday afternoon
    ("INC-21022", "P3", datetime(2026, 10, 2, 16, 45)),  # Friday, late
    ("INC-21031", "P2", datetime(2026, 10, 3, 10, 0)),   # Saturday
    ("INC-21036", "P4", datetime(2026, 10, 5, 7, 15)),   # Monday, early
]

for number, priority, logged in tickets:
    due = add_business_hours(logged, TARGETS[priority])
    print(f"{number} {priority}  logged {logged:%a %d %b %H:%M}"
          f"  ->  resolve by {due:%a %d %b %H:%M}")

INC-21017 P2  logged Thu 01 Oct 14:30  ->  resolve by Fri 02 Oct 12:30
INC-21022 P3  logged Fri 02 Oct 16:45  ->  resolve by Wed 07 Oct 16:45
INC-21031 P2  logged Sat 03 Oct 10:00  ->  resolve by Mon 05 Oct 16:00
INC-21036 P4  logged Mon 05 Oct 07:15  ->  resolve by Fri 09 Oct 18:00

Real tools add public holidays, different calendars per customer, and paused clocks: while the service desk waits for the user to answer a question, the resolution clock usually stops. Write down in the SLA when the clock pauses — otherwise "waiting for user" becomes a status that hides slow work.

Availability per month

An availability percentage only means something once you translate it into minutes. The program below uses a 30-day month (43,200 minutes). The Cloud topic uses an average month of one twelfth of a year, which gives 43 min 48 s for 99.9%; a 31-day month allows 44 min 38 s. The SLA should state which basis it uses.

MONTH_MINUTES = 30 * 24 * 60  # a 30-day month has 43,200 minutes

print(f"{'Target':<8}{'Downtime allowed':>18}{'Minutes':>10}")
for target in (99.0, 99.5, 99.9, 99.95):
    minutes = MONTH_MINUTES * (100 - target) / 100
    hours, rest = divmod(round(minutes * 60), 3600)
    mins, secs = divmod(rest, 60)
    allowed = f"{hours} h {mins:02d} min {secs:02d} s"
    print(f"{f'{target:g}%':<8}{allowed:>18}{minutes:>10.1f}")

Target    Downtime allowed   Minutes
99%        7 h 12 min 00 s     432.0
99.5%      3 h 36 min 00 s     216.0
99.9%      0 h 43 min 12 s      43.2
99.95%     0 h 21 min 36 s      21.6

Forty-three minutes a month is less than one slow database failover plus the time to notice it. Before signing 99.9%, check that the OLAs and contracts underneath can actually deliver it, and agree how availability is measured: from the user's side (a scripted login) or from a server that says it is running while nobody can reach it.

A per-minute check like this measures time-based availability; request-based availability counts failed requests instead and can give a very different number.

The watermelon effect

The watermelon effect is a service that looks green on the outside — every SLA target met — and is red on the inside: users are frustrated and the business is unhappy. It happens when the metrics measure what is easy instead of what matters.

Kestrel's monthly report shows 100% of P3 tickets responded to within four hours. Meanwhile the customer contact center complains that the billing screens freeze for a few seconds several times an hour. Nobody logs those freezes as incidents anymore ("it always does that"), the availability check does not cover the contact center's billing screens, and so nothing in the report is red. The customer stops trusting the report, and then stops trusting IT.

Typical causes:

• Measuring components (server uptime) instead of the service as users use it (can a customer pay a bill?).
• Measuring response but not resolution, or resolution of tickets that were reopened three times.
• Averages that hide the bad cases: an average resolution of 6 hours can contain a ticket that took two weeks.
• Problems users have given up reporting.

Experience level agreements

An experience level agreement (XLA) is an agreement about how a service should feel to the people who use it, rather than only about technical performance. It combines operational data with measures of experience and sentiment: short surveys after a ticket is closed, how much time users lose to slow or failing tools, how often they work around IT instead of asking for help.

An XLA for Kestrel's contact center could say: "agents rate the billing system 4 out of 5 or better on average, and lose less than 10 minutes per shift to IT problems". Measuring that needs both a short weekly pulse survey and endpoint data (screen freezes, application crashes). XLAs do not replace SLAs — the 99.9% still matters — but they catch the watermelon before the customer cuts it open.

Service reviews and reporting

A service review is a regular meeting between the provider and the customer to look at how the service performed against the agreed levels, what users experienced, and what should change. At Kestrel, Sanne (the portal's service owner) meets the customer operations manager every quarter with a short report:

Customer Portal - Q3 2026 service review

Availability      Jul 99.97%   Aug 99.84% (!)   Sep 99.95%    target 99.9%
P1 incidents      1 (Aug 14, payment page down 71 min, cause: expired
                  certificate at the payment provider)
P2 resolution     94% within 8 business hours            target 90%
User rating       3.6 / 5 after ticket closure (Q2: 3.9)

Actions agreed
1. Certificate expiry monitoring for all supplier endpoints (owner: Ravi)
2. Investigate drop in user rating: survey comments mention slow
   meter-reading upload on mobile (owner: Mei)
3. Next review: 14 January 2027

A good review spends little time on the green numbers and most of its time on the actions: what went wrong, what the trend is, what the customer's plans for next quarter mean for the service. Review the SLA itself too — targets that no longer match the business are a reason to renegotiate, not to keep reporting. Improvements that come out of reviews go into continual improvement.

Common mistakes

• Too many metrics. An SLA with forty targets is a report nobody reads. Pick the few that the customer actually cares about and that tell you when to act.
• Targets nobody can influence. A target for the speed of the customer's home internet, or a resolution time for issues that depend on a supplier with no matching contract, only produces breaches and excuses.
• An SLA without OLAs. The service desk promises four hours; the database team has never heard of that number.
• Only response time. Answering in five minutes and solving in five days still meets a response-only SLA.
• Copying the cloud provider's percentage. If the platform promises 99.95%, the service built on it — with your own code, network and changes on top — will be lower.