How to Read the SLA in an IT Maintenance Contract

SLA is the most quoted and least questioned abbreviation in IT support sales. Everyone promises "fast intervention" in the meeting; when systems are down, the only thing that matters is the number written in the contract. The SLA — Service Level Agreement — is that number in writing. This guide covers how to read one: the critical difference between response and resolution time, the priority classes that make a single blanket number meaningless, and the exception clauses that quietly decide real-world outcomes.

What an SLA Is, and Why It Matters

The SLA is the contract section that defines which type of incident gets which intervention, through which channel, within how much time. A well-written SLA protects both sides: the customer knows what to expect, the provider knows what it has promised. Without one — or with a vague one — priority always belongs to whoever shouts loudest.

Typical symptoms of a vague SLA:

• Open-ended phrases like "intervention as soon as possible"
• Response and resolution collapsed into one number
• No definition of incident priorities
• No statement of which hours the clock runs in
• Silence on what happens when the commitment is missed

Response Time Is Not Resolution Time

This is the single most important reading skill. Response time is how long until a technician starts working on your ticket; resolution time is how long until the problem is fixed. A "one-hour response" commitment says nothing about when you will be operational again — only that someone will engage within the hour.

An honest contract usually avoids promising a hard resolution number for everything, defining target ranges or "planned according to the nature of the work" instead — replacing a disk and recovering corrupted data simply do not run on the same clock. The suspicious contract is the one that promises the same aggressive resolution time for every possible failure.

Priority Classes: Not Every Incident Is Equal

Priority	Definition	Example
Critical (P1)	The operation has fully stopped	Server down, nobody can work
High (P2)	A key function is out, work partially continues	Accounting system unreachable
Medium (P3)	One user or one device affected	Email broken on a single PC
Low (P4)	No business impact, can be scheduled	New-user setup request

A single blanket number without this classification fails in both directions: too slow for the critical case, and you pay urgency pricing for routine requests that never needed it.

Three Clauses Everyone Misses

The Measurement Window

"Four-hour intervention" tied to business hours can legitimately mean Monday morning for a ticket opened Friday at 5 pm. The contract must state whether times run on calendar hours or business hours, and exactly where the business-hours window begins and ends.

Exceptions and Clock Pauses

Time spent waiting for information from the customer, delays caused by third parties (the ISP, a software vendor) and parts procurement typically pause the SLA clock. The existence of such exceptions is normal; leaving them undefined is the problem.

What Happens on a Miss

Enterprise contracts balance SLA breaches with service credits or fee reductions. SME contracts often lack this clause entirely — at minimum, repeated breaches counting as grounds for termination is a reasonable middle ground worth asking for.

Real-World Examples

Example 1: An E-Commerce Warehouse

A fulfilment business discovered on outage day that its contract carried a single flat "24-hour resolution" clause — a jammed label printer and a crashed server sat in the same queue. The renewed agreement defined priority classes with a separate track and escalation path for critical incidents; the next outage ran on the priority table, not the queue.

Example 2: An Accounting Practice

During filing season, a practice watched its e-signature ticket get "responded to" promptly — then sit unresolved for days, because the contract committed only to response. The renewal added a season-critical application list: during filing periods, the tax software and e-signature stack are treated as high priority by default.

How Yamanlar Bilişim Supports This Process

Yamanlar Bilişim treats the SLA as an operations plan, not a marketing number. The engagement starts by mapping which systems are genuinely critical for the business; priority classes and intervention channels are written against that map. Times are defined together with the measurement window, and because every ticket's opening, handling and closure is logged, whether the commitment was honoured is visible in a report — not a matter of memory.

Topics clarified when designing the SLA include:

• Building the critical-system list together with the business
• Priority classes and the intervention channel for each
• Response and resolution targets written separately
• Measurement window and exception conditions defined explicitly
• Periodic SLA reporting backed by ticket records

The full maintenance scope is described on the Managed IT Support & Maintenance page, and the companion article on what drives contract pricing shows how SLA speed feeds the cost.

FAQ