- Customer-based SLAs
- Service-based SLAs
- Multilevel SLAs
- Customer-based example
- Service-based example
- Multilevel example
LogRocket’s Galileo AI watches every session, surfacing impactful user struggle and key behavior patterns.
My first experience in a B2B model got off to a horrible start. Day after day, furious customers would flood my mailbox with complaints, and I felt like a failure.
Instead of doing product management, I ended up doing a kind of customer relationship management. I had to deal with complaints like the following:
- “I’m unhappy with the response time. Yesterday I opened a critical request, and nobody responded”
- “I’m highly dissatisfied with your resolution time. Despite answering my request in two days, I had no clue when my problems were finally solved”
- “Over the last two months, I have experienced downtime four times, which is unacceptable.”
As an inexperienced B2B product manager, it took me a couple of months to understand the real problem: unclear expectations from customers and no service-level agreement whatsoever.
In this guide, we’ll define what a service-level agreement (SLA) is, explore common types of service-level agreements, and review what’s included in a typical SLA.
Note: This article is intended to provide general information about service-level agreements and is not a substitute for professional legal advice. The templates and examples provided in this article should be used as a starting point and not as definitive legal documents. Always consult with your company’s legal department before drafting, finalizing, or signing any service-level agreement.
What is a service-level agreement (SLA)?
A service-level agreement (SLA) is a contract between a service provider and a client that clearly outlines the expectations and responsibilities of both parties. This agreement sets the standards for the level of service the provider will deliver, detailing specific metrics such as response time, resolution time, and product-specific conditions.
The goal of a service-level agreement is to maintain transparency between the provider and the client, ensuring consistent service quality and accountability.
In any relationship, all parties need to know what to expect (and what not to expect) from each other. Whenever that exchange is unclear, frustrations and conflicts arise.
As in the story I shared earlier, the lack of an established agreement regarding response time, resolution time, and uptime can lead to a discrepancy between how you perceive the quality of your product and how your customers perceive it. Whenever you leave something up to interpretation, you will be surprised, and not in a fun way.
With a SLA, all parties agree on a time range to address the available services. When the range isn’t respected, a fine may be applied to the side breaking the agreement. The penalty isn’t mandatory, but it’s a common practice in B2B.
Who is responsible for writing service-level agreements?
The task of writing a service-level agreement typically falls on the service provider because it best understands the capabilities and limitations of the service. That said, creating SLAs is a collaborative effort that involves input and negotiation from both the service provider and the customer.
It’s crucial for both parties to be involved in the process to ensure that the agreement is realistic, achievable, and mutually beneficial. Lawyers and/or the company’s legal department may also be involved to ensure that the agreement is legally sound and protects the interests of both parties.
What is included in a service-level agreement?
A basic, generic service-level agreement typically includes information and articulates expectations around the following:
- Services — A detailed description of the service provided
- Responsibilities — Who is responsible for each part of the service
- Performance measurement — Detailed KPIs to track and their respective targets
- Problem management — Processes and contingency plans for when a service issue arises
- Customer duties — What is expected of the customer in the relationship
- Legal compliance — All legal aspects of the service, such as data protection and confidentiality
- Termination — How to terminate the agreement
When writing a SLA, it’s particularly important to articulate the expected response when service issues arise. This includes clearly communicating the service provider’s obligations around the following:
Reaction time
Over 200k developers and product managers use LogRocket to create better digital experiences
Learn more →
How long does it take for you to look at something? It’s one thing to look at an issue and another to actually answer your customers’ cries for help.
People are anxious; don’t leave them high and dry without any information.
Response time
How long do you respond to requests? A bug impacting all your users has a higher priority than a time on your footer.
Set expectations and, preferably, categorize the expected response time based on the importance of a given issue.
Resolution time
You may not work on all requests from your stakeholders because some of them are unimportant to your product. Your response time consideration should include the time and effort it takes to explain those decisions.
More great articles from LogRocket:
- How to implement issue management to improve your product
- 8 ways to reduce cycle time and build a better product
- What is a PERT chart and how to make one
- Discover how to use behavioral analytics to create a great product experience
- Explore six tried and true product management frameworks you should know
- Advisory boards aren’t just for executives. Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Uptime
What is your application availability? For example, an uptime of 99.5 percent means you can have a downtime of three hours and 45 minutes per month, while 99.9 percent means you can be down only 45 minutes per month.
This is fundamental because you need to understand the business and your application. Commonly, you need some windows to run upgrades in your application.
Types of service-level agreements (with templates)
Service-level agreements come in various formats. The three most common SLA types for external customers are:
Customer-based SLAs
A customer-based service-level agreement is tailored to meet the individual requirements of a single customer. This type of SLA covers all the services that the client uses.
Customer-based SLAs are unique and flexible, enabling you to customize the agreement based on the specific customer’s needs. However, it can be resource-intensive for the same reason.
Customer-based SLA template
A typical customer-based SLA might include the stipulations outlined in the template below. To use the SLA templates in this article, copy/paste the following into a document or spreadsheet and replace the text in brackets with information specific to your agreement:
- Customer name: [Customer’s Name]
- Services: [Detailed list of services]
- Availability: [Specific uptime percentage]
- Response time: [Specific response time range]
- Resolution time: [Specific resolution time range]
- Penalty: [Specific penalties for SLA violations]
Service-based SLAs
Service-based service-level agreements apply to all customers using the services provided. It is a standardized agreement, which means it’s easier to administer because there’s only one agreement for any number of customers.
However, service-based SLAs lack the flexibility to cater to individual customer needs.
Service-based SLA template
Here’s an example of what a service-based SLA might include:
- Service: [Specific Service]
- Availability: [Specific uptime percentage]
- Response time: [Specific response time range]
- Resolution time: [Specific resolution time range]
- Penalty: [Specific penalties for SLA violations]
Multilevel SLAs
Multilevel service-level agreements are a combination of customer-based and service-based SLAs. They provide a balance between standardization and customization, allowing you to provide different levels of service for different customer groups.
For example, a basic service level may apply to all customers, with premium service levels available for an additional fee.
Multilevel SLA template
Here’s a basic template for a multilevel SLA:
- Customer group: [Specific group of customers]
- Services: [Detailed list of services]
- Availability: [Specific uptime percentage]
- Response time: [Specific response time range]
- Resolution time: [Specific resolution time range]
- Penalty: [Specific penalties for SLA violations]
Customer-based vs. service-based vs. multilevel SLAs
| Type of SLA | Flexibility | Ease of administration | Suitability |
|---|---|---|---|
| Customer-based | High | Low | For customers with unique requirements |
| Service-based | Low | High | For standard services used by many customers |
| Multilevel | Medium | Medium | For a mix of standard and unique service requirements |
Note: This article is intended to provide general information about service-level agreements and is not a substitute for professional legal advice. The templates and examples provided in this article should be used as a starting point and not as definitive legal documents. Always consult with your company’s legal department before drafting, finalizing, or signing any service-level agreement.
Service-level agreement example
To provide a clear understanding of how service-level agreements work in practice, let’s look at examples of each type of SLA:
- Customer-based SLA example
- Service-based SLA example
- Multilevel SLA example
Customer-based example
Let’s consider the example of a software-as-a-service (SaaS) company that provides billing applications.
A customer-based SLA between the company and client could guarantee 99.9 percent uptime, a maximum response time of two hours for high priority issues, and a resolution time of 24 hours for critical issues. The SLA would be specific to this client.
Such a service-level agreement might look like this:
- Service — Project management tool
- Performance — 99.9 percent uptime
- Reliability — Resolution of critical issues within 24 hours
- Responsiveness — Response time of 2 hours for high priority issues
Service-based example
In a service-based scenario, a SaaS customer relationship management provider might offer its services to multiple clients. The SLA might guarantee an uptime of 99.99 percent, data refresh frequency of once every hour, and a response time of 4 hours for support queries. This SLA would apply to all clients using that company’s services.
A service-based SLA between a CRM provider and its customers might look like this:
- Service — CRM service
- Performance — Data refresh frequency of once every hour
- Reliability — Uptime of 99.99 percent
- Responsiveness — Response time of 4 hours for support queries
Multilevel example
A company providing project management services to a large organization with many departments might opt for a multilevel SLA that assigns service tiers to various departments based on their unique needs.
For instance, developers might be guaranteed a response time of one hour, while the marketing might be guaranteed a response time of three hours.
This single SLA would cover the diverse service levels required by the different departments within the organization.
- Service — Communication applications
- Performance — Varies based on department needs
- Reliability — Consistent service across all departments
- Responsiveness — Response time of 1 hour for Engineering department; 3 hours for Marketing department
Measuring KPIs
It’s fundamental to measure the health of your SLA. If you overpromise, you’ll receive loads of complaints. But how do you determine your actual capacity? Learning by doing is my answer.
First, determine which specific metrics related to the performance, reliability, and responsiveness of your product or service are most important to monitor. Ensure you measure all expectations mentioned previously for each category.
For example, whereas general response time isn’t helpful, the response time for critical and noncritical issues is actionable. This could mean tracking the average time it takes to respond to and resolve technical issues reported by customers or the time it takes to deliver software updates or patches.
In addition to response times, you should also monitor system uptime. Uptime is a crucial KPI for any SaaS business because low uptime can signal reliability issues that might breach the SLA and negatively impact the customer experience.
Other important KPIs to track might include the error rate of your software or the frequency and severity of bugs and crashes. These metrics provide insights into the quality of your product and can inform efforts to improve its reliability and performance.
My key learning is to set alerts when things go wrong. This helps you react faster instead of learning you have a problem once it becomes too big. For product managers, this might mean setting up automated notifications that alert you when a certain error rate threshold is exceeded or when system uptime falls below a specified level.
You don’t need to make it complicated. A simple dashboard with all key metrics will get the job done. Whenever something is out of your SLA, that should be clear so that it doesn’t go unnoticed.
Conclusion
I used to think setting detailed SLAs was a time waster and over-engineering. Now, I recognize the truth lies somewhere in between.
Not having a SLA is a no-go. At the same time, an overly complex SLA will confuse all parties involved and ultimately be unhelpful. The most important aspect is to craft an SLA that every party can agree to.
- Set realistic timelines
- Continuously reflect on how satisfied your customers are with your services
- Understand how sustainable it is for your team to keep the SLAs
- Monitor KPIs
- Inspect, review, and adapt
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Share this:
- Click to share on Twitter (Opens in new window)
- Click to share on Reddit (Opens in new window)
- Click to share on LinkedIn (Opens in new window)
- Click to share on Facebook (Opens in new window)
