Service Level Agreement (SLA): Metrics, Template and Practical Example
What Is a Service Level Agreement?
A service level agreement (SLA) is a documented commitment between a service provider and recipient that defines what service is covered, the required performance standard, how results will be measured, who is responsible and what happens when agreed levels are missed. It turns service expectations into commitments that can be measured, monitored and reviewed.
Use a service level agreement to turn service expectations into commitments that can be measured, monitored and reviewed.
A provider may say it responded within the agreed time while the customer argues that the issue remained unresolved for two days; both may be correct if the SLA never distinguished response time from resolution time.
A well-designed agreement defines the service scope, measurable targets, calculation rules, exclusions, ownership and what happens when agreed service levels are missed.
A service target is useful only when both sides can determine objectively whether it was met.
What Is a Service Level Agreement and What Should It Control?
A service level agreement translates service expectations into measurable commitments and clear governance rules. It should define what service is covered, the required performance level, how results will be measured, who is responsible, which exclusions apply, how performance will be reported and what happens when agreed levels are missed.
IBM's guidance on SLAs similarly describes an SLA as an agreement that defines the service, expected performance, measurement approach and consequences of failing to meet the commitment.
An SLA may sit within a wider contract, but it is not the whole contract. Commercial terms such as pricing, liability, confidentiality, intellectual property and termination may sit elsewhere. The SLA focuses more narrowly on:
What service must be delivered, to what measurable standard, and how compliance will be determined.
For the wider contractual context, see LOTC's Contract Management Lifecycle.
The same logic also works internally. An internal service level agreement might define, for example, the response and resolution commitments Finance provides to Operations, together with reporting, escalation and review rules.
How to Write an SLA That Can Actually Be Measured
A useful SLA process turns broad service expectations into commitments that both sides can measure in the same way. That requires more than writing targets: the service level requirements, calculation rules and ownership must all be explicit.
Define the Service Scope and Boundaries
Start by defining what the service includes, who receives it, when it is available and which request types are covered. Also state what is outside scope and which customer or user responsibilities affect delivery.
"Provide timely support" is too vague. A stronger commitment would be:
Provide invoice-query support for approved suppliers during defined business hours.
Do not measure a service before defining exactly what counts as the service.
Turn Expectations into Measurable Service Levels
Convert each expectation into a metric + target + time period + condition. For example:
Acknowledge Priority 1 requests within 30 minutes during service hours.
This is more useful than "respond quickly to urgent requests". Relevant SLA metrics may cover availability, timeliness, accuracy, quality, completion or resolution, depending on the service.
Define How Each SLA Metric Is Calculated
For every metric, specify:
If the measurement rule is ambiguous, the target is ambiguous.
Separate Response Time from Resolution Time
SLA response time measures how quickly the provider acknowledges or begins handling a request. Resolution time measures how long it takes to reach the agreed resolution state. For example:
These are different commitments and should be measured separately.
Define Exclusions, Dependencies and Clock-Pause Rules
State when the SLA clock may legitimately pause or when cases are excluded, such as scheduled maintenance, missing customer information, third-party dependencies or waiting for required approval.
Exclusions should clarify fair measurement, not become a mechanism for making poor performance disappear.
Assign Ownership, Escalation and Authority
Define who owns service performance, monitors compliance, investigates breaches, approves exceptions and receives escalation.
A RACI Matrix can help clarify these roles where several teams contribute to the service.
A target without an owner becomes reporting rather than accountability.
SLA Metrics: Choose Measures That Reflect the Service
Choose SLA metrics that show whether the service outcome customers or internal users actually depend on is being delivered. The right measure depends on the service, so targets should be selected deliberately rather than copied from a generic SLA template.
| Service Question | Possible SLA Metric | Example Target |
|---|---|---|
| How quickly do we acknowledge? | Response time | 95% within 2 business hours |
| How quickly do we resolve? | Resolution time | 90% within 1 business day |
| Is the service available? | Availability | 99.5% during defined service hours |
| Is the output accurate? | Accuracy / error rate | ≥98% correct first time |
| Are requests completed when promised? | On-time completion | ≥95% within agreed deadline |
| Are critical cases prioritised? | Priority compliance | P1 response within 30 minutes |
These targets are illustrative, not universal standards. A payroll service, facilities team, logistics provider and customer-support function should not inherit the same service level agreement metrics simply because a template contains them.
IBM's guidance on SLA metrics similarly shows that suitable measures vary according to the nature and purpose of the service.
Good SLA monitoring should therefore focus on a small set of measures that demonstrate whether the agreed service is being delivered, rather than producing a dashboard full of numbers with little operational meaning. For broader guidance on measures that sit beyond specific SLA commitments, see LOTC's guide to Operational KPIs.
Measure what defines successful service delivery, not merely what is easiest to count.
SLA vs KPI: What Is the Difference?
Understanding SLA vs KPI prevents service agreements from becoming overloaded with measures that do not belong in them. An SLA defines the commitment between a service provider and recipient; a KPI measures performance against a specific objective.
| SLA | KPI |
|---|---|
| Defines an agreed service commitment | Measures performance against an objective |
| Usually shared between provider and recipient | May be entirely internal |
| Includes targets and governance rules | May track broader operational performance |
| A breach may trigger escalation or remedy | Missing a target normally triggers management action |
| May contain several measures | A KPI is a measure, not the agreement itself |
SLA key performance indicators can therefore be used to demonstrate whether an agreed service level has been achieved, but the KPI does not replace the agreement surrounding it.
Not every KPI belongs in an SLA, and an SLA is not simply a list of KPIs.
For wider guidance on designing measures beyond specific service level agreement metrics, see LOTC's guide to Operational KPIs.
How to Calculate SLA Compliance
Calculate SLA compliance against the exact commitment defined in the agreement, not against a convenient average. A simple percentage formula is:
SLA compliance (%) = Cases meeting the agreed target ÷ Eligible cases × 100
For example, if 184 of 200 eligible requests meet the agreed response target:
184 ÷ 200 × 100 = 92% SLA compliance
The critical word is eligible. Before calculating performance, confirm which cases belong in the denominator. The SLA should already define whether exclusions apply, whether the clock pauses while waiting for customer information and whether different priority levels are measured separately.
When calculating SLA performance, averages can also be misleading. An average response time of 40 minutes may look acceptable while masking a smaller group of customers who waited eight hours. A clearer commitment might be:
95% of Priority 2 requests must be acknowledged within two business hours.
That wording creates a direct link between the commitment, the SLA metrics and subsequent SLA reporting.
The calculation must reproduce the wording of the commitment; otherwise reporting can show compliance with a target the SLA never actually defined.
Copyable Service Level Agreement Template
Use this service level agreement template to define not only the target, but also the rules that determine whether the service has actually met it.
| Field | What to Define |
|---|---|
| Parties / service relationship | Provider and service recipient |
| Service scope | Services included and excluded |
| Service hours | When the commitments apply |
| Request / priority categories | How work is classified |
| SLA metric | What performance is measured |
| Target | Required service level |
| Measurement method | Formula, calculation rule and data source |
| Clock start / stop | Events that start, pause and stop measurement |
| Exclusions | Cases legitimately removed from calculation |
| Provider responsibilities | Actions and resources the provider must supply |
| Customer / user responsibilities | Required information, approvals or actions |
| Reporting | Frequency, format and recipients |
| Breach definition | What constitutes non-compliance |
| Escalation | Who acts, when and at what level |
| Remedy / corrective action | Agreed response to failure |
| Review frequency | When performance and targets are reconsidered |
| Change approval | Who can authorise SLA amendments |
Copy this service level agreement template into Word, Excel, SharePoint or your organisation's contract or service-management system. A sample service level agreement should then adapt these fields to the service rather than preserving every section regardless of relevance.
A useful SLA template records not only the target, but also how both sides will know whether the target was met.
Service Level Agreement Example: Internal Support Service
Consider this service level agreement example for an internal Finance team supporting Operations with supplier-payment queries:
| Priority | Example | Response | Resolution / Update |
|---|---|---|---|
| Critical | Payment block stopping essential supply | 30 minutes | Resolution or substantive update within 2 hours |
| High | Supplier payment due today | 2 business hours | Same business day |
| Routine | Status or information query | 1 business day | Within 2 business days |
The internal service level agreement applies Monday to Friday during defined business hours. The SLA clock pauses only when Finance genuinely requires missing evidence or approval from the requester. Incomplete requests are excluded only where the agreed rule for incompleteness is met, rather than being removed informally from reporting.
Performance is reported monthly against each priority level, and recurring breaches are escalated to the service owner for investigation and corrective action.
The SLA does not promise that every issue will be solved instantly; it defines predictable commitments for different service conditions.
SLA Monitoring, Breaches and Review
Effective SLA monitoring should show more than whether performance is green or red. Useful SLA reporting should include the agreed target, actual result, service volume, valid exclusions, number and severity of breaches, performance trend and any unresolved corrective actions.
Monitor Target, Actual Performance and Exceptions
Review results in context. A reported 97% compliance rate means little if the underlying volume, exclusions or recurring failures are invisible. Trends also matter: a service may still meet its overall SLA while deteriorating month by month.
Treat a Breach as an Operational Event, Not Just a Percentage
When breaching an SLA, the service owner should:
Where the SLA relates to a supplier, repeated compliance failures can feed directly into supplier performance management and wider scorecard or contract-performance reviews.
Review the SLA When the Service Changes
Reassess the SLA when demand, systems, capacity, customer requirements or contractual arrangements change, or when repeated breaches show that the existing commitment no longer reflects the service.
An SLA should remain demanding enough to protect the service outcome, but realistic enough to be operationally meaningful.
Common SLA Design Mistakes
Poor SLA management often begins with an agreement that cannot be interpreted or measured consistently. Common mistakes include:
A service level that cannot be measured consistently cannot be managed consistently.
A final quality test:
If the provider and service recipient can read the same event data and reasonably disagree about whether the SLA was met, the agreement is not yet precise enough.
Strengthen Service and Contract Performance with LOTC
Strengthen SLA management by connecting measurable service commitments with clear contract governance, performance monitoring and structured responses to non-compliance.
LOTC's Contract Management Fundamentals course develops practical capability across the contract lifecycle, including roles and responsibilities, drafting clarity, deliverables, milestones, quality control, KPIs, performance monitoring, remedies and continuous improvement.
These capabilities help teams design service commitments that are realistic, measurable and easier to manage when performance falls below the agreed standard.
To discuss the course or arrange training for your organisation, contact LOTC on WhatsApp.