How to write your first service level agreement (with tips from Slack, Amazon, and Google)

When you pay a lot of money for something, you have certain expectations about how it works. If you walked into a car dealership and drove out with a new ride, you’d assume the vehicle would drive problem-free (at least for a while). Most likely, you would even get a warranty from the dealership that outlined which repairs and maintenance they’d cover in the first few years of ownership.

In the tech industry, that warranty agreement between a seller of something—software, instead of a car—and a customer is called a service level agreement (SLA). An SLA is a contract between a service provider and a service user that defines what service is provided, as well as expectations around issues and downtime.

As an early-stage founder, writing an SLA is one of those tasks that’s uber-important but also uber-outside your forte. It needs to be done, and as the person with the most product expertise and customer visibility, it falls to you. And yet, this is very much not one of those cases where you can throw spaghetti at the wall, see if it sticks, and iterate. This is a contract. You can’t move fast and break things when it comes to contracts.

That’s why we took a deep dive into what makes a good SLA—so you don’t have to. We’ve pored over the best examples our industry has to offer, from companies like Slack, Google, and Amazon, and emerged with a model any company can use to write their SLA.

‍
Steal this service level agreement template. A good SLA will use simple language to define a set of components around service performance. In a way, an SLA can act as a DIY problem-solver and instruction manual for your customers. The idea is to tell your customers four things:

1. What they can expect around functionality from your service
2. How the service will be monitored
3. A plan of action in case something goes wrong
4. Steps for remediation

Define the level of service functionality your customer can expect

Define the type of service up top. This section will help to get both you and your customers on the same page around the type of service you’re providing. It will also provide an estimated performance level, which is usually given in the form of a percentage (like 99.5% uptime).

Lay out metrics for monitoring your service

Next, tell the customer how you will monitor performance and where they can view the monitoring information. If your customers use a lot of third-party apps in addition to yours, it can be difficult for them to pinpoint where the exact issue is if one of the apps goes down. In 2020 when AWS had an outage—tons of websites were down. Having a status page for your app and telling your customers where to view it will help them quickly see when there is a problem.

Offer an escalation for resolving issues

Now, tell your customers what to do in case of any problems. Is your app experiencing an outage? Give them an email address, a help-desk phone number, a shared Slack channel, or a contact form where they can get more information. Once the problem is resolved, you’ll be able to tell them before the status bar on your monitoring site changes. Remember, the key to happy customers is great communication.

Provide remediation if an issue arises

Finally, as much as your engineers are rock stars or wizards or whatever recruiting is calling them these days, they’re still just a bunch of humans. Sometimes, technical problems happen, and they can take a little bit of time to resolve. In your SLA, be sure to give a response-time window, where the customer can expect issues to be looked into and resolved. This might sound impossible, but do your best. You can also spell out clear, actionable ways customers can escalate if a problem persists outside of the agreed-upon window, such as applying for refunds for lost time.

Now that we have a clear understanding of the parts of a great SLA, let’s look at some examples from Slack, Google, and Amazon.

Slack’s SLA has both a summary and details

The Slack SLA includes a two-sentence summary of the document at the top that makes understanding the terms of the agreement really simple. If end users wanted to, they could probably get by with reading only those first two sentences. Learn from Slack: Make mutual understanding as easy as possible.

Below the summary, Slack’s SLA provides concrete details that the customer can read for more information:

Including a summary at the top with the most important details, like percentage of expected uptime and a short explanation of service credits (with a link to the details in the doc), means your customers can find info quickly and will have to dig through details only if they really need to.

In the SLA breakdown, Slack clearly labels each section to help end users find what they’re looking for quickly (and, hey, it seems to follow our suggested outline pretty well!):

• Downtime: Definition of what “downtime” means for Slack
• Uptime commitment: Numerical percentage of uptime guarantee
• Scheduled downtime: Clear boundaries on scheduled downtime, including advanced warning and total outage time in a year
• Service credits: Promises to the customer if Slack fails to meet their SLA terms
• Updates (to SLA): Legally, Slack is saying they can update their SLA whenever they want

Most sections are just a few sentences and/or have bullet points to convey details without too much fluff. After all, your customers are tech people, not lawyers. Basically, we love Slack’s SLA because it keeps it simple, with links to more documentation for deeper dives, which helps keep this page strictly for important info.

Google’s Cloud Functions SLA defines terms

Google’s Cloud Functions SLA has a section dedicated to defining all the technical and legal terms they use in their agreement to make sure customers understand all conditions.

Often, SLAs need to include very technical terms or legal jargon. To make the job of the reader as easy as possible, why not include some definitions right at the top so readers can refer back when they hit a word or phrase they don’t know? That’s exactly what Google does:

Each defined term is bolded, which is extra helpful if a reader sees something confusing and wants to go back and look for the definition.

Defining the terms within the same doc is critical. If your customer is looking up “downtime period” in a random internet search, they may find a completely different definition than the one you have. Better to ensure you’re all clearly talking about the same definitions.

Google uses a table to define “Financial Credit” because that’s the clearest way to show the information, and that’s more than okay! It may seem counterintuitive to include a spreadsheet or table in your legal docs, but it’s actually pretty normal.

We love Google’s Cloud Functions SLA because it really excels at spelling out exactly what Google intends to convey to the reader and gives them great resources for understanding everything in the SLA doc.

Amazon’s S3 SLA outlines service credits with tables

Amazon’s S3 SLA uses tables to help the reader understand service credits to their account, which awards a service-credit percentage based on the monthly uptime percentage. Remember how we said tables were normal for SLA docs? We weren’t kidding!

Writing this information out in long-form sentences would be very confusing for the reader.

“If your monthly uptime percentage is less than 99.9% but greater than or equal to 99.0%, your service credit percentage will be 10%. If your monthly uptime percentage is less than 99.0% but greater than or equal to 95.0%, your service . . .”

Yeah—that’s no good. Seeing this information laid out in a table makes it much easier to understand.

Terms for the service credit are listed below the table and include rules (for instance, you can’t transfer credit to another account).

Write a service level agreement that makes you and your customers happy

An SLA is more than just a legal document.

An SLA is a promise about quality of service to your customers. Writing an SLA that’s clear, simple, and easy to use is key for keeping your customers happy. Companies like Slack, Google, and Amazon have written SLAs that work well for their customers by keeping it simple, defining confusing terms, and displaying information in an easy-to-digest manner.

An SLA is just one step toward becoming Enterprise Ready

You’ve built the app. You’ve gotten your first customers. You have traction and—dare we say it?—product-market fit. But that’s not all you need. Before you can move upmarket, before your business can mature, your app needs to become Enterprise Ready.

Take a look at Callingly, a sales enablement platform that optimizes how businesses connect new leads to available sales team agents. Callingly lost an RFP from a large company partially because it lacked single sign-on (SSO). But for a small, sub-50-person company, SSO seemed out of reach. They estimated it would take 120 precious developer hours to implement.

With WorkOS, Callingly implemented SSO in only a few hours, and after announcing SSO, they had their first enterprise customer using it in only 48 hours.

Is your app Enterprise Ready?