Service Level Agreements - SLA, SLO, SLI

People’s expectations of both free and paid services are high in our always-on world. Users expect speed, usefulness and usability to meet a high standard – and this increasingly applies to AI agents that take over tasks in your business processes.

SLAService Level Agreement

The agreement with your customers or users

SLOService Level Objective

The goals your team has committed to

SLIService Level Indicator

The real numbers of the service delivered

Why service level agreements?

Because of user expectations, it is important for companies to understand and maintain SLAs, SLOs and SLIs - three abbreviations that represent the promises we make to our users. They are internal targets that help us keep those promises based on traceable measurements and show us where we stand.

The goal of all three agreements is to get everyone – providers and customers alike – on the same page regarding system performance. How often will your systems be available? How quickly will your team respond when the system goes down? What promises do you make regarding speed and functionality? Users want to know – and that is why you need SLAs, SLOs and SLIs.

SLA: Service Level Agreements

What is an SLA?

An SLA (Service Level Agreement) is an agreement between provider and customer on measurable metrics such as availability, responsiveness and responsibilities.

These agreements are usually drawn up by a company’s business and legal departments and represent the promises you make to customers – and the consequences if you fail to keep them. Consequences typically include penalties, service credits or licence extensions.

Challenges of SLAs

SLAs are notoriously difficult to measure, report on and fulfil. These agreements – generally written by people who are not in the tech trenches themselves – often make promises that are hard for teams to measure, do not always align with current and constantly evolving business priorities, and do not allow for nuance.

For example, an SLA may promise that teams will resolve reported problems with product X within 24 hours. But the same SLA does not specify what happens if the client takes 24 hours to send answers or screenshots that help your team diagnose the problem. Does this mean the team’s 24-hour window was consumed by client delays, or does the clock start and stop based on the client’s response? SLAs need to answer these questions but often do not – a fact that has generated a great deal of hostility towards them among IT managers.

For many experts, the answer to this challenge is, first and foremost, that engineering should be involved in drawing up SLAs. The more IT and DevOps work with legal and business development to develop SLAs that relate to real-world scenarios, the more SLAs will begin to reflect important realities, such as customers delaying their own problem resolution.

Who needs an SLA?

An SLA is an agreement between a provider and a paying customer. Companies that offer users a free service are unlikely to want or need an SLA for those free users.

SLO: Service Level Objectives

What is an SLO?

An SLO (Service Level Objective) is an agreement within an SLA on a specific metric such as availability or response time. So if the SLA is the formal agreement between you and your customer, SLOs are the individual promises you make to that customer. SLOs set customer expectations and tell IT and DevOps teams which targets they must reach and be measured against.

Challenges of SLOs

SLOs are less hated than SLAs, but they can cause just as many problems if they are vague, overly complicated or impossible to measure. The key to SLOs that do not make your engineers tear their hair out is simplicity and clarity. Only the most important metrics should qualify for SLO status, targets should be worded in plain language and, as with SLAs, they should always account for issues such as client-side delays.

Who needs SLOs?

Whereas SLAs are only relevant for paying customers, SLOs can be useful for both paid and unpaid accounts, as well as for internal and external customers.

Internal systems such as CRMs, customer data stores and intranets can be just as important as external systems. Having SLOs for these internal systems is important not only for achieving business goals but also for enabling internal teams to achieve their own customer-facing goals.

SLI: Service Level Indicators

What is an SLI?

An SLI (Service Level Indicator) measures compliance with an SLO (Service Level Objective). For example, if your SLA states that your systems will be available 99.95% of the time, your SLO is likely to correspond to 99.95% uptime and your SLI is the actual measurement of your uptime. Perhaps it is 99.96%. Perhaps 99.99%. To meet your SLA, the SLI must meet or exceed the commitments made in that document.

Challenges of SLIs

As with SLOs, the challenge with SLIs is to keep them simple, to choose the right metrics to track, and not to complicate IT’s work by tracking too many metrics that do not actually matter to customers.

Create a detailed disaster recovery plan:

• What will you do when downtime occurs?
• If you do not yet know the answer to this question, the default answer is “waste precious time figuring out what to do”.

The better your incident response plan, the faster and more effectively your teams will handle incidents. That is why the first step of any new incident management programme should be process and planning.

Who needs SLIs?

Any company that measures its performance against SLOs needs SLIs in order to take those measurements. SLOs are not really possible without SLIs.

• SLAs: promises to customers.
• SLOs: internal targets.
• SLIs: how did we do?

Best Practices for SLA, SLO and SLI

Build SLAs around customer expectations

Every part of your customer agreement should be geared towards what matters to the customer. Behind the scenes, an incident may mean that 10 different components are involved. But from the customer’s point of view, all that matters is that the system works as expected.

Your SLAs and SLOs should reflect this reality. Do not make things too complicated.

SLOs for AI Agents

When AI agents take over tasks in your business processes, you need additional metrics besides availability and response time: How often does the agent deliver a correct result? How many cases are handed over to humans? What does a completed case cost? With clearly defined SLOs and continuously measured SLIs, the quality of AI agents becomes as verifiable as that of any other software.

How We Support You

• Gathering requirements together with business, technical and legal teams
• Defining clear and measurable SLAs, SLOs and SLIs
• Setting up automated monitoring and reporting
• Incident and disaster recovery plans
• Regular reviews and adjustment to new business priorities