A service level agreement (SLA) is a written promise between a service provider and a customer about the level of service the customer will get: what's covered, how fast you respond and fix problems, how it's measured, and what happens if you miss. For a support team, the SLA usually comes down to response times by priority, such as a first reply within one business hour for urgent issues.
What does SLA mean in business?
SLA stands for service level agreement. It turns "we'll take care of you" into numbers both sides can check. You'll find SLAs in:
- Software (SaaS) contracts: uptime, such as 99.9% a month, and support response times.
- Managed IT services: how fast a managed service provider (MSP) answers a ticket, comes on site or restores a server.
- Agencies and outsourced work: turnaround times for requests and revisions.
- Internal teams: how fast IT or operations answers the rest of the company.
An SLA can be its own document or a section of a larger contract, often attached to a master services agreement.
Types of SLAs
- Customer-based SLA: one agreement for one customer, covering everything you do for them.
- Service-based SLA: the same terms for every customer of one service, such as "standard support".
- Multi-level SLA: layers, such as company-wide terms, then terms per service, then extras for a specific customer. Common when you sell support tiers like Standard and Premium.
- Internal SLA: between two teams in the same company.
What to include in an SLA
- Parties and dates. Who the agreement is between, when it starts and how long it lasts.
- Services covered. What's included, and just as important, what isn't.
- Hours of coverage. Business hours (and in which time zone), extended hours, or 24/7.
- Priority levels. Define each one with examples, so nobody argues later about what "urgent" means.
- Targets. First response time and resolution time for each priority, plus uptime if you run a service.
- How it's measured. When the clock starts and stops, whether it pauses while you wait for the customer, and which tool is the source of truth.
- Customer responsibilities. How to report an issue, what to include, who can open tickets.
- Escalation. Who to contact when a target is at risk.
- Reporting. What you report and how often.
- Remedies. Service credits or other consequences when you miss.
- Exclusions. Planned maintenance, issues caused by the customer or third parties, events outside your control.
- Review. When the SLA gets reviewed and updated.
SLA examples
Support response times by priority
| Priority | Example | First response | Resolution target |
|---|---|---|---|
| Urgent | The service is down for everyone | 1 business hour | 8 business hours |
| High | A key feature is broken, with no workaround | 4 business hours | 2 business days |
| Normal | A problem with a workaround | 1 business day | 5 business days |
| Low | A question or a feature request | 2 business days | Best effort |
These are examples, not a standard. Set targets your team can meet at least 95% of the time with the people you actually have.
Uptime
Uptime SLAs are usually written as a percentage of a month:
| Uptime | Downtime allowed in a 30-day month | Per year |
|---|---|---|
| 99% | 7 hours 12 minutes | 3.65 days |
| 99.5% | 3 hours 36 minutes | 1.83 days |
| 99.9% | 43 minutes | 8.76 hours |
| 99.99% | 4 minutes | 53 minutes |
Managed IT services
An MSP might promise: urgent tickets answered within 30 minutes, 24/7; a technician on site within 4 hours in the metro area; normal tickets answered within 4 business hours.
SLA vs SLO vs SLI
- SLA (service level agreement): the promise you make to the customer, with consequences if you miss. Example: "We answer urgent tickets within 1 business hour."
- SLO (service level objective): your internal target, usually stricter than the SLA, so you have room before you break a promise. Example: "We aim to answer urgent tickets within 30 minutes."
- SLI (service level indicator): what you actually measure. Example: "97% of urgent tickets this month got a first reply within 1 business hour."
The SLI tells you whether you're meeting the SLO, and the SLO keeps you safely inside the SLA.
SLA template
Copy this, replace the brackets and cut what doesn't apply. It's a starting point, not legal advice: have a lawyer review the remedies and exclusions before you sign.
SERVICE LEVEL AGREEMENT
Between: [Your company] ("Provider") and [Customer] ("Customer")
Effective date: [Date] Term: [12 months, renews with the main agreement]
1. SERVICES COVERED
[List the services. Example: support for the [Product] web app and its integrations.]
Not covered: [Example: custom development, third-party tools, training beyond onboarding.]
2. SUPPORT HOURS
[Monday to Friday, 9 am to 5 pm Eastern, excluding public holidays.]
Urgent issues: [24/7 by phone at ...]
3. HOW TO REQUEST SUPPORT
[Support email, website chat or phone.] Include what happened, when, who is affected, and screenshots.
4. PRIORITIES AND TARGETS
Urgent: [definition] First response: [1 business hour] Resolution: [8 business hours]
High: [definition] First response: [4 business hours] Resolution: [2 business days]
Normal: [definition] First response: [1 business day] Resolution: [5 business days]
Low: [definition] First response: [2 business days] Resolution: [best effort]
5. MEASUREMENT
The clock starts when the request is received and pauses while the Provider waits for information from the Customer.
Source of truth: [help desk or ticketing tool]. Report: [monthly], sent by [the 5th business day].
6. UPTIME (IF APPLICABLE)
[99.9%] per calendar month, excluding planned maintenance announced [48 hours] in advance.
7. ESCALATION
If a target is at risk: [support lead, name, email]. Then: [head of customer success or owner].
8. SERVICE CREDITS
[If monthly uptime falls below 99.9%, the Customer receives a credit of 10% of that month's fee.]
9. EXCLUSIONS
[Issues caused by the Customer's systems or users, third-party outages, events outside the Provider's control, beta features.]
10. REVIEW
This SLA is reviewed [every 12 months] or when the services change.
Provider: ____________________ Name, title, date
Customer: ____________________ Name, title, date
How to track SLAs without a big help desk
An SLA is only as good as your ability to see when you're about to miss it. You need four things: every request in one place, a priority on each, a clock per priority, and a view of what's running late.
Large help desks do this with routing rules and SLA policies that take time to set up. A small team usually needs less. In Alori, the all-in-one app, tickets have a number, an assignee, a status and a priority. Each team sets a response time per priority, and a ticket past its time turns red. Chats, support emails and texts land in one shared inbox, and you file a ticket from a conversation in one click. The customer gets an email when their ticket moves, and Front desk shows how long customers wait for a person on chat and support email. See ticket SLA tracking and the help desk.
A support bot answers chats and support emails from your help center at any hour, and hands the rest to your team, which takes pressure off your response times. See AI customer support.
Common SLA mistakes
- Promising 24/7 without the people for it. Every missed target costs more trust than a slower, honest promise.
- Too many priority levels. Three or four are enough.
- No definition for each priority. Customers will call everything urgent.
- Measuring resolution without pausing the clock while you wait for the customer.
- No exclusions. You end up on the hook for someone else's outage.
- Never reviewing it. Targets that made sense with 20 customers may not with 200.
Frequently asked questions
What is an SLA in simple terms?
An SLA is a promise about service, written down with numbers: how fast you'll answer, how fast you'll fix things, how much of the time the service will be up, and what happens if you miss. It sets expectations for both the provider and the customer.
What's the difference between an SLA and a contract?
A contract covers the whole business relationship: price, payment, liability, ownership. An SLA covers only the level of service. It's often a section of the contract or an attachment to it.
What is an SLA breach?
A breach is a missed target, such as an urgent ticket answered after the promised hour. What happens next depends on the SLA: often a service credit, an escalation or a review.
What's the difference between an SLA and an SOW?
An SLA defines the ongoing level of service. A statement of work (SOW) defines one project: deliverables, timeline and price. A managed service often has both. See our statement of work template.
What is a good response time SLA?
One you can keep. Start from your current response times and staffing, set targets you hit at least 95% of the time, and tighten them as your team grows.
Keep your promises visible
Tickets with priorities, response times that turn red when a ticket runs late, and a support bot for after hours, in one app. Alori is free to start, with no credit card. Build your app now.