A good IT SLA names the service, ranks problems by business impact, sets a response time and a resolution target for each rank, states the hours covered, and says what happens when the provider misses. The examples below show each of those parts written in plain terms, so you can compare them with the agreement you hold now or the one you are about to sign.
The examples are illustrative wording, not a quotation from any contract. Targets differ by provider, by service tier and by what your business can tolerate, so treat the figures as a starting point for your own conversation.
TL;DR
- An SLA is a written commitment to a customer, with a threshold and a consequence. A KPI is an internal measure with no counterparty.
- Every helpdesk SLA needs priority levels, a first response time, a resolution target, covered hours, escalation rules and pause conditions.
- Response time means the first human reply, not an automatic acknowledgement. Resolution means the cause is fixed or the request is complete.
- A 99.99% availability promise allows about 52 minutes 36 seconds of downtime a year, so check how the figure is measured.
- Review the agreement at least quarterly and keep the report to the few metrics that show whether the relationship works.
Table of Contents
- What an IT support SLA actually is
- What a helpdesk SLA should include
- IT SLA examples by priority
- What “response time” means, and how it is measured
- Uptime examples: what 99.99% really allows
- Which metrics to put in the report
- Setting targets you can both live with
- Our perspective
- How Lancast supports businesses that want a clear SLA
- A checklist before you sign
- FAQ
- Sources
What an IT support SLA actually is
A service level agreement is a documented contract between a provider and a customer. According to ITIL’s definition, it sets out responsibilities, performance standards, response times, availability targets and the remedies if agreed levels are not achieved. Atlassian describes it as a plain-language agreement covering the services to be delivered, the responsiveness expected and how performance will be measured.
A useful test is whether a missed target changes anything. The Irish Institute of Public Administration’s guidance on service level agreements says service levels should be readily understood by staff on both sides. If your office manager cannot read the document and say what happens when the server goes down at 9:15 on a Monday, the wording needs work.
SLA or KPI: the difference in one sentence
A KPI is an internal measure with no contractual weight, while an SLA is an external commitment where a miss has commercial consequences such as service credits or contract review. The same number can be both. First response time is a KPI when the support team reviews it internally, and an SLA when a contract promises an answer within a stated time and a credit if it is missed.
For a business buying support, the practical point is simple. The KPI tells the provider how the team is doing. The SLA tells you what you are entitled to.
What a helpdesk SLA should include
TechCentral.ie once quoted an Irish consultant who split an SLA into two parts: the service description (what is done, hours, cost, escalation) and the management level (overall service level, dispute resolution, review frequency). The second part is often neglected until something goes wrong, and it is the part that keeps an agreement useful in year three.
Putting that together with the components listed in Freshworks’ helpdesk SLA guide and ManageEngine’s SLA guide, a sound IT support SLA covers the following.
Service description. Which systems, users, sites and devices are covered, and which are not. “All Microsoft 365 users and the office network at the Bray site” is better than “IT support”.
Priority levels. Typically Critical, High, Normal and Low, each defined by business impact rather than by who is complaining.
First response and resolution times. One of each, per priority.
Operational hours. Business hours, 24/7, or a mix by priority.
Escalation rules. Who is contacted, and when, if a target is at risk.
Pause conditions. The clock stops while the provider waits for you, for example for a reply or for access to a locked room.
Remedies and review. Service credits or other remedies, reporting frequency, and a scheduled review.
IT SLA examples by priority
Benchmarks published by EmailMeter put response times at 15 to 30 minutes for critical issues, 1 to 2 hours for high, 4 to 8 hours for medium and one business day for low. The table below shows how a small Irish office might apply that pattern. The wording and the targets are illustrative.
| Priority | Example situation | Illustrative response | Illustrative resolution target | Hours covered |
|---|---|---|---|---|
| Critical | Server down, whole office cannot work, email unavailable | 30 minutes | 4 hours, or a workaround in place | Extended or 24/7 |
| High | One department cannot access the finance system | 1 to 2 hours | 8 working hours | Business hours |
| Normal | One user cannot print or a laptop is running slowly | 4 hours | 2 working days | Business hours |
| Low | New starter set-up, software request, advice | 1 working day | 5 working days | Business hours |
The logic matters more than the numbers. Murphy, quoted in the same TechCentral.ie piece, advised customers to separate what is mission critical from what is not: a two or four hour response on revenue-generating systems, while an internal system may be down for a day without business impact.
Example clause: response time
For Critical incidents, the provider will make first contact with a named customer representative by phone within 30 minutes of the incident being logged, during the agreed support hours. An automated acknowledgement does not count as first contact.
Example clause: resolution and pause conditions
The resolution target runs from the time the incident is logged until service is restored or a workaround is in place. The target clock is paused while the provider is waiting for information, access or approval from the customer, and restarts when the customer responds.
Example clause: escalation
If a Critical incident is not resolved within 2 hours, the provider will escalate to the senior engineer on duty and notify the customer’s named contact. If it is not resolved within 4 hours, the provider’s service manager will contact the customer directly and agree a recovery plan.
Example clause: priority definitions
Critical: a service that stops the business operating or a security incident in progress. High: a service degraded for a team or department. Normal: a fault affecting one user with a workaround available. Low: a request or question with no operational impact.
Separate tiers matter because averaging response and resolution times across priorities hides the very failures an SLA is written to catch. A password reset and a system-wide outage should never share one target.
What “response time” means, and how it is measured
This is where most disputes begin. Response time is the elapsed time between a ticket being created and a technician’s first human reply, and automatic acknowledgements do not count. Resolution time runs from creation to the point the issue is resolved, with the clock paused while waiting for the customer.
It is worth asking your provider which of the following three clocks the agreement uses, because they are different promises.
Response: a technician has picked up the ticket and started work.
Restoration: the service works again, possibly through a workaround.
Resolution: the underlying cause is fixed or the request is complete.
Reporting tools also differ in what they count. IBM’s documentation for its SLA report shows average response time measured in business hours and calculated only for closed tickets. That is a reminder to ask whether your figures are measured in calendar hours or working hours, and whether open tickets are included.
Uptime examples: what 99.99% really allows
Some IT agreements, especially for hosting, connectivity and cloud services, promise availability rather than response times. A 99.99% target allows 52 minutes 36 seconds of downtime a year, 4 minutes 23 seconds a month and about 8.6 seconds a day, assuming round-the-clock availability is required.
An example clause might read as follows.
The hosted service will be available 99.99% of the time in each calendar month, excluding agreed maintenance windows notified at least five working days in advance.
The small print decides the value of that sentence. Ask how availability is measured, whether planned maintenance is excluded, and whether partial outages count. Also ask whether the service credit is automatic or must be claimed. Service credits are the usual remedy: one published template, for instance, offers a 10% credit when a device is unavailable for 25 minutes, but credits differ widely between providers, so read yours.
Which metrics to put in the report
There is a temptation to measure everything. McLaughlin, quoted by TechCentral.ie, describes a cycle in which reports start with a couple of hundred metrics and narrow over time to the core few that show whether the relationship is working. A monthly report for a small or medium business usually needs only the following.
SLA compliance percentage. The share of tickets that met their response and resolution targets, shown per priority. Supportbench’s framework uses 99% compliance as an example target and also tracks average resolution time, escalation rate (2% in its example) and customer satisfaction (4.5 out of 5).
First response time and time to resolve. Reported separately for each priority.
Escalation rate. How often tickets needed a senior engineer, which hints at training gaps or recurring faults.
Repeat incidents. The same fault returning is a sign that the root cause has not been dealt with.
Satisfaction. A short rating from the people who raised the tickets.
One caution on realism: KPIs are only as reliable as the incident data behind them. A resolution time calculated from confirmed incidents is a different number from one calculated from a stream of raw alerts, as AlertOps notes. Agree up front what counts as an incident.
Setting targets you can both live with
A target that cannot be staffed is not a commitment, it is a hope. Start from your own business. List the systems the business cannot trade without, such as the accounting package, the booking system, email and the internet connection, and rank everything else beneath them. Then match each rank to a response and resolution target and to the hours when you actually work. A shop that trades on Saturdays needs Saturday cover for the till system, however quiet the office is.
From there, three habits keep an agreement healthy.
- Set targets slightly faster than the provider’s current median, so they stretch the team without being unrealistic.
- Use business hours for Normal and Low priorities and extended or 24/7 cover for Critical.
- Review targets every quarter.
Those last three points follow Jitbit’s best-practice guidance, which also notes that most teams aim for 90 to 95% compliance across all priorities combined, rather than 100%.
The review is where agreements improve. If the same type of ticket keeps appearing, fixing the cause is better than hitting the response target faster. Our guide to how to reduce helpdesk tickets covers that side, and the reduce support tickets playbook is a good example of how ongoing review and narrowing reports to meaningful metrics keeps the volume of requests down.
Our perspective
We have spent 30 years supporting Irish organisations, and the pattern we see most often is that an SLA is written once and then filed. The agreements that work are the ones both sides read.
We believe the best SLA starts with a conversation about your business, not a template. Which systems earn your revenue? Who needs cover outside office hours? What would a day of downtime cost? Those answers set the priority levels, and the priority levels set everything else.
We also believe proactive monitoring changes what an SLA is for. When we can detect and deal with a fault before your team notices it, the best response time is the one nobody needs to measure. That is why our managed services combine monitoring, remote and onsite support, and consultancy, so that we act as an extension of your own team rather than a number to ring.
Our Silver, Gold and Platinum support plans exist so you can match the level of cover to the level of risk. We would rather talk you through which tier suits your business than sell you more than you need.
Carl
How Lancast supports businesses that want a clear SLA
We provide proactive managed services, strategic IT consultancy, project delivery and ongoing technical support for organisations in Ireland, as a Microsoft Cloud Service Provider and HP Amplify Partner. Our Silver, Gold and Platinum support plans cover remote and onsite support, and our business IT helpdesk support is built around keeping people working.
If you want help drafting priority levels, comparing an existing agreement with what your business needs, or deciding between support tiers, talk to our team and we will walk you through it. If you are weighing options, our guides on managed IT services for small businesses and managed IT versus in-house IT set out the questions to ask.
A checklist before you sign
Before you agree to any IT support SLA, read it for these points.
Does it define each priority by business impact, with an example of each? Does it state that response means a human reply? Are hours covered written out, including bank holidays? Is it clear when the clock pauses? Is there a named escalation route with times? Are remedies stated and is the process for claiming them simple? Does it say how often reports arrive and when the agreement is reviewed? And does it cover the equipment and services you actually use, including backup and disaster recovery, so that a restore time is as clearly defined as a response time?
On that last point, backup is a good test of whether an SLA is complete. A response time tells you how quickly someone answers. A recovery target tells you how long you are without your data. Our pages on business backup and disaster recovery plans explain how those targets are set.
FAQ
What does SLA response time mean?
It is the time between you reporting a problem and a technician making first human contact about it. Automatic acknowledgements do not count. It is separate from resolution time, which measures how long it takes to fix the problem.
What is the difference between an SLA and a KPI?
An SLA is a written commitment to a customer, with a defined threshold and a consequence if it is missed. A KPI is an internal measure used to track performance, with no customer-facing penalty. A provider often uses KPIs to make sure it meets its SLAs.
What does a 99.99% SLA mean?
It means the service may be unavailable for about 52 minutes 36 seconds in a year, or about 4 minutes 23 seconds in a month, if availability is measured around the clock. Check whether planned maintenance is excluded, because that changes the real figure.
What response times are typical for different priorities?
Published benchmarks put critical issues at 15 to 30 minutes, high at 1 to 2 hours, medium at 4 to 8 hours and low at one business day. Your own targets should reflect the cost of downtime for your business and the hours you work.
How often should an IT SLA be reviewed?
Quarterly is a sensible rhythm for targets, with a monthly report between reviews. The review is the point at which both sides check that the priorities and hours still match how the business operates.
Sources
- ITIL: What is a service level agreement
- Atlassian: What is SLA
- Institute of Public Administration: Service Level Agreements
- AlertOps: KPI vs SLA
- TechCentral.ie: Getting the level of service right
- Freshworks: Help desk SLA guide
- ManageEngine: SLA examples for IT support
- EmailMeter: SLA response time
- Jitbit: Help desk SLA best practices
- IBM: SLA report details
- Uptime.is: 99.99% downtime calculator
- Supportbench: SLA and reporting framework