A Service Level Agreement (SLA) is a document that defines IT response times to the customer's issues. It may sound dull, but the absence of an SLA results in disorder: the customer does not know what to expect, the IT team does not know what is expected of it, and disputes are inevitable when things go wrong. This article sets out the 8 mandatory elements of an SLA agreement, how to determine contractual penalties for breaches, what response times are realistic, and provides a downloadable template that may be adapted to your organization.
What an SLA is and why every IT supplier should have one
An SLA is a service agreement entered into by the IT supplier (the Provider) and the customer (the User / Company). It shall define:
- Response times for different categories of issues (e.g., P1 = 30 min, P2 = 2h)
- Service hours (business days only or 24/7)
- Consequences of breaches (contractual penalty or additional support)
- Matters excluded from the SLA (hardware replacement, planned maintenance)
8 mandatory elements of an SLA agreement
1. Heading: the date, the parties to the agreement (the IT department or supplier, and the customer), and the term of the agreement.
2. Definitions: the definitions of P1, P2, P3, P4 incidents must be unambiguous (for example, "P1 = system fully unavailable, 50 or more users unable to work").
3. Reaction Time: the time elapsed between submission of the ticket and the first contact from a technician with the customer.
4. Resolution Time: the time available to deliver the FULL resolution of the issue.
5. Service hours: whether the SLA applies during 08:00-17:00 or 24/7. Coverage of weekends and public holidays shall be specified.
6. Exclusions from the SLA: planned maintenance, issues caused by the customer, and force majeure shall not count toward SLA timers.
7. Penalties and credits: the consequences of a breach of times shall be set out, whether a refund, free additional support, or otherwise.
8. Review and amendment: the SLA shall be reviewed annually or whenever the IT structure changes materially, and amended accordingly.
Response and resolution times - illustrative values
The table below presents illustrative starting points, not a binding market standard. The specific response and resolution times shall be set individually depending on the criticality of services, team availability, and customer expectations. Begin with values you can realistically meet.
| Priority | Manufacturing (24/7) | Office (8-17) | Startup (Backup) |
|---|---|---|---|
| P1 | Reaction: 15min / Res: 2h | Reaction: 30min / Res: 4h | Reaction: 1h / Res: 8h |
| P2 | Reaction: 1h / Res: 8h | Reaction: 2h / Res: 8h | Reaction: 4h / Res: 24h |
| P3 | Reaction: 4h / Res: 24h | Reaction: 4h / Res: 2d | Reaction: 1d / Res: 5d |
| P4 | Reaction: 1d / Res: 5d | Reaction: 2d / Res: 10d | Reaction: 5d / Res: 30d |
Contractual penalties and credits - how to set them
The models and percentage values below are examples illustrating possible approaches. The specific amounts shall be agreed between the parties to the agreement. There is no single binding market standard.
Option 1: Percentage refund. Upon a breach of response or resolution time, the customer shall receive an agreed percentage refund for the relevant month, typically subject to a monthly cap. For example, a defined percentage refund for each breach, up to a fixed monthly maximum.
Option 2: Support credits. Instead of a monetary refund, the customer shall receive additional support hours free of charge, proportional to the delay.
Option 3: Tiered penalties. Isolated breaches in a month shall not trigger a penalty; the penalty applies only once an agreed breach threshold is exceeded. This approach is often perceived as more equitable.
SLA drafting errors to avoid
- An overly ambitious SLA: committing to a 1-hour P1 response 24/7 with only 2 technicians is unsustainable. Start with a realistic SLA and tighten it over time.
- No clear P1-P4 definitions: "urgent" is too vague. The definition must be precise, for example: "P1 = total unavailability affecting 50+ users".
- Service hours different from actual coverage: stating "24/7" while operating only 08:00-17:00 will cause customers to wait overnight and lose trust in the agreement.
- No exclusions: planned maintenance must be expressly excluded from SLA timers.
- Penalties too low: a 1% penalty creates no operational incentive and will be disregarded.
FAQ - IT SLA agreement
Should every IT contract include an SLA?
Yes. The SLA need not be complex (it can be one page), but it must define response and resolution times for each incident priority. Without an SLA, both the customer and the supplier operate under unclear expectations.
What happens when an SLA is breached?
An SLA breach may (but need not) result in a contractual penalty. Penalties may be financial (% refund for the month) or non-financial (additional support). The agreement should clearly define what happens.
Should the SLA be the same during day and night?
Not always. If the customer works 08:00-16:00, the SLA should apply only during those hours (a different definition of resolution time). If the customer operates 24/7, the SLA should be the same around the clock. This must be clearly defined.
How should contractual penalties for SLA breaches be priced?
The most common approach is a percentage refund of part of the contract value for the delay, or credit in the form of additional support hours. Specific rates are agreed by the parties to the contract - there is no single market standard. The penalty should serve as motivation to meet the SLA, not as a sanction for situations beyond the supplier's control.
Related articles
SLA for a manufacturing plant - how to set IT response times IT helpdesk KPIs - 12 indicators every IT manager must track Change management in manufacturing - managing IT changes without downtimeNeed an SLA template for your company?
Rotech Group will prepare an SLA template tailored to your industry (manufacturing, IT, MSP, finance) covering all 8 mandatory elements.
Request an SLA template →