Disruption is inevitable. This guide outlines five strategies that can increase the digital resilience of your organization, including how to achieve greater observability maturity and how security vendor consolidation can reduce complexity.
Published Date: April 4, 2023
Service level agreements, or SLAs, are used in the technology industry to define the agreed-upon metrics used when a vendor supplies a service to a customer. SLAs may define a minimum level of uptime, a floor for response time, performance standards or overall bandwidth, other measurements of the quality of a technology service, and even a minimum level of aggregate customer satisfaction. SLAs specify specific, quantitative measurements that must be adhered to — and outline penalties if SLAs are missed. These penalties can include financial discounts or even the right to terminate services without consequence (such as forfeiting a deposit). As an example, a typical cloud service SLA might provide a service credit of 10 percent of a month’s bill if total monthly uptime falls below 99.99 percent — and more if uptime falls even lower.
SLAs are included in many if not most contracts for technology services, ranging from cloud service operations to internet access. Many outsourcing providers — such as call center operations — also include SLAs as part of their contracts.
SLAs are legal agreements and as such are often subject to review by attorneys before they are signed. This is especially common among large enterprises doing business together, where SLA terms and benchmarks may be hotly negotiated in advance, along with more traditional terms like the price and length of the service contract. In cases where a startup is looking to engage with a larger, more established customer, an SLA that promises a high level of service performance and stiff penalties if that level is not reached can be an effective tool to closing a deal.
In this article, we’ll discuss the various types of SLAs, what to look for in an SLA, and the myriad advantages that SLAs can provide to the players on both sides of the agreement.
What are the different types of SLAs?
The industry generally recognizes three general types of SLAs, each of which can include a wide range of more specific SLAs. The three broad categories are as follows:
- Customer SLAs: These SLAs specify service levels from a service provider to a single customer. These SLAs can be negotiated individually from one customer to the next, specifying service deliverables, the terms of that service and the standards by which that service is provided. If these terms are not met, the SLA provides the terms of recourse for the customer.
- Service SLAs: Service SLAs are broad agreements that apply to all the users of the service. These types of SLAs are generally simpler in nature and are not considered negotiable. The terms of service contracts that users must sign to access a web-based service are a good example of service SLAs — boilerplate agreements which apply to anyone who agrees to use the service. Service SLAs generally offer minimal recourse in the form of penalties against the provider.
- Multi-level SLAs: With a multi-level SLA, different service levels are set to apply to different types of customers. Multi-level SLAs are the most complex type of SLA but provide some level of customization without requiring negotiation for each specific customer. For example, a multi-level SLA could provide one level of service for “free” users who don’t pay for a service, enhanced service for those who pay a nominal fee and a higher tier of service for those who pay premium rates.
SLAs can also be generally categorized based on the signatory for the SLA: internal (for use within the organization), external (any agreement with an external customer, like a customer service level agreement), or vendor (for use with organizations with which your company is the customer). SLAs can fall into both of these categories simultaneously. For example, an SLA can be both a customer SLA and an external SLA.
What is a vulnerability SLA?
While SLAs are commonly used to set minimum service levels related to performance and uptime, they can also be used to ensure products used by an organization are kept secure and free of vulnerabilities.
A vulnerability SLA is most commonly used to specify that a company fix any vulnerabilities that are discovered within a certain timeframe. The vulnerability SLA may set different targets for different severity levels of the vulnerability. CVSS scores are commonly used in this calculus. A vulnerability with a Low severity rating may be required to be patched within 90 days, while one with a High severity rating may require patching within a month or, increasingly, 14 days.
Vulnerability SLAs give customers some level of recourse against sloppy development practices which could put the user at risk of an attack which targets third-party software or service.
What is SLA compliance?
SLA compliance is achieved by meeting agreed SLA measurements. When an SLA is not being met, the SLA is said to be out of compliance.
SLA compliance is most commonly referenced in relation to an SLA compliance ratio, which is also known as the SLA success rate. The SLA compliance ratio measures the percentage of time an SLA is in compliance and can be measured over any set time frame. This is most easily calculated when the SLA relates to a specific number of activities or incidents. For example, consider an SLA that specifies that help desk support calls must be resolved within 60 minutes. If, during one week, 95 calls are resolved faster than 60 minutes and 5 are resolved slower than 60 minutes, then the SLA compliance ratio is 95 percent. The SLA itself should specify penalties for the SLA compliance ratio falling below a certain level.
Note that the SLA compliance ratio may be less useful than the SLA metric (or the SLI, which we’ll discuss later) in many cases, such as in time-based measurements such as network availability. If an SLA states that monthly uptime of 99.99 percent must be achieved, an SLA compliance ratio would not be meaningful in the short term. Only in examining a long-term series of these time frames would these ratios be of much use – such as by providing the percentage of time the provider achieved a daily minimum uptime level over the course of a year. That said, in most cases, a measurement of the total uptime rate over that entire one-year period would likely be a more useful metric than the SLA compliance ratio.
Regardless of the metric, the onus of SLA compliance is generally the responsibility of the customer to monitor. In most cases, it is unlikely that a service provider will proactively indicate when it is not in compliance with an SLA. This is the function of SLA compliance monitoring tools and strategies.
What are some examples of an SLA in practice?
A wide range of SLAs are in common use. Here are some examples:
- Uptime: Arguably the most common type of SLA. An uptime SLA will mandate a certain level of service availability for a technology service, ranging from cloud services to an internet backbone connection. Various legislative orders require or strongly suggest SLAs for essential services, including internet access.
- Call Center Metrics: SLAs are the rule in call center and other help desk operations, specifying minimum service levels such as maximum hold time, maximum call length, and even the number of rings allowed before the phone is answered.
- Customer Satisfaction: Satisfaction SLAs are used for call centers and many other customer support operations, including offline examples, such as repair services or facilities maintenance.
- Product Quality: A quality-based SLA would specify a maximum error or defect rate in the delivered, finished goods from an outsourced manufacturer or producer.
- IT Operations Metrics: Mean Time to Recovery (MTTR) and Mean Time Between Failures (MTBF) are common SLAs used in IT operations. These SLAs specify the amount of time it takes for incidents to be resolved satisfactorily and the length of time between incidents, respectively.
- Other Business Metrics: SLAs can be used in nearly any business function, ranging from sales (number of leads contacted per week) to human resources (maximum time before a new hire is fully onboarded). Like external SLAs, these can be used to measure the quality of service from nearly any department or business function.
SLAs can be used across any business function to measure quality of service.
What are SLAs in ITIL?
ITIL is a framework that defines best practices for IT Service Management (ITSM) within an organization. SLAs are a major part of Service Management, with ITIL 4 defining them as “A documented agreement between a service provider and a customer that identifies both services required and the expected level of service.”
In ITIL, SLAs are internal facing. Otherwise, they function identically to the more common external-facing SLA. In short, ITIL specifies that when IT creates or alters a service which it is provided, an SLA should accompany it. For example, one internal SLA might hold that IT will complete password resets within 30 minutes of a request. Or, it might determine the service desk response time expected by the IT service provider. SLAs should be agreed upon by both the IT department and the business at large such that both groups agree it is realistic and attainable.
An IT department which adopts ITIL will likely have dozens of SLAs to govern its service catalog, one for each service it provides. ITIL services are narrowly defined: The terms around the termination of an account and the creation of a new account would be governed by separate SLAs. As with external SLAs, internal SLAs created with ITIL in mind should be regularly reviewed for relevance, measurability, timeliness, and achievability – and should be revised if they fail on any of those fronts.
How do SLAs relate to KPIs?
Key Performance Indicators, or KPIs, are at the core of SLAs. KPIs are the specific metrics that are used to tell whether the organization is performing well, and they are always linked to business performance. KPIs may relate to customer satisfaction — and if customer expectations are unmet — the performance of a service offered, fraud rates, and more – as long as those topics are strategic goals of the organization. KPIs can be thought of as the “vital signs” for a business, the core metrics which determine whether or not the organization will be successful.
The primary difference between SLAs and KPIs is that KPIs do not relate to the provider of a service. KPIs are more abstract in nature, although they may ultimately overlap and measure some of the same data. For example, a business may have a KPI related to service uptime, with a goal of providing 99.999% availability of its mobile app. However, if the business outsources the delivery of that app to a third party, it isn’t in complete control over that KPI. As such, an SLA would be involved with ensuring the delivery provider is meeting its goals of providing 99.999% availability to the company. While these may seem identical at first, they aren’t. The external service provider is likely only partially responsible for the delivery of the app. Other factors involved may influence the KPI of 99.999% availability, including the stability of the app’s code base, the user’s internet connection and device, and other variables. Ultimately, the SLA is much more narrowly defined and limited in scope than the KPI.
How do SLAs relate to SLOs?
SLOs are Service Level Objectives. These are the specific metrics defined within an SLA. The SLA as the broad contract between a provider and a consumer of a service and includes the scope of services provided, the responsibilities of the customer, and the penalties for failure to meet the terms of the agreement. The SLOs are simply the performance metrics specified within that agreement. For example, if an SLA specifies 99.999% uptime, the SLO is 99.999% uptime. That metric plus all the other terms of the agreement comprise the SLA.
How do SLAs relate to SLIs?
SLIs are Service Level Indicators. They are measurements of how well a provider is meeting its Service Level Objectives. If the SLA specifies 99.999% uptime and the vendor is providing 99.997% uptime, then 99.999% is the SLO and 99.997% is the SLI.
In practice, most people use the term SLA loosely to refer to all of these things, so it’s important to understand if a speaker is actually intending to refer to an SLO or an SLI when SLAs are discussed.
Why are SLAs important to an enterprise?
SLAs are important to the enterprise for a wide variety of reasons, including:
- SLAs keep everyone on the same page. The biggest reason for an SLA is that it helps everyone avoid surprises. The customer understands the specific services it’s getting. The provider understands what the customer is expecting to receive. An SLA is a written tool that aligns the interests and expectations of both stakeholders.
- SLAs ensure you are getting what you pay for. Today’s enterprise can’t afford to shell out money for services that are not being received. SLAs are legally enforceable terms that give an enterprise some level of protection and recourse against shoddy service.
- SLAs help the enterprise deliver more consistent services. An SLA sets a baseline of performance provided by the vendor to the customer, and that in turn helps the contracting enterprise plan the service levels it can provide to its own customers. This allows for more consistent operations and fewer surprises over time.
- SLAs encourage a high level of customer service. SLAs inherently keep the focus of service delivery on quality. The mere presence of an SLA can encourage a service provider to resolve problems more quickly and otherwise provide a better level of service than customers without an SLA might receive.
- SLAs can provide an “out” from a contract. If a provider isn’t working out, an SLA can give the enterprise an easier way to cancel the contract than would otherwise be available.
What are the benefits of SLAs?
In addition to the above, SLAs provide a number of benefits to any organization. These include:
- SLAs force an organization to monitor operations. Many organizations don’t monitor critical operations quantitatively because they have no compelling reason to. Issues like downtime are considered an unavoidable problem that is remedied when it occurs, but which is never really tracked. SLAs give the organization a reason to do this calculus, particularly when a service provider can be held accountable for lapses in service.
- SLAs put everything in writing. SLAs work to take any uncertainty out of agreements with service providers. Because these agreements are written to be contractual in nature, they remove confusion and ensure aligned expectations among all parties.
- SLAs make it easier to comparison shop. SLAs can be used to help choose a vendor when shopping for a service provider in a commodity market. If one provider offers an SLA with 99.995% uptime and another offers 99.997% uptime – and all other terms and pricing are similar – the added value provided by the better SLA becomes more obvious. SLA terms can also be negotiated to improve the terms of a contract before it is signed.
- SLAs help the enterprise be more proactive. A well-written SLA helps an enterprise be more proactive about problems and solutions. If service quality is slipping, a quick escalation phone call or an incident report with the provider, as specified by the SLA contract, can usually remedy the situation rapidly. Without an SLA, the customer may be left floundering for days as it attempts to troubleshoot the issue, determine who can help, and implement a solution. Well-written SLAs define specific procedures to be taken in the event of service failures, which further aid the enterprise at being proactive in reaching a solution.
What are some SLA best practices?
The strategy for creating good SLAs is similar to that for creating a good contract. Good SLAs are loaded with specifics: what services are being provided, how the services are provided, and the quality standard for each service — an enterprise can start with a template SLA, but it’s important to add specific clauses for their own company. Critically: Each service must be measured by a separate, granular SLA which can be quantified with numerical, measurable metrics along with consequences should the SLA be violated. An SLA will specify the specific responsibilities of each party, what exceptions may apply to the service provider, and terms that specify how the SLA can be adjusted or amended over time.
For customers, it’s important for an SLA to include an indemnification clause, which protects them from any third-party litigation that results from a range of service level breaches.
Additional best practices apply to the setting of SLOs within an SLA. Specifically, SLOs should have the following features:
- Attainability: SLOs should not represent an ideal but should represent a minimum acceptable level of performance. “100% uptime” is essentially impossible and should not be the basis of an SLA or SLO.
- Meaningfulness: SLOs should have relevance to the enterprise and should represent “make or break” metrics that truly matter to the organization’s success and business needs.
- Measurability: SLOs should always be quantifiable numerically.
- Controllability: The service provider must have control over the SLO and should not be subject to external variables, within reason.
- Understandability: Good SLOs immediately make sense and can be understood across both IT and the broader business.
- Affordability: It should not be overly costly to meet the terms of an SLO or else it becomes impractical; this relates directly to attainability as well.
- Mutual Acceptance: SLOs must always be agreed upon by both sides of the service contract.
Creating a good SLA is similar to creating a good contract.
Service Level Agreements are a core part of any good service contract. When created properly, they are good for the parties on both sides of the agreement: The customer knows what to expect from the provider, and the provider has no confusion over the services it is supposed to be delivering. For the client, SLAs provide an essential way to ensure that it is getting the services it has paid for, helping to ensure business consistency, and optimize customer experience and profitability.
