Service-level agreements (SLAs) are contracts that outline how a service is delivered to a customer, made popular decades ago in the telecommunications industry. With the rise of cloud-based providers—and the fact that over 90% of businesses use the cloud—the importance of SLAs has multiplied. Why? Because they’re crucial in setting standards of “good” service, managing expectations, explaining liabilities and responsibilities, and creating frameworks for handling timely customer support and repairs when failures occur.

When many mission-critical business operations depend on the reliability and quality of these services—whether it’s the internet, IT infrastructure, cloud hosting, telecommunications, or IT support, among other things—good SLAs are increasingly non-negotiable. Let’s take a look at what they should include, and why you should know what’s in your existing SLAs.

A Closer Look at SLAs

An SLA can be formal and legally binding, or informal and internal, and provides mutual protection for all parties by creating an agreed-upon benchmark for what constitutes “good” service—making it much easier to quantify “poor” service.

For businesses outsourcing IT operations or paying a premium for hosting, this is critical because it gives them leverage in the event that service lags. They’re able to back that up by the SLA and in some cases, even be reimbursed for downtime. When both parties agree to the terms of service, both are obligated to uphold that. Beyond service, SLAs can also include important security and compliance measures. In this respect, you can think of an SLA like an insurance policy for the service.

When failures do occur, however, SLAs can be incredibly valuable—to both parties. We’ve already established how SLAs benefit customers, but for providers the goals of an SLA are two-fold:

  1. Manage customer expectations. Without an SLA, you risk customers assuming that a service may be 100% available, 100% of the time. This sets realistic expectations and covers the provider in the event that outages or failures happen.
  2. Establish a clear understanding of how issues will be prioritized when handling service problems. They’re important for IT as well because they establish standards for customer service by creating a framework for how to handle and prioritize issues.

A Quick Example

Say you’re paying to receive mobile telephone and internet service from a provider. While it’s not always going to be perfect 100% of the time, you can mostly rest assured that you won’t experience an abnormally frequent loss of service, dropped calls, or periods of very slow service. The SLA, whether you know it or not, puts parameters on the bandwidth, consistency, reliability, and the time it takes to get back up and running.

Now, say you’re a business paying to host your e-commerce website in the cloud. If there’s a disruption in the hosting service that takes your site offline, that’s potential lost revenue. Know what that downtime is worth to your organization and be sure the SLA protects your best interests.

SLAs and APIs

API integrations are what make the cloud, infrastructures-as-a-service (IaaS), and sharing services and data all possible. They’re the driving force behind a new way of organizing and operating, with many businesses, applications, and services built entirely on APIs—and if those APIs stop working, so does your business. This makes SLAs a critical component every business should look for when integrating with an API.

Look for API SLAs that guarantee no degradation of service and offer protection against outages.

Understanding The Terms of Your SLA

If you’re paying for a service, whether it’s an IaaS, API, cloud provider, or outsourced IT support because you’re not quite large enough to warrant your own IT department, it’s very important to know the terms of your SLA. It can keep you informed of your rights, what you’re entitled to, what you may be owed for downtime, and what to expect in the event of a failure.

SLAs can also dictate things like your data rates, which might affect site or software performance if it gets throttled, or how long it takes for a service ticket to get a response.

Look for the following line items in your SLA:

  • Overview, dates of contract, numbers, cost, and contact information, etc. These are the basics, but note them in case you need to reference back to them.
  • Definition of the service you’re receiving, including the type of service, the functions the provider will perform, and specifics like data rates and throughput that might affect your operations.
  • The performance you can expect. The SLA should address the issue of disruptions, what happens when they occur, and how quickly the provider will respond to requests.
  • How processes and performance levels will be monitored. Accurate reporting of how the service is running—with data and stats—is the best way to gauge adherence to the SLA.
  • How data privacy or compliance concerns will be managed. For enterprises in certain regulated industries, providers (especially when it comes to the cloud and sensitive data) must comply with relevant mandates. Ensure the providers’ systems work in accordance with regulatory schemas. Look for data backup and recovery, continuity, and record keeping.
  • How to report any issues to the provider. Whether it’s contact information or a portal page, know how to report problems and look for transparency regarding prioritization of issues and how long it’s estimated or them to respond to reports.
  • How long it takes to resolve issues. TTR (time to resolution) explains exactly long after you submit an issue it and it’s acknowledged that will take for the provider to get it fully resolved.
  • A process for how to handle contract changes, in the event you want to renegotiate your contract for better service or add new functionality, look for change management measures and terms regarding your ability to renew or upgrade your SLA.
  • Reimbursement or otherwise, when the service provider doesn’t hold up its end of the SLA. If the provider is not able to meet the SLA requirements, the consequences may include customer’s right to terminate the contract or ask for a refund for losses incurred by the customer due to a failure of service.

This is just a loose outline for an SLA—some can get very granular and formal, while others can be quite informal. The key is knowing what to expect, what you can assume, and what processes are in place to make sure that service is consistent.