What is an SLA template?

An SLA template is a reusable structure for the written agreement between a service provider and a customer that states what response and resolution the customer can expect, under what conditions, and what happens when those commitments are missed. It is a document, not a dashboard. The internal work of choosing achievable numbers is a separate exercise, and the template's job is to make sure the numbers you chose are written down with the scope, severity definitions, exclusions, and measurement method that make them mean the same thing to both sides a year from now.

What should a service level agreement include?

Nine sections cover almost every support SLA. The scope of what is covered, service hours and coverage windows, severity definitions, first response targets, resolution commitments, exclusions and clock-pause rules, how performance is measured and reported, the escalation path, and the remedies plus a review cadence. The two that teams leave out are exclusions and measurement, and those are the two that decide every disagreement, because without them a missed target becomes an argument about whether it was ever missed at all.

What is a good response time SLA?

A good response time SLA is one your current team already hits roughly ninety percent of the time, tightened by ten to twenty percent, and scoped by severity rather than applied flat. As starting points, fifteen minutes on Critical with round-the-clock coverage, one business hour on High, one business day on Medium, and three business days on Low are defensible for a B2B SaaS support team. What makes a response target good is not how fast it sounds. It is whether you can hit it during your busiest week, because a target missed routinely trains customers to stop believing the rest of the document.

What is the difference between an SLA and an SLO?

An SLA is the external agreement with a customer and it carries consequences, usually service credits. An SLO is the internal objective your team works to, and it is normally set tighter than the SLA so there is headroom before a customer-facing commitment is at risk. A useful rule is to write the SLA at a number you would be comfortable defending in a renewal conversation, then set the SLO tight enough that the team notices trouble well before the SLA does.

Should an SLA include a resolution time?

Include a resolution commitment, but be careful about promising a flat clock on defects. First response is entirely within support's control, so a hard time works there. Resolution on a confirmed bug depends on engineering capacity and the nature of the fix, so a fixed number either gets padded until it is meaningless or gets missed regularly. The usual compromise is a firm workaround commitment plus a firm update interval on the higher severities, and a release-based rather than clock-based commitment on the lower ones.

Do you need service credits in an SLA?

Not always. Service credits belong in an SLA that is attached to a contract with an enterprise customer who negotiated for them. For a self-serve or mid-market product, a published support policy with clear targets and no credits is usually the better document, because credits create a claims process somebody has to administer. If you do include credits, define the claim window and the calculation precisely, since a vague credit clause generates more support work than the outage did.

SLA Template (Free Copy-Paste Service Level Agreement)

Most support SLAs contain one clause that nobody in the building can honor. It usually reads something like "resolution within five business days." It sounded reasonable when it was written, it made a renewal conversation easier, and it has been quietly missed on every escalated bug since, because the moment a ticket turns out to be a real defect it stops being support's ticket and the clock keeps running anyway.

A template does not fix that by itself. What it does is force the document to answer the questions that clause skipped: what counts as covered, what severity this is, when the clock pauses, who measures it, and what happens when it is missed. This guide walks the nine sections a support service level agreement needs, with worked severity and response tables, and a copy-paste version at the bottom.

In this article

Key takeaways

Nine sections make an SLA hold up: scope, service hours, severity definitions, response targets, resolution commitments, exclusions, measurement, escalation, and remedies with a review date.
Response time and resolution time are different kinds of promise. The first is entirely within support's control and can carry a hard clock. The second depends on engineering and usually should not.
The exclusions and measurement sections are the ones teams skip, and they are the ones that decide every disagreement about whether a target was missed.
An SLA is the external commitment and an SLO is the tighter internal objective. Writing them at the same number leaves no headroom to react.
The resolution clock keeps running after a ticket becomes a confirmed defect and leaves the help desk, which is the point where most SLA schemes quietly stop being measurable.

9sections in the template

2clocks, and only one you control

90%attainment before a target is worth publishing

What a Service Level Agreement Template Actually Covers

Nine sections. The order matters less here than it does in a release note, but scope and definitions have to come before any number, because every target below them is meaningless until the reader knows what it applies to.

1
1. Scope and parties
Who the agreement is between, which product or plan it covers, and what kind of request falls under it. Support requests, defects, and feature requests are three different things with three different realistic commitments, and an SLA that does not separate them will be read as covering all three. Name the effective date here too, because an SLA with no date attached is impossible to argue about later.
2
2. Service hours and coverage
The window during which the clocks run. Business hours in a named time zone, the holiday calendar you observe, and any severity that gets round-the-clock coverage regardless. This is the section customers in other time zones read most carefully, and vagueness here is expensive. "Business hours" without a time zone is not a commitment.
3
3. Severity definitions
Four levels, each defined by customer impact rather than by engineering effort. This is the section that makes every number below it tractable, because a single flat target across all requests either over-commits on cosmetic issues or under-commits on an outage. Write each level so a customer filing a ticket can pick the right one without calling you.
4
4. First response targets
How long until a human replies, per severity. This is the cleanest commitment in the document because it depends only on staffing and routing, both of which you control. It is also the one customers judge you on emotionally, since the first reply is the signal that they were heard.
5
5. Resolution commitments
What you commit to after the first reply. Resist the urge to make this a flat clock on every severity. A workaround commitment plus a firm update interval is a stronger promise than a resolution deadline you will miss, and it is the one you can actually keep on a confirmed defect.
6
6. Exclusions and clock pauses
What is not covered and when the timer stops. Third-party outages, customer-side configuration, requests filed outside the agreed channel, and time spent waiting on the customer for blocking information. Skipping this section does not make the agreement more generous. It makes it unenforceable in both directions.
7
7. Measurement and reporting
Which system of record produces the numbers, what percentile or attainment percentage is being claimed, and how often a report goes to the customer. An SLA where each side measures from a different tool is a disagreement waiting for a bad quarter.
8
8. Escalation path
Named roles and how to reach them when a target is at risk, with a second contact for when the first does not answer. This section costs ten minutes to write and it is the reason a frustrated customer emails the right person instead of your CEO.
9
9. Remedies and review
What the customer gets when you miss, if anything, and the date this document gets looked at again. Even an SLA with no service credits should carry a review cadence, because targets set against last year's volume stop being honest as the team and the product change.

Response Time SLA vs Resolution Time SLA

These two get written as if they are the same kind of promise, and they are not. Understanding the difference is most of what separates an SLA that survives contact with a real quarter from one that gets quietly renegotiated.

A response time SLA is a commitment about your own team. The clock starts when the ticket arrives and stops when a human replies. Everything that determines whether you hit it, which is coverage, routing, staffing, and whether the queue surfaces the ticket in time, sits inside your organization. A hard number is appropriate here, and it should be tight.

A resolution commitment is different the moment the ticket turns out to be a defect. Now the outcome depends on reproducing the bug, on engineering capacity that quarter, on how risky the fix is, and on a release process that support does not run. Writing "resolution within five business days" across all severities means one of two things is true: either the number is padded so far that it commits you to nothing, or you are going to miss it regularly on exactly the tickets customers care most about.

First response is a promise about your team. Resolution on a confirmed defect is a promise about another team's backlog, and the document should say so rather than pretending otherwise.

The practical resolution: commit hard where you have control and commit to communication where you do not. On Critical and High, promise a workaround or mitigation within a stated window plus an update at a fixed interval until it is closed. On Medium and Low, commit to a release-based outcome rather than a clock. Customers accept this readily when it is stated plainly up front. What they do not accept is a five-day promise that silently becomes six weeks.

A Service Level Agreement Example

Here is the shape filled in, so the abstract sections have something concrete underneath them. Treat every number as a starting point rather than a recommendation, since the whole point of the target-setting exercise is that your numbers come from your own ticket history.

Severity definitions first, written from the customer's side of the screen.

Severity	Definition	Typical example
S1 Critical	The service is unavailable or unusable for all users, and no workaround exists	Nobody can sign in, or data is not saving
S2 High	A core function is broken or severely degraded for many users, and the workaround is costly	Exports fail for every account on a plan tier
S3 Medium	A feature behaves incorrectly, with a reasonable workaround available	A filter returns the wrong count but the data is correct elsewhere
S4 Low	Cosmetic, documentation, or a minor annoyance with no functional impact	A label is truncated, or a help article is out of date

Then the commitments, split the way the previous section argued for.

Severity	First response	Update interval	Resolution commitment	Coverage
S1 Critical	15 minutes	Every 2 hours until mitigated	Workaround or mitigation same day	24/7
S2 High	1 business hour	Every business day	Fix targeted within 10 business days	Business hours
S3 Medium	1 business day	Every 5 business days	Scheduled into a future release	Business hours
S4 Low	3 business days	On status change	No dated commitment	Business hours

Two things about that second table are deliberate. The update interval column is present on every row, because a ticket acknowledged in fifteen minutes and then silent for three weeks feels worse to a customer than one acknowledged in an hour and updated reliably. And the resolution column gets progressively less specific as severity drops, which is honest rather than evasive. The severity scale itself maps onto the routing rules in the escalation matrix guide, and if you are still deciding how to define these levels, bug severity vs priority covers why customer impact and engineering ordering are two different scales.

The Exclusions Section, and When the Clock Pauses

This is the section most templates on the internet leave as a single line, and it is the one that decides every future disagreement about whether a target was met.

Requests filed outside the agreed channel
If the SLA covers tickets submitted through your help desk, then a message sent to an account manager on Slack at 11pm is not on the clock. Say so plainly. This is not bureaucracy, it is the only way response targets can be measured at all, and customers understand it immediately when it is written down in advance rather than invoked afterward.
Time waiting on the customer
When you have asked a specific, blocking question and cannot proceed without the answer, the clock pauses. Define this tightly. A pause rule that triggers on any outbound message is the most commonly abused clause in support, and it produces attainment numbers your own team does not believe.
Third-party and infrastructure outages
Failures in a dependency you do not operate, and scheduled maintenance announced in advance. Name the announcement window for maintenance, because "announced in advance" and "announced forty minutes in advance" are different commitments.
Customer-side configuration and unsupported use
Misconfiguration, unsupported integrations, custom code against your API, and environments outside your stated compatibility list. Be specific about what is supported rather than listing what is not, since the list of unsupported things is infinite.

Where the Resolution Clock Goes After Escalation

There is one gap this document cannot close by itself, and it is worth naming because it is where most SLA schemes stop being measurable.

The path is familiar. A ticket comes in, support responds inside the target, investigates, and confirms it is a real defect. It gets escalated to engineering, where it becomes an issue with a different title, a different owner, and a different tool. From that moment the resolution clock on the original ticket is being driven by a system that support cannot see into. The rep chases it in standup or on Slack, the customer asks for an update, and someone reconstructs an answer by hand.

This is why resolution SLAs on escalated tickets get relaxed year after year until they commit to nothing. The number was never the problem. The visibility was.

A resolution target you can actually report on

The ticket and the engineering issue are linked records
Status changes flow back to the ticket automatically
The update interval can be met without chasing anyone
Attainment is measured from one system of record
The closing reply goes out the day the fix ships

A resolution target that decays into a guess

The ticket references an issue key and nothing else
Support learns the status by asking in Slack
Every update is a manual reconstruction
Two tools disagree about when it was resolved
The customer finds out weeks after the fix shipped

Nothing in the left column requires a bigger team. It requires the handoff from support to engineering to leave a durable link behind it, so the ticket and the issue stay attached to each other for the whole life of the defect. That is the same gap that makes a root cause analysis hard to write afterward and the reason closing the customer feedback loop is the step that quietly gets skipped.

For teams where support runs on HubSpot Service Hub and engineering runs on Linear, this is what IssueLinker is for. A ticket becomes a linked Linear issue in one click with the customer's own wording carried across, status changes sync back to the ticket automatically, and comments move both ways, so the resolution clock in your SLA is measured against something real instead of reconstructed at reporting time. The Linear HubSpot integration guide covers how the two-way sync works.

Resolution targets you can measure

If support runs on HubSpot Service Hub and engineering runs on Linear, IssueLinker links the customer ticket to the engineering issue and syncs status both ways, so the resolution clock in your SLA reflects real progress and the closing reply goes out the day the fix lands.

Before You Send an SLA to a Customer

Run this before the document leaves your building. Most of these take a minute and all of them are cheaper to fix now than in a renewal conversation.

Pre-send checklist

Every target came from your own ticket history, not from a benchmark article, and your team already hits it about ninety percent of the time.
Service hours name a time zone and a holiday calendar, and any 24/7 coverage is scoped to specific severities.
A customer filing a ticket could pick the right severity from your definitions without asking you.
The resolution commitments do not put a flat clock on defects you cannot schedule.
The clock-pause rule is narrow enough that your own team would call it fair.
One named system of record produces the numbers, and both sides know which one it is.
The escalation path lists a second contact for when the first is unavailable.
Your internal SLO is set tighter than the published SLA, so a bad week is visible before it is a breach.
The document has an effective date and a review date, and someone owns the review.

Mistakes That Make an SLA Unenforceable

Four patterns account for most support SLAs that exist on paper and mean nothing in practice.

Publishing the SLA and the SLO as the same number
If the internal objective and the external commitment are identical, the first sign of trouble is a breach. Set the SLO tighter so the team gets a warning band. This costs nothing and it is the single highest-value line in the whole exercise.
Severity assigned by the person filing rather than defined by impact
Every customer's issue is Critical to that customer. Definitions written in terms of measurable impact, plus a documented right to reclassify with an explanation, is the workable version. Without it the top severity band fills up and the targets stop meaning anything. Consistent classification at intake is a triage problem before it is an SLA problem.
No measurement section
Attainment claimed from a report neither side agreed on is not a commitment, it is a marketing sentence. Name the tool, the calculation, and the reporting cadence. Which numbers to track and how to read them together is covered in customer service metrics.
Written once and never reviewed
Targets calibrated against last year's volume, team size, and product surface stop being honest as all three change. An annual review with a named owner keeps the document from becoming something everyone has stopped reading, which is the terminal state of most SLAs.

Copy-Paste SLA Template

Here is the template in plain text. Paste it into a doc, a contract exhibit, or your public support policy page. Delete the remedies section entirely if you are not offering service credits, since an empty credits clause invites a question you do not want to answer twice.

SERVICE LEVEL AGREEMENT

Provider:           [ your company ]
Customer:           [ customer or "all customers on [plan]" ]
Effective:          [ date ]
Review date:        [ date, usually 12 months out ]

1. SCOPE
Covered:            [ product / plan / environments ]
Covered requests:   [ e.g. defects and service requests ]
Not covered here:   [ e.g. feature requests, professional services ]
Channel of record:  [ where a request must be filed to be on the clock ]

2. SERVICE HOURS
Standard hours:     [ e.g. 09:00-18:00 ET, Mon-Fri ]
Holidays observed:  [ calendar or link ]
24/7 coverage:      [ which severities, if any ]

3. SEVERITY DEFINITIONS
S1 Critical:  [ unavailable or unusable, no workaround ]
S2 High:      [ core function broken, costly workaround ]
S3 Medium:    [ incorrect behavior, reasonable workaround ]
S4 Low:       [ cosmetic or documentation, no functional impact ]
Reclassification: [ provider may reclassify with a written reason ]

4. FIRST RESPONSE TARGETS
  Severity   Target            Coverage
  S1         [ 15 minutes ]    [ 24/7 ]
  S2         [ 1 hour ]        [ business hours ]
  S3         [ 1 day ]         [ business hours ]
  S4         [ 3 days ]        [ business hours ]

5. RESOLUTION COMMITMENTS
  Severity   Update interval   Commitment
  S1         [ 2 hours ]       [ workaround same day ]
  S2         [ daily ]         [ fix targeted in N days ]
  S3         [ 5 days ]        [ scheduled into a release ]
  S4         [ on change ]     [ no dated commitment ]

6. EXCLUSIONS AND CLOCK PAUSES
Excluded:           [ third-party outages, announced maintenance,
                      customer-side configuration, unsupported use ]
Clock pauses when:  [ a specific blocking question is outstanding ]
Clock resumes when: [ the customer responds ]

7. MEASUREMENT AND REPORTING
System of record:   [ tool ]
Metric:             [ e.g. % of tickets meeting target, per severity ]
Reported:           [ cadence, to whom ]

8. ESCALATION PATH
  Level        Role                 Contact         When
  1            [ support lead ]     [ ... ]         [ target at risk ]
  2            [ head of support ]  [ ... ]         [ target missed ]
  3            [ exec sponsor ]     [ ... ]         [ repeated misses ]

9. REMEDIES AND REVIEW
Service credits:    [ amount, or "none" ]
Claim window:       [ e.g. within 30 days of the miss ]
Review cadence:     [ annual, owner named ]

---
INTERNAL, NOT PUBLISHED
Internal SLO (tighter than the published targets):
  Severity   Published SLA     Internal SLO
  S1         [ ... ]           [ ... ]
  S2         [ ... ]           [ ... ]
Escalated defects currently on the resolution clock:
  Ticket     Severity   Escalated on   Tracker issue   Customer told
  ------------------------------------------------------------------
  1.
  2.

The block at the bottom is the part that makes the rest of it real. An SLA is only as measurable as your worst-tracked ticket, and the worst-tracked ticket is always the one that left the help desk for the engineering tracker and stopped reporting back. If that table is hard to fill in today, the resolution numbers in the published sections above are an estimate rather than a commitment, and that is worth knowing before a customer finds out first.

SLA Template: A Support Service Level Agreement, Section by Section