Service level agreement template: 10 Sections and a Worked Support Example

A service level agreement template sets out what service a provider will deliver, how both parties will measure it, and what happens when a target is missed. A useful SLA turns broad promises such as “fast support” into clear rules that the customer and service team can follow.

Below, you will find a fill-in template, a service level agreement example, and practical checks for timers, reporting, and escalation. The example focuses on business software support. Adapt the structure to your service and have the contractual terms reviewed for your jurisdiction and wider agreement.

What belongs in an SLA?

An SLA needs a defined service, measurable targets, a measurement method, duties, and a process for exceptions. It should also identify the people who review results and approve changes. A percentage without a definition is not a usable promise.

For example, a four-hour response target leaves several questions open. Does the clock run overnight? Does an automated receipt count as a response? Can the provider pause the timer while waiting for access? Answer those questions before setting the number.

Keep the SLA aligned with the main contract. Pricing, liability, confidentiality, and termination may sit in other documents. Reference the right version rather than adding conflicting terms to a short support schedule.

A fill-in service level agreement template

Use the following sections as a drafting framework. Replace every bracketed field and remove options that do not apply. A blank left in a signed document can create more uncertainty than an omitted section.

1. Parties, service, and document control

Provider: [legal name and contact]. Customer: [legal name and contact]. Service: [specific service or system]. Agreement reference: [main contract and version]. SLA version: [version number]. Effective date: [date]. Review date: [date].

Day-to-day contacts: [named roles and contact channels]. Approval contacts: [roles approved to approve changes]. This SLA applies to [named environments, locations, users, or service components].

Keep the service boundary precise. For software support, identify whether the agreement covers production only, test environments, integrations, and customer-built extensions. Otherwise, a request may arrive with no shared view of whether it belongs in scope.

2. Scope and exclusions

Included services: [support, monitoring, maintenance, or other work]. Excluded services: [new features, training, third-party repairs, or other exclusions]. The provider will route excluded requests through [quotation or change process].

Customer dependencies: [access, information, approvals, supported devices, and other inputs]. Third-party dependencies: [named services and the limits of the provider’s responsibility].

However, avoid making every dependency a blanket exclusion. Explain how the provider identifies the cause, informs the customer, and continues useful work while another party acts.

3. Service hours and contact channels

Standard support hours: [days and times]. Time zone: [named zone]. Holiday calendar: [calendar or rule]. Accepted request channels: [portal, phone, email]. Emergency channel: [channel and eligibility].

Requests received outside support hours enter the queue at [defined time], except for [explicit emergency coverage]. A request counts as received when [the support platform records it or another defined event occurs].

Next, decide how daylight saving time affects the window. A named local time zone is often clearer than an offset that may change during the year.

4. Priority definitions

Priority 1: [critical business impact and scope]. Priority 2: [major impact with limited workaround]. Priority 3: [limited impact or effective workaround]. Priority 4: [routine request or question].

Initial priority owner: [role]. Priority review process: [who may change priority, what evidence they use, and how they notify the other party]. Disputed priority escalation: [role and channel].

Use impact and urgency together. A request from a senior person does not automatically have greater service impact than a fault affecting the whole team.

5. Response and restoration targets

For each priority, record [first response target], [update interval], [restoration target where applicable], and [resolution target where applicable]. State whether each target uses business hours or elapsed time.

A qualifying first response means [human acknowledgment, initial assessment, named owner, and next action]. Restoration means [service returns through a fix or accepted workaround]. Resolution means [the agreed final outcome and closure criteria].

These are separate events. A team can respond quickly while taking much longer to restore service. Reporting only the first response can hide the customer’s main problem.

6. Timer and measurement rules

Timer start: [event]. Pause conditions: [specific allowed conditions]. Resume event: [event]. Stop event: [event]. Reopened request treatment: [continue the original clock or start a defined new cycle]. Measurement system: [system and report].

For availability targets, define [service boundary], [observation method], [measurement interval], [eligible minutes], and [exclusions]. Record how planned maintenance and partial failures affect the calculation.

The Atlassian documentation on creating SLAs illustrates how start, pause, and stop conditions shape support timers. The contract and the configured workflow need to use the same rules.

7. Escalation and communication

Day-to-day escalation: [role and trigger]. Management escalation: [role and trigger]. Customer update channel: [channel]. Update frequency: [interval by priority]. Major incident notice: [who sends it and what it contains].

Each update should include [current impact, actions taken, known limits, next action, and next update time]. If the provider has no confirmed restoration estimate, it should say so and give the next review time.

In addition, keep an out-of-hours contact route current. An escalation list fails if it points to a former employee or an unmonitored inbox.

8. Reporting and review

Reporting period: [period]. Report owner: [role]. Delivery date: [date or interval]. Measures: [target attainment, breaches, exclusions, backlog, and agreed supporting metrics]. Review meeting: [frequency and participants].

Each breach review will record [cause, customer effect, corrective action, owner, and due date]. The parties will distinguish isolated incidents from repeat causes that need a service change.

Also show the denominator behind percentages. “95% met” means little without the number of eligible requests and any excluded cases.

9. Remedies and claims process

Agreed remedy: [service credit, corrective plan, or other remedy]. Eligibility: [conditions]. Claim deadline: [period]. Evidence: [required records]. Calculation and cap: [agreed method]. Approval and delivery: [process].

Legal review should align this section with the main agreement, including how remedies interact with other rights. Do not copy a provider’s credit schedule without checking whether it fits your service and risk.

For an actual contract example, Atlassian’s published SLA ties defined commitments to eligibility and a credit request process. Its terms apply to its services, rather than serving as universal terms for yours.

10. Change, renewal, and approval

Change request owner: [role]. Review process: [steps]. Approval required from: [roles]. Notice period: [period]. Version storage: [location]. Renewal or end date: [date and process]. Signatures: [approved names, roles, dates].

State when a revised target takes effect and how staff will learn about it. Then update the support tool, reports, and training. A signed change that never reaches the system will produce inclear results.

A worked support SLA example

Consider a fictional inventory application used by one business. Standard support runs Monday to Friday, 09:00 to 17:00 in the customer’s named time zone, excluding an agreed holiday calendar. Critical production incidents have a separate 24-hour channel.

The parties define a critical incident as the production service being unavailable to all approved users with no workable alternative. A routine report question falls into a lower priority. These definitions let the service team classify requests based on impact.

These targets are examples, not recommended service levels. Before adopting them, check staffing, cost, dependencies, and customer needs. A promise that the team cannot support will create repeated breaches.

Now suppose a major request arrives at 16:30 on Friday. If no holiday applies and the timer uses the stated business calendar, 30 minutes run on Friday and the remaining 90 minutes run on Monday. The response deadline is Monday at 10:30.

Finally, define what happens if the customer sends missing details at the weekend. The system should apply the agreed calendar and pause rules clearly. Staff should not decide timer treatment differently for each ticket.

How to calculate availability without ambiguity

A simple availability calculation is: eligible service minutes minus qualifying unavailable minutes, divided by eligible service minutes, multiplied by 100. The hard part is agreeing on the words “eligible” and “unavailable.”

For example, a fictional 30-day period contains 43,200 minutes. If all minutes qualify and 60 count as unavailable, availability is about 99.861%. A different measurement window or exclusion rule would change the result.

Therefore, define the monitored service and failure condition before setting a percentage. A healthy server does not always mean customers can complete the key business action. Select checks that reflect the service boundary you promise.

Common drafting mistakes

First, avoid using response, restoration, and resolution as if they mean the same thing. Give each one its own event and target. This makes both reporting and customer updates clearer.

Second, do not allow vague pause reasons such as “pending.” Identify who must act and what resumes the clock. Keep the history so both parties can review a disputed pause.

Third, avoid targets with no day-to-day owner. Assign someone to monitor approaching deadlines and trigger escalation. Our article on help desk software covers the workflow needed to support those actions.

Finally, keep a controlled copy of the signed SLA and its revisions. Contract management automation can help with reviews and version control when many customer agreements use different terms.

Test the SLA before customers rely on it

Run a short tabletop exercise with the customer contact and service team. Pick one routine request, one critical outage, and one case waiting for customer access. Walk through receipt, classification, response, pause, escalation, and closure.

For example, a customer may open a critical ticket through an ordinary email channel at night. The agreement should make the emergency route clear and explain when each channel receives attention. If the team cannot follow the wording clearly, revise it before signing.

Next, test an escalation when the main contact is absent. Confirm that a backup can act and has the authority needed to make a decision. A name in a table is not a workable escalation route unless someone monitors it.

Also inspect a sample monthly report. It should show each measure, the calculation, any exclusions, and the cases that missed the target. Keep the incident records available so both parties can check a disputed result.

Finally, compare the SLA with the service team’s capacity. Include leave, holidays, and the work needed during several simultaneous incidents. If the promised coverage needs extra staffing or monitoring, price and arrange that support before the agreement takes effect.

Record the outcome of the exercise as part of the launch checklist. This gives the team a shared example to use during training and later reviews.

Make the agreement measurable in daily work

Use this service level agreement template to define scope, clocks, duties, and remedies before choosing target numbers. Then walk through real timing examples with both teams. A useful SLA is one that customers, managers, and support staff can interpret the same way.