Most internal IT SLAs are copied from a managed-service contract and then quietly abandoned, because they promise things the team was never staffed to deliver. This one starts from what you measurably do today and makes the exclusions explicit, so the document survives contact with a bad month.
What you get
Response and resolution targets per priority, with the service hours they are measured against
An exclusions section: the part most SLAs omit and then argue about
A clock-stop definition for time spent waiting on the requester or a vendor
A review and reporting cadence, so the SLA is measured rather than filed
How to use this template
1
Measure before you promise. Pull your last 90 days of tickets and find your actual 90th-percentile response and resolution times per priority. Set the target just inside that. An SLA built on aspiration generates breach reports that teach everyone to ignore breach reports.
2
Define the clock before the target. A four-hour target is meaningless until you say four hours of what. Name your service hours, your holidays, and whether the clock runs overnight. Two teams reading the same number differently is the most common cause of an SLA dispute.
3
Write the exclusions in, not out. Third-party outages, unsupported hardware, changes needing vendor action, and requests missing required information all behave differently. Listing them is not weaselling. It is the difference between a document you can defend and one you abandon.
4
Agree the clock-stop rule explicitly. Decide now whether the clock pauses while you wait on the requester. Most teams pause it; the failure mode is pausing it without telling anyone, which looks like gaming the numbers. State it, and show paused time separately in reporting.
What's inside
Here's a preview. Unlock the free download to get all 6 sections (5 more below).
Agreement details
Who this covers and who owns it. An SLA with no named owner stops being true within a quarter.
A priority matrix only earns its place if two different agents classify the same ticket the same way. This one defines impact and urgency as countable things (how many people, and whether work has already stopped), so the grid produces one answer instead of a conversation.
Escalation fails when it depends on someone deciding to escalate. Time-based triggers remove the judgement call, so a ticket moves because the clock says so rather than because an agent felt stuck enough to ask.
A service catalogue written in IT's language lists systems. One written in the requester's language lists outcomes ('I need access to the finance system', not 'ERP permission provisioning') and that distinction decides whether anyone uses it.
The services covered, service hours, response and resolution targets per priority, exclusions, clock-stop rules, how performance is reported, and named owners on both the provider and business side. Without the exclusions and the clock definition, the targets are not measurable.
What is the difference between an SLA and an OLA?
+
An SLA is the commitment to the customer or business. An OLA is the internal agreement between the teams that make the SLA deliverable: for example, how fast the network team must respond when the service desk escalates. An SLA you cannot support with OLAs will breach at the handoffs.
Should the SLA clock pause while waiting on the user?
+
Most teams pause it, and that is defensible. The requirement is that the rule is written down, the requester is told when the clock pauses, and reporting shows paused time separately. Pausing quietly looks like manipulating the numbers even when it isn't.
How often should an IT SLA be reviewed?
+
Quarterly. Headcount, tooling, and the estate all change faster than a year, and an annual review means at least a couple of quarters of unnoticed drift. Review against actual performance, not against whether anyone complained.