Service Level Agreement
Last reviewed October 2026
Definition
Service Level Agreement — A service level agreement (SLA) is the part of a contract that sets measurable service targets for a provider, how they are measured and reported, and what happens if they are missed. In remote staffing and outsourcing the targets typically cover coverage hours, uptime, response time and resolution time by severity, and quality. Consequences usually include a remediation plan, service credits, escalation and a right to end the contract after sustained underperformance.
What a service level agreement is
A service level agreement (SLA) is the part of a contract that says what level of service the provider will deliver, how it will be measured, how it will be reported, and what happens if the provider falls short. In remote staffing and outsourcing it turns a vague promise such as "we will respond quickly" into a measurable commitment that both sides can check.
The engineering literature separates three ideas that people often blur. In the Site Reliability Engineering book, a service level indicator (SLI) is a carefully defined quantitative measure of some aspect of the service, such as request latency or error rate. A service level objective (SLO) is a target value or range for that indicator. A service level agreement is an explicit or implicit contract with users that includes consequences of meeting or missing the objectives it contains. A simple test: ask what happens if the target is missed. If there is no explicit consequence, you are almost certainly looking at an SLO, not an SLA.
Where SLAs fit in staffing models
How much an SLA matters depends on who is accountable for the outcome. The same logic is set out on our managed services page, where the provider runs a function and is measured by SLAs.
- Staff augmentation: you direct the work, so the agreement with the provider is light. It covers availability, responsiveness to your requests, and how quickly the provider replaces someone who leaves. Quality is handled through your own performance management. See staff augmentation.
- Dedicated team: the provider handles recruitment and employment while you direct the work, so the SLAs cover the provider's responsibilities: time to fill a role, replacement, equipment and connectivity. See the dedicated team model.
- Managed services and business process outsourcing: the provider owns the outcome, so the SLA is the main accountability mechanism and covers full performance metrics, service credits, reporting and escalation. See managed services and business process outsourcing.
Mixing the models causes confusion. If you direct the work, do not expect outcome SLAs. If the provider owns the outcome, avoid managing its people day to day. The managed services vs staff augmentation comparison explains the difference.
The main categories of service level
The categories below match those used on the managed services page, so the two can be used together.
Availability and uptime
Availability covers the coverage hours the team will be reachable and, for systems in scope, the percentage of time the service is working. Uptime is usually written as a percentage, and the SRE book notes that the industry commonly expresses high availability in "nines": for example, 99% is "two nines" and 99.999% is "five nines". The allowed downtime follows from simple arithmetic. In a 30-day month of 720 hours, which is a calculation made by this site rather than a published benchmark:
- 99% uptime allows 7.2 hours of downtime.
- 99.9% uptime allows 43.2 minutes of downtime.
- 99.99% uptime allows about 4.3 minutes of downtime.
Higher targets leave less room for downtime, so ask how the provider plans to meet them and what it will charge. Define what counts as "down": a full outage, degraded performance, or a failure in one region only. State whether planned maintenance is excluded and how it is announced.
Responsiveness: response time and resolution time
These two are different and should be written separately. Response time is how long the provider takes to acknowledge a request and start work. Resolution time is how long it takes to fix the problem or complete the task. Set both by severity, so that a critical issue gets a faster response and a tighter resolution target than a minor one. Describe the clock: when it starts (when the ticket is logged or when the issue is detected), when it stops, and whether it runs only during covered hours.
Quality
Quality measures show whether the work is good, not just prompt: accuracy or error rate, first-contact resolution, customer satisfaction, defects in delivered work. Pick measures the provider can influence and that you can measure independently. Define what counts as an error before the contract starts.
Throughput and capacity
Throughput measures the volume completed in a period, such as tickets resolved or transactions processed. Capacity terms cover how quickly the provider can add people if volume rises, and what happens to the targets while it does.
Recovery
For systems and data, agree how quickly service must be restored after a serious failure (the recovery time objective) and how much recent data you can afford to lose (the recovery point objective). These matter when the provider hosts or processes your systems.
Consequences: service credits, escalation and exit
A target without a consequence is an objective. Typical consequences, in rising order of seriousness, are:
- A remediation plan for a first miss, with a deadline and a named owner.
- Service credits for repeated or serious misses: a reduction in the fee, with the calculation, the fee it applies to and any cap written into the contract. Capping credits keeps the provider financially viable.
- Escalation to more senior people on both sides when a problem continues.
- A right to end the contract without penalty after sustained underperformance, with the definition of "sustained" written out.
Credits alone may not be enough for work that matters to your business. The right to leave, and an exit plan, can give more leverage than a small fee reduction. Consider incentives for exceeding targets, but make sure they reward outcomes rather than activity.
How to write an SLA that works
- Start from what the business needs, not from numbers copied from another contract.
- Write each target so it is specific, measurable and time-bound. "Respond to tickets quickly" cannot be tested. A target that names the share of tickets, the time limit, the covered hours, the measurement source and the reporting period can.
- Set targets the provider can realistically meet, and leave room for a ramp-up period with staged targets and agreed dates when the team is new.
- Name who measures, with which tool, and who resolves disputes about the data.
- Limit the number of targets to those that drive outcomes. Too many dilutes attention.
- Include a review clause so targets can change as the work changes.
- Include force majeure and upstream dependency terms, so both sides know what is outside the provider's control.
As an illustration only, a well-formed target might read: "95 percent of priority-1 tickets acknowledged within 15 minutes during covered hours, measured from the ticketing system and reported monthly, with a service credit for each month below target." The numbers are for the buyer and provider to agree; they are not a standard.
SLA, SLO, OLA and related terms
- SLA: the agreement with the customer, including consequences.
- SLO: an internal target, often set tighter than the SLA so there is a margin before a breach.
- SLI: the measure the target is based on.
- OLA (operational level agreement): an agreement between internal teams that supports a service commitment.
- Underpinning contract: a contract with a third-party supplier that the provider relies on to meet the SLA.
SLAs, data protection and standards
If the provider handles personal data, the SLA sits alongside a data-processing contract. GDPR Article 28 says a controller must use only processors providing sufficient guarantees to implement appropriate technical and organisational measures. For cloud services, ISO/IEC 19086-1 sets out common building blocks, concepts, terms and definitions for cloud SLAs. Our guide to data security when outsourcing covers the security terms to request.
Common mistakes
- Targets that cannot be measured, or have no agreed measurement source.
- Unrealistic targets that push the provider to raise prices or game the numbers.
- Measuring activity, such as handle time, instead of outcomes.
- Credits with no right to exit, or an exit right with no definition of sustained failure.
- No escalation path or review clause.
- Ignoring the ramp-up period for a new team.
- Asking for outcome SLAs while directing the work yourself.
Some providers now tie fees to results rather than hours, which we cover in outcome-based pricing in BPO.
Sources
- Site Reliability Engineering: Service Level Objectives
- ISO/IEC 19086-1:2016, Cloud computing, Service level agreement (SLA) framework
- GDPR Article 28, Processor
References checked on 13 October 2026. Contract terms and remedies depend on the governing law, so have an adviser review any agreement. This page is general information, not legal or tax advice.