Service Management Blog

SLAs vs OLAs: Comparing Service and Operational Agreements

4 minute read
Kirstie Magowan

I often see some confusion between service level agreements (SLAs) and operational level agreements (OLAs). I think the easiest way to explain it is to think about like this:

sla-vs-ola

However, in today’s world of complex services sourced from multiple suppliers, the distinction may be a little more confusing. Let’s take a look.

SLAs & OLAs in traditional IT environments

In earlier times, a service consumed by a customer would most likely be supplied and supported within your own organization. You would put in place an SLA with the customer that explains:

  • When the customer would be able to access the service
  • How reliable it would be
  • When it may be unavailable for scheduled maintenance
  • Other similar measurements

The SLA would, in turn, be supported by OLAs with other internal suppliers, such as:

This situation is easy to understand, easy to manage, and normally makes for easier negotiation of the customer-facing SLA.

SLAs & OLAs in complex environments

In an environment where services are put together using components from multiple suppliers, as is the case for most organisations today, this picture is not as clear.

A service will have its customer-facing SLA, just as it did in the earlier scenario. In turn this SLA is likely to be backed up with internal OLAs, as before. But—here’s the difference—the SLA will also be supported by the SLAs that you have negotiated, as a customer, with your own vendors. These should be treated in the same way as OLAs in this scenario: they must support the customer-facing SLA.

This situation can turn negotiating the SLA with your customer into a complex balancing act with often conflicting timeframes that you must consider.

Understanding SLAs

The SLA represents the commitment of the entire IT organization to its customer to provide a service that meets their expectations. In a multi-sourced environment, this includes third-party suppliers.

SLAs address business level requirements. The business will not be interested in how many hours each of the different teams will need to replace disks, backup and restore files, roll forward the database, or restart servers and applications.

Instead, the business wants to know how long they can realistically expect a service to be unavailable following an outage—this is what you’ll outline in the SLA.

SLAs are all about managing expectations.

Understanding OLAs

The OLAs are the tools that you use to set these expectations. Establishing a workable SLA for a complex service is something like putting a jigsaw puzzle together. Each piece needs to fit with the others in order to build a workable picture.

The OLA clearly articulates what each functional IT group will need to do, in relation to each other, to support the SLA. This will include things like:

  • What the server team will do for patching of the servers
  • What the desktop team will do to patch the desktop systems
  • What the DBAs will do to optimize the databases
  • How the service desk will respond to incidents and requests
  • And more…

The promises that you make in the SLA must be measurable and completely supported by the OLAs that the SLA relies on.

Real-world examples

If your customer requires a service to have no more than two hours of consecutive downtime at any time of the day or night, you must ensure that every OLA that supports that service allows you to promise that level of service.

If the vendor that supports the database for the service, for example, has an OLA with you that gives a two-hour restoration time only during business hours, you cannot agree to a two-hour restoration time, 24-hours a day with your customer. It is likely that your vendor will agree to providing the level of service that your customer is requesting—but is your customer prepared to pay for it?

Consider also that, during a service failure, it is quite likely that you may go through multiple teams or vendors before you are able to resolve the situation. Each of these will be running under their own OLA or SLA with you. Each time a new partner is brought in to look at the failure, their clock starts.
For this reason, all suppliers need to be involved from the outset if you are to meet the SLA timelines agreed with your customer.

Best practice: Negotiate OLAs first

Understanding what your internal service providers and your vendors can provide, and at what cost, is critical. You must understand any limitations, cost differentials, and other factors before you negotiate the SLA with your customer. The OLAs are your building blocks, so they must be in place first.

The biggest and most common mistake I see is this: you agree and sign off on an SLA with a customer. Then, after agreement, the service level manager heads off to negotiate supporting OLAs with internal and external suppliers…only to find that the agreed SLAs are unsupportable, at any cost, sending you back to your customer to start over.

Challenges for service level managers

Today’s service level manager has a job that is far more complex than it was earlier. One service may require input from multiple internal and external teams in order to meet customer requirements. I warn you: the complexities will not stop there.

Imagine you are purchasing infrastructure as a service (IaaS) from one vendor. That vendor, in turn, uses another vendor to supply security gateways. You will have to rely on your vendor having a properly negotiated OLAs with their supplier. While contractually the onus is on the vendor you have the direct relationship with, that does not really matter to your customer—all your customer is concerned with is that the service they’re consuming performs in accordance with their SLA with you.

My recommendation is this: Never assume anything. Ask to see your vendors’ agreements with any suppliers who are supporting services that you consume from them. Your responsibility is to provide the agreed service level to your customer. Telling them that it is ‘not my fault’ is unlikely to go down well—so do your due diligence up front.

While SLAs and OLAs will contain much of the same type of information, they do perform different roles. Make sure that all your building blocks are in place, stable, and well supported from end to end. Without this you will not be able to agree service levels with your customers with any confidence.

SLAs are all about managing expectations. OLAs are the tools that you use to set these expectations.

Additional resources

For more on this topic, explore our BMC Service Management Blog and these articles:

E-book: Choosing the Right Metrics for Enterprise IT

Every business and organization can take advantage of vast volumes and variety of data to make well informed strategic decisions — that’s where metrics come in. This e-book introduces metrics in enterprise IT. Organizations of all shapes and sizes can use any number of metrics. In this e-book, we’ll look at four areas where metrics are vital to enterprise IT.


These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.

Business, Faster than Humanly Possible

BMC empowers 86% of the Forbes Global 50 to accelerate business value faster than humanly possible. Our industry-leading portfolio unlocks human and machine potential to drive business growth, innovation, and sustainable success. BMC does this in a simple and optimized way by connecting people, systems, and data that power the world’s largest organizations so they can seize a competitive advantage.
Learn more about BMC ›

About the author

Kirstie Magowan

Kirstie has been active in service management since 2000, working in a wide range of organizations, from primary industry to large government entities, across New Zealand and Australia. Kirstie has spent much of the past 15 years working at a strategic level as an ITSM consultant. She regularly takes on operational assignments to remember what it's like to be on the ‘coal face’ of service management, as this allows her to provide real and actionable advice as a consultant. Kirstie first qualified as an V2 ITIL Manager in 2004 and spent four years working as the Chief Editor for itSMF International from 2012 where she built a strong global network of service management experts. Kirstie is a member of the authoring team for the ITIL4 book - Direct, Plan and Improve, and a contributing author to the ITIL4 practice guides.