The SLA is often presented as the core of a managed service contract. In many offers, it still boils down to a few lines about response time. That approach feels reassuring when read. It remains too weak to steer a real service.
A useful SLA does not measure speed alone. It describes how the provider treats criticality, organizes escalation and reports service quality over time.
A concrete example of a bad reflex and a better one
A bad reflex is to look only at a response commitment such as acknowledgement within one hour. That formulation may look strong. It still says nothing about restoration time, criticality or the fact that an incident may block the whole business.
A better reflex is to distinguish acknowledgement, workaround target, restoration target and possible dependence on third parties. Only at that level does the SLA begin to describe a real service.
The real issue
A fast response time does not guarantee correct resolution or satisfactory recovery. One team can answer quickly to a ticket and still leave a critical system unavailable for too long. Another can formally meet a commitment that was never tied to the actual business stakes.
The issue is therefore not whether an SLA exists. The issue is how well it is built.
The building blocks of a useful SLA
Criticality
Not all incidents have the same impact. A user blocked on a non-critical application does not represent the same issue as an authentication failure, primary Internet outage or impossible restore. The SLA should rest on criticality levels defined before the incident occurs.
Acknowledgement
Acknowledgement time measures how long it takes to recognize an incident and begin treatment. That indicator matters. It cannot be the only one.
Resolution
Resolution time measures the return to an acceptable service state. It is usually the indicator closest to business impact when production is affected. It therefore needs to be defined precisely.
Service window
A commitment only makes sense when it says during which time window it applies. Business hours, evening extension, on-call coverage or extended service all change the actual value of an SLA.
Measurement method
Who opens the incident. When the timer starts. When the timer stops. What happens when time is lost waiting for a third party or for client validation. Without a measurement method, the numbers remain debatable.
The indicators that matter most in SMBs
For an SMB, an SLA becomes truly steerable when it covers at least the following.
- Acknowledgement time by criticality.
- Resolution or workaround time by criticality.
- Availability of key services.
- Recovery time in case of a major incident.
- Review frequency for commitment compliance.
These indicators have one simple benefit. They link the delivered service to the real continuity of the business.
What RTO and RPO really change
Backups are often treated as a separate topic. In reality, they fully belong to service level design. RTO is the target recovery time after an incident. RPO is the amount of data loss the organization can tolerate. Both notions structure continuity. They are not merely technical.
An SLA that talks about backup without linking it to recovery objectives leaves out the main question. How long can the activity remain degraded and how much data loss can be accepted.
The difference between contractual commitment and internal target
The term SLA refers to a formal service commitment. Some organizations also track internal performance targets that do not hold the same contractual value. That distinction matters. An indicator may guide continuous improvement without becoming an enforceable contract commitment.
A simple criticality grid
| Level | Example | Target acknowledgement | Target restoration |
|---|---|---|---|
| Critical | Production stopped | Very short | Short |
| Major | Important service degraded | Short | Moderate |
| Standard | User incident | Moderate | Moderate |
| Minor | Non-blocking request | Normal | Planned |
The point of such a grid is not to define universal numbers. Its value lies in preventing a major incident from being treated like a simple inconvenience.
Topics that often require different targets
Not every topic calls for the same commitment.
| Topic | What matters most |
|---|---|
| User support | Acknowledgement and prioritization |
| Critical servers and applications | Restoration and escalation |
| Backups | Verification and recovery objectives |
| Primary Internet and core network | Workaround and third-party coordination |
That distinction avoids applying one identical logic to incidents that do not carry the same impact.
Common mistakes
Using one indicator only
An SLA reduced to response time creates an illusion of control. It leaves out recovery, availability and real resolution quality.
Not linking SLAs to critical systems
A generic commitment loses much of its value when it fails to distinguish vital services from secondary ones.
Ignoring external dependencies
Carrier, software vendor, cloud host or telephony provider may all influence resolution. The contract should explain how those dependencies interact with the main SLA.
Confusing SLA and SLO
The SLA contractually commits the provider. The SLO remains an internal performance or steering target. The two can coexist. Confusing them mainly creates misunderstandings about what is actually enforceable.
Never revisiting service levels
An SMB evolves. Critical systems change. A relevant SLA should therefore be reviewed regularly. A strong governance report helps show whether the commitments still match the environment.
What this changes in practice
A well-designed SLA helps move away from a purely impression-based reading. Service quality becomes measurable. Treatment priorities become explicit. Budget arbitration becomes more rational.
It also becomes possible to compare two offers on a real basis. Without a criticality structure, a measurement method and recovery objectives, the word SLA remains largely decorative. For a broader frame, the managed service contract should always be read alongside it.
Sources
Sources
Support available on this topic
Initial Infrastructures handles these topics for SMBs and mid-size companies. A short call is enough to identify priorities and the right scope of intervention.