What a real IT support SLA for small business looks like

Here's the short version: a real IT support SLA for small business puts numbers and consequences on the promises. Defined response tiers, a guaranteed clock for each, support hours the clock actually runs in, and a credit when they miss. Everything else is a marketing line. If a provider's "SLA" is a paragraph of adjectives (fast, proactive, dedicated) with not one figure you could hold them to, there is no agreement, just a brochure. This piece gives you the response tiers in plain English so you can read any contract and tell the difference, plus the six questions that flush out the truth before you sign.

The SLA is the only part of the contract that means anything when something breaks

Every IT provider says they're responsive. The SLA, the service level agreement, is where they're forced to say what that means in writing. It's the bit you don't read when things are fine and the only bit you care about at 4pm on a Friday when the whole office can't get email.

The problem is that "SLA" has been hollowed out into a sales word. Plenty of contracts carry an SLA heading and then a few sentences that commit to nothing. So before you compare anything, get the actual document, the table with the tiers and the times, and read it for two things only: numbers and consequences. If you can't find a number you could quote back at them, and nothing happens when they're late, you don't have an SLA. You have a wish.

Response tiers, in plain English

This is the heart of it, and it's where most small businesses get fooled. A real SLA doesn't promise the same speed for everything, because that would be either impossibly expensive or uselessly slow. It sorts problems into tiers by how much they hurt, and guarantees a different response time for each. Here's the shape worth holding out for, in normal words:

• Critical: the business is down. Nobody can work. The server's dead, the internet's gone, the phones are off, or you've been locked out of everything. This is the one you're really paying for. A workable guarantee is a real person on it inside about an hour, in your support hours.
• High: one or a few people can't work. A staff member's laptop won't boot, someone can't get into the system they need, a printer the whole front desk relies on has died. Painful but not fatal. A few hours is a fair guaranteed response.
• Medium: it's degraded, but you're limping along. Something's slow, an app keeps crashing, a non-critical service is flaky. Same business day is reasonable.
• Low: requests and "when you get a chance". New starter setup, a software install, a question. A couple of business days, or a scheduled slot, is fine.

You don't need exactly four tiers, and the times aren't sacred. What's non-negotiable is that the tiers exist, that they're defined so it's clear which bucket a problem lands in, and that the times are guaranteed, not "targeted". The biggest tell of a fake SLA is one flat line for everything: "we aim to respond within 24 hours." A whole-business outage and a request for a new mouse should never share a clock.

Response time is not resolution time, and the gap is where you get burned

Here's the distinction that costs people money because nobody explained it. Response time is how long until a human picks up your ticket and starts. Resolution time is how long until it's actually fixed. Almost every provider guarantees the first and not the second, and that's fair, because how long a fix takes genuinely depends on the fault. A failed hard drive and a forgotten password aren't the same job.

The trap is what counts as a "response". On a weak SLA, the response is an automated email that says "we've received your ticket, reference #48213." That's not a response. That's a receipt, and the clock has technically stopped while nothing is happening. When you read the tiers, make sure response is defined as a real person has picked it up and begun working on it, not that a robot acknowledged it landed. If the document is vague on this point, it's vague on purpose.

Support hours: the clock only counts when they're open

A "one-hour response" means nothing until you know one hour of what. SLA clocks run during defined support hours, and that's reasonable, because you can't pay business-hours money for someone sitting up at 2am. But it's also where the fine print bites. If your SLA covers 8am to 6pm Monday to Friday and your café trades all weekend, a Saturday outage isn't a breach of anything; the clock simply isn't running until Monday morning.

So match the hours to how you actually work. If you trade weekends or nights, you need an SLA whose clock runs then, or a defined (and separately priced) after-hours tier for genuine emergencies. Don't pay for 24/7 you'll never use, but don't assume the standard business-hours SLA has you covered when you don't keep business hours. This is exactly the kind of inclusion that separates two quotes that look identical on price; for how that flows through to the monthly figure, see what managed IT services actually cost and what should be included.

The uptime number, and why most of them are marketing

You'll see uptime guarantees thrown around: 99.9%, 99.99%, "five nines". The maths is worth knowing because it's smaller than it sounds:

• 99.9% ("three nines") allows about 43 minutes of downtime a month, roughly 8.7 hours a year.
• 99.99% ("four nines") allows about 4 minutes a month.
• 99%, which sounds fine to most people, allows over 7 hours a month. That's a working day of outage, inside the guarantee.

But the percentage is the easy bit. The real question is uptime of what. A guarantee on a provider's own hosting or a service they fully control is meaningful. The same number waved at your whole office, including your NBN or 5G connection, your hardware and your power, is meaningless, because they don't control any of it. When the internet drops because of an NBN fault up the street, that's not their SLA breaking; it was never theirs to guarantee. So pin it down: uptime of which system, measured how, and what's the credit if they miss? An uptime promise with no credit attached is just a number on a page.

"Consequences" is the word that separates real from rubbish

An SLA without teeth is a press release. The mechanism that makes it real is the service credit: if they breach the agreed times, you get money back, usually a percentage of the month's fee. It's rarely going to make you whole for a bad outage, and that's not the point. The point is it gives the provider skin in the game: missing the SLA costs them, so they build their staffing and processes to hit it. No credit, no consequence; no consequence, no real commitment. When you read the document, find the clause that says what happens when they're late. If there isn't one, the times above it are aspirations.

The six questions that flush out the truth

You don't need to be technical to test an SLA. Ask these, plainly, and listen for whether the answers are specific or slippery:

1. How do you classify a ticket as critical versus routine, and who decides? If the provider alone decides, your "critical" outage can quietly become their "medium".
2. What are the guaranteed response times for each tier? You want numbers, and the word "guaranteed", not "targeted" or "typically".
3. What hours does the clock run, and what does after-hours cost? Match it to how you trade.
4. Is it response or resolution you're guaranteeing, and what counts as a response? A human, not an auto-reply.
5. What's the credit if you miss the SLA? No answer means no teeth.
6. If I leave, who owns my data, domains and passwords? The only correct answer is "you do". An SLA is worthless if you're held hostage by the exit.

A provider who answers those six straight is showing you how they'll treat you for the next three years. One who reaches for adjectives is telling you something too.

What I'd actually want in my own contract

If it were my business signing, I'd want a one-page table I could pin to the wall: four tiers, a guaranteed response time against each, the support hours stated, response defined as a real person starting work, a service credit if they miss, and a clean exit with my data and credentials mine to take. No lock-in dressed up as a discount. No uptime number for things they don't control. Plain English the whole way down, because a contract you can't read isn't protecting you, it's protecting them.

An SLA is one piece of the wider managed-IT picture. The same "is this real or is this a sales line" test applies to the security stack and the phones. It's worth reading alongside where small-business cyber security should actually start and the buyer's guide to business VoIP phone systems. For the full set, browse the managed IT articles.

Frequently asked questions

If you'd like to read your current IT contract against this and aren't sure what half of it means, send it over. We'll tell you plainly where it's solid and where it's just adjectives, no obligation to switch anything. Tell us what your setup looks like and we'll point you straight.