Published: 20 April 2026 | By AOLC
A service level agreement — or SLA — is the single most important document in any managed IT contract. It is where the provider's marketing promises become contractual obligations. It is also the document most often skipped over in the excitement of signing a new deal, and then regretted the first time an incident takes longer to resolve than anyone expected.
This guide explains exactly what an IT support SLA should include, what fair response and resolution times look like in South Africa in 2026, and the red flags to watch out for when comparing providers.
An SLA without priority tiers, without business-hours clarity, and without measurable compliance reporting is not really an SLA — it is a marketing promise dressed up in a table. Know the difference before you sign.
A proper IT support SLA is built on four pillars: priority tiers, response times, resolution times, and service hours. Miss any one of these and the agreement has holes you will feel in the worst moments.
What is a reasonable SLA in the South African market? Below is what a good managed IT provider should commit to, and what you should push back on if a quote falls short.
| Priority | Example | Response | Resolution | After-hours |
|---|---|---|---|---|
| P1 — Critical | Server down, ransomware, email outage | 15 min | 4 hours | YES |
| P2 — High | Multiple users affected, VPN down | 1 hour | 8 hours | YES |
| P3 — Normal | Single user issue, slow laptop | 4 hours | 3 business days | No |
| P4 — Low | Non-urgent request, feature request | 8 hours | 7 business days | No |
These are the benchmarks AOLC commits to and what most reputable SA MSPs should offer. If a provider quotes you P1 response times of "4 business hours" or offers no after-hours cover for critical incidents, you are looking at a break-fix service rebranded as managed IT.
Fair P1 response time for SA managed IT in 2026. If you are being quoted longer than 30 minutes for a business-down incident, the provider is not structured to support you during outages.
This is the single biggest source of misunderstanding. Response time is the commitment to start work — a technician has acknowledged the ticket, gathered information, and begun diagnosing. It does not mean the problem is fixed.
Resolution time is the commitment to actually close the ticket — the problem is fixed or a documented workaround is in place. Resolution is a target, not a guarantee, because the root cause may involve third parties (Microsoft, your ISP, a hardware vendor) whose own SLAs are outside your provider's control.
A well-written SLA makes this distinction explicit, and includes provisions for pausing the resolution clock when the ticket is blocked by something outside the provider's control — a vendor response, a client approval, a hardware delivery. Without this, response targets become meaningless because the provider cannot realistically commit to resolving what they do not control.
When reviewing a provider's SLA, watch for these patterns — they are the ones we see again and again when taking on clients who have switched from another MSP:
Tip
Ask your current or prospective provider for their SLA performance report for the last quarter. A reputable provider measures SLA compliance and can show you the numbers. If they cannot (or will not), that tells you everything you need to know.
A modern SLA should recognise that security incidents — active ransomware, credential compromise, phishing-driven wire fraud — are not ordinary IT tickets. They warrant P1 response and a documented incident-response runbook, not a place in the normal queue. At AOLC, confirmed security incidents are logged as P1 with immediate escalation to our security lead and are covered by our 24/7 after-hours response.
If your provider's SLA treats a ransomware attack the same as a broken printer, the SLA has not been updated for the reality of South African cyber threats in 2026.
An IT support SLA is not a formality. It is the contract that tells you what you will actually get when things go wrong — which is the moment when you most need clarity and least have time to negotiate. Before you sign, make sure the SLA has clear priority tiers, specific response AND resolution times, defined service hours, after-hours cover for critical incidents, and quarterly compliance reporting so you can measure the provider against their own promises.
If any of those are missing, raise it before signing. A reputable provider will rewrite the SLA. An unreliable one will explain why they cannot — and that, too, is useful information.
Want to see what a proper South African IT support SLA looks like? We will walk through ours in detail and compare it to what you currently have — no commitment required.
Contact Us