SLA (Service Level Agreement): Meaning, Examples & Template

A service level agreement (SLA) is a documented commitment between a service provider and a customer that defines what service will be delivered, how it will be measured, and what happens if a target is missed. Typical SLA terms cover response time, resolution time, uptime, responsibilities, and remedies such as service credits.

That's the short answer. The rest of this guide covers what most people actually search for next: how an SLA differs from an SLO, SLI, OLA and KPI, the types of SLA, what goes inside one, how to write one step by step, a template you can copy, and worked examples for IT, support, sales and vendor uptime.

What is an SLA?

An SLA is a promise with numbers attached. A provider commits to a level of service (how fast, how available, how good), and the customer knows exactly what to expect and what recourse they have if the provider falls short.

Google's engineering handbook defines an SLA as an explicit or implicit contract with users that "includes consequences of meeting (or missing)" the service level objectives it contains, and offers a simple test: ask what happens if the targets aren't met. If there's no explicit consequence, you're almost certainly looking at an objective, not an agreement (Google SRE Book, Service Level Objectives).

SLAs usually come with penalties or accountability measures. An e-commerce company might promise to refund the shipping cost if an order isn't delivered within 2 hours of being placed, and publish that promise on its website. That's an SLA: a clear target, a clear measure, a clear consequence.

Key Facts: SLA in 30 seconds

• An SLA names the service, the metric, the target, the measurement method and the remedy.
• Without a consequence or a measurement rule, it's an aspiration, not an agreement.
• SLAs sit between a provider and a customer. When both sides are teams inside the same company, it's called an internal SLA or an OLA.
• Cloud providers publish theirs: AWS promises at least 99.99% monthly uptime at the region level for EC2, with credits of 10%, 30% or 100% depending on how far uptime falls (AWS Compute SLA).

What is an internal SLA?

SLAs began with internet service providers, but they now run across IT and well beyond it. Companies large and small use internal SLAs to make sure they can keep the promises they've made to customers.

The reason is that departments depend on each other. One team becomes the "customer" of another: marketing hands leads to sales, sales hands signed deals to onboarding, support hands bugs to engineering. The performance of one team directly affects the next, and the best way to manage that handoff is to put a measurable agreement around it.

There's a real distinction between process management and project management. Projects tend to be unpredictable, one-off bundles of tasks. Processes are set up in advance by the business, which makes them predictable and easier to control. So the most effective way to track internal SLAs is through process flow monitoring, and internal SLAs usually live in the job function or the process documentation. If you're new to the underlying discipline, start with what process management is.

Example of an internal SLA

Take a contract processing workflow with six steps. If the company promises to finish all paperwork for a customer within 48 hours, it can break that promise into six smaller SLAs, one for each department involved. The customer sees one 48-hour commitment; internally, every team knows its own slice of the clock.

Benefits of internal SLAs

Whether an SLA sits between a business and its customers or between two teams, its fundamental purpose is to measure performance against pre-defined standards and agreed accountability. Benefits of internal SLAs include:

• Improves workflow efficiency and compliance with customer-facing SLAs.
• Clarifies responsibilities and expectations, which improves relationships between teams.
• Surfaces delayed tasks and bottlenecks quickly enough to act on them.
• Gives you an accurate basis for performance reviews, rewards or corrective action.
• Builds a transparent work environment with better task prioritization and goal alignment.

SLA vs SLO vs SLI vs OLA vs KPI

These five terms get used interchangeably, and that's where most SLA arguments start. Each one answers a different question.

Think of it as a chain. The SLI measures reality, the SLO sets the target for that measurement, the SLA turns the target into a contract with consequences, and the OLA makes sure the teams behind the scenes can actually deliver it. The KPI is the odd one out: it tracks how well the business is doing overall and doesn't need a counterparty.

Google's SRE handbook describes an SLI as a carefully defined quantitative measure of some aspect of the service, such as request latency or error rate, and an SLO as a target value or range for that measure (Google SRE Book, Service Level Objectives). The same chapter recommends keeping a safety margin: a tighter internal SLO than the one advertised to users gives you room to respond to problems before they become visible externally.

SLA vs KPI in practice

The main difference between an SLA and a KPI is purpose and scope:

• An SLA is a formal agreement between two parties, focused on meeting specific service standards.
• A KPI is an internal metric used to gauge the performance of services, processes or employees against business goals.

For example, an SLA might state that a software provider must maintain 99.9% uptime or respond to critical support issues within 1 hour. A company might track a KPI such as customer satisfaction rating or average resolution time for support tickets. Many SLA metrics start life as KPIs. If you already track them, our guide to process KPIs shows how to choose ones worth turning into commitments.

Types of SLA

Most SLAs fall into one of three structures, plus the internal variant.

Customer-level SLA

A customer-based SLA covers all the services provided to one customer. It sets out the service details, availability, responsibilities, escalation process and cancellation terms for that customer's needs. An IT company might have one customer-level SLA with a corporation that uses several IT support services, so everything sits under a single agreement.

Service-level SLA

A service-level SLA covers one specific service delivered to many customers. Every customer on that service gets the same terms. If an internet provider sells a standard broadband package to several clients, the service-level SLA defines the speed and uptime guarantees for that package.

Multi-level SLA

A multi-level SLA is layered to cover different customers or service tiers in one agreement. It suits businesses with several plans. A cloud storage provider might use one framework where basic, premium and enterprise customers get different storage capacity, support levels and guaranteed uptime.

Internal SLA

An internal SLA applies the same idea between departments, such as marketing to sales or support to engineering. There's no invoice or credit at stake, so the consequence is usually escalation, visibility in a review, or a process change. For worked versions of the external types, including the uptime math and credit ladders, see our SLA examples and templates.

Key components of an SLA

A good SLA is short on prose and long on definitions. Every one of these elements should be in the document:

1. Parties and term: who is providing, who is receiving, the start date, and how long it runs.
2. Service description: what's delivered, described in the customer's words rather than internal jargon.
3. Service hours: the coverage window, time zone, holidays and on-call arrangements.
4. Metrics: each measure defined once, with its unit (minutes, percent, tickets).
5. Targets: the number, and the share of cases it applies to (for example, 95% of tickets).
6. Measurement method: the system of record, when the clock starts and stops, and the reporting window.
7. Responsibilities: what the provider does, and what the customer must do (give access, answer questions) for the clock to keep running.
8. Exclusions: named, bounded and testable. Planned maintenance and customer-caused delays are the usual ones.
9. Reporting: who publishes the numbers, how often, and where.
10. Remedies: credits, penalties or corrective plans, how to claim them, and the deadline for claiming.
11. Escalation: named roles and time triggers for raising a problem.
12. Review and change control: how often targets are revisited and who can change them.

The three most often skipped are the measurement method, reporting and remedies. Those are the ones that decide whether the agreement has any teeth.

How to write an SLA in 7 steps

The steps below work for a customer-facing SLA and for an internal one. Where the two differ, the step says so.

Step 1: Identify the requirements and expectations of everyone involved

The key is to find the few factors that accurately reflect performance and can be measured. Run a short survey or hold internal meetings so the people doing the work can contribute. Pull current performance reports as a reference, so the targets reflect what's realistic rather than what sounds good.

Talk directly to customers, partners and stakeholders too. What are you doing well? Is the sales team giving a satisfying experience? What could be faster or clearer?

Step 2: Choose a small set of metrics

Avoid overwhelming the business with too many SLAs, but have enough to meet your goals. Three to five metrics per service is a sensible range. If you already track KPIs such as first response time or resolution time, build on those rather than inventing new ones.

Step 3: Set realistic targets and agree on them

An SLA must be agreed by every party involved. A common solution is to meet in the middle. For example, the customer service team may want to resolve requests in one day while the technical team needs five days for its part. A three-day SLA might be a reasonable compromise, with the handoff steps defined inside it.

Set targets from your actual baseline. A target you can't hit on day one trains everyone to ignore it.

Step 4: Define how the clock works

Many disputes come from ambiguity, not from poor service. State when the clock starts (ticket created, lead assigned, order placed), when it stops (first human reply, issue resolved), and what pauses it (waiting on the customer, outside service hours). Exclude non-working days and hours. If an SLA is 24 hours and a task is assigned at 9 am on Friday, the deadline is 9 am on Monday, since the weekend doesn't count.

Step 5: Establish rewards and consequences

Consequences are what make an SLA different from a goal. For external SLAs, that's usually a service credit. For internal ones, penalties for missing the SLA can scale gradually, from a reminder to a warning to a written notice and, in the end, a smaller bonus. Rewards can include one-on-one praise, public recognition and performance bonuses. Neither should be harsh, just enough to motivate.

Keep in mind that unforeseen events, such as an outage at a third-party provider, can affect compliance. Write those into the exclusions instead of arguing about them later.

Step 6: Set up monitoring and reporting

To make sure SLAs are followed and managers can track the numbers, you need a monitoring system. For some businesses, a spreadsheet and one dedicated person are enough. But manual tracking is labor-intensive, involves processing a lot of raw data, and one person can't oversee every process, especially across departments.

At that point, ask whether manual tracking costs more than it returns. If it does, move to a tool that tracks SLAs automatically, because that gives you:

• Faster, more accurate SLA measurement with less labor.
• Instant alerts to SLA violations or workflow bottlenecks.
• Long-term data storage and automatically compiled reports.
• Integration with collaboration and management tools.

Workflow platforms are one option here. Rework, for example, includes SLA rules for lead distribution and SLA tracking across sales, marketing and customer success handoffs, so the clock stays visible to the people responsible. Any tool that records the timestamps you defined in Step 4 will do the job.

Step 7: Review and improve regularly

Market conditions and customer expectations keep shifting, so your SLAs must shift with them. When workload or staffing changes, adjust the targets. If SLAs aren't reviewed, they quickly become outdated and fall short of both what employees can deliver and what customers expect.

Most companies revise their SLAs every one to two years. Fast-growing companies review more often, sometimes quarterly.

Tips: For a newly written SLA, pilot it on a small scale first. This lets you test whether it works before rolling it out across the organization.

SLA template you can copy

Paste this into a document, replace the bracketed values, and delete the rows you don't need. The numbers shown are placeholders for illustration, not recommendations.

Service Level Agreement: [Service name]

And a priority matrix to fill in alongside it:

If you need a bilateral template for a specific team handoff, there's a ready one for marketing and sales, and the SLA examples and templates page includes templates for IT, support, vendors and cloud uptime.

SLA examples by function

The figures below are illustrative examples to show how an SLA is structured. They aren't industry benchmarks. Set your own numbers from your baseline and capacity.

Example 1: IT service desk

Also stated: service hours are 8 am to 6 pm local time on working days, with an on-call number for P1 outside those hours. The clock pauses while the ticket is waiting on the requester. Target: 95% of tickets within these times each month. Remedy: a written root-cause review for any P1 breach.

Example 2: Customer support

Also stated: auto-replies don't count as a first reply, and weekends are excluded from business hours. If the monthly satisfaction target is missed twice in a row, the support lead presents a fix plan at the next review.

Example 3: Sales and marketing lead handoff (internal SLA)

This one is two-sided, which is what makes it work. Marketing owes sales a certain quality of lead, and sales owes marketing a certain speed of follow-up.

Speed is usually the sticking point. If you're deciding what number to commit to, see how lead response time affects conversion and how a lead assignment SLA keeps leads from sitting unowned.

Example 4: Vendor or SaaS uptime

Uptime is stated as a percentage per month. A quick way to feel the difference is to turn the percentage into minutes of allowed downtime in a 30-day month (43,200 minutes):

Remedies are typically a sliding scale of credits. As a real reference point, AWS's EC2 SLA pays a 10% credit if monthly uptime at the region level falls below 99.99% but stays at or above 99.0%, 30% if it falls below 99.0% but stays at or above 95.0%, and 100% below 95.0% (AWS Compute SLA). Read the claim process closely in any vendor SLA: credits usually have to be requested, and the deadline is short.

SLA metrics to track

Pick the few that match what the customer cares about. The most common ones:

• First response time: how long until a human acknowledges the request.
• Resolution time: how long until the problem is actually solved.
• SLA compliance rate: the share of requests or periods that met the target.
• Availability or uptime: the share of time the service worked.
• Backlog age: how long the oldest open items have been waiting.
• Escalation rate: how often requests needed to be escalated.
• Customer satisfaction: a survey score tied to the interaction.
• Breach count and cause: how many misses, and why.

Compliance rate is the single most useful number for managers. It tells you at a glance whether the commitment is being kept, and a falling trend gives you a warning before customers start complaining.

Internal SLA best practices

While most people accept SLAs for external relationships (customers, partners, media), there's often hesitation about internal ones. The reason is simple: internal SLAs are closely tied to individual employee responsibilities. These tips help you roll them out more smoothly:

• Keep SLA names simple so employees can remember them. Instead of "SLA requires confirming a customer order within 15 minutes of the order being placed successfully," call it "Order confirmation SLA: 15 minutes" in your tracking documents.
• Exclude non-working days and hours from SLA timing.
• Break SLAs into steps instead of assigning them to a whole department, so you can see accountability for each task. In a contract handling process, even if "Processing terms" and "Getting signatures" are consecutive steps in the Legal department, give them separate SLAs.
• Make SLAs visible to everyone involved.
• Write the process down. An SLA is easier to meet when the steps behind it are documented. A standard operating procedure turns the promise into a repeatable routine.

Common SLA mistakes: dos and don'ts

Dos

• Do define every term. "Response" and "resolution" mean different things to different people. Write down which one you mean.
• Do measure what the customer experiences. A ticket marked resolved isn't resolved if the customer comes back with the same problem.
• Do set the internal target tighter than the promise. An SLO a little stricter than the SLA gives you room to react before a breach.
• Do name an owner on each side. Someone has to be accountable for reporting and reviews.
• Do review on a schedule. Put the review dates on the calendar when you sign.

Don'ts

• Don't track too many metrics. Past five or six, nobody remembers what matters.
• Don't promise numbers you can't measure. If there's no system of record for the clock, you'll argue about the data instead of fixing the service.
• Don't copy another company's targets. Their staffing, tools and customers aren't yours. Start from your baseline.
• Don't leave exclusions vague. "Unforeseen circumstances" invites a dispute. List what is excluded and how it's verified.
• Don't write an SLA with no consequence. If nothing happens when a target is missed, it's an objective, and people will treat it that way.
• Don't set it and forget it. An SLA nobody reviews drifts away from reality within a year. Pair it with regular process monitoring.

Conclusion

SLAs are more than formal contracts. They make service quality something two parties can measure, discuss and improve. SLAs with customers are widely understood, but internal SLAs between departments are where many companies find their biggest efficiency gains.

If your business promises customers 24/7 support, internal agreements between your support and IT teams are what make that promise real. By measuring performance consistently and reviewing it on a schedule, SLAs let the business run like a well-oiled machine, inside and out.