IT Service SLAs: Which Commitments Should You Insist On?

An SLA sounds like something for law students, but in practice it determines exactly what you get when you outsource your IT management. Will you get someone on the phone within an hour when email goes down, or not until Monday morning? Do you keep paying the full monthly fee after a day-long outage? And can you walk away if your IT partner keeps failing to deliver on its commitments? This article explains what an SLA for IT services actually is, which commitments SMEs should insist on, and what to watch out for when negotiating.

What is an SLA for IT services?

SLA stands for Service Level Agreement. It's the schedule to your IT contract that sets out what performance you can expect from your provider, how that performance is measured, and what happens if they fail to meet it. An SLA is therefore not a marketing brochure ("we're fast and reliable") but a measurable commitment ("we respond to a critical incident within 15 minutes, with a maximum resolution time of 4 hours").

In ITIL terminology, three types used to be distinguished: the SLA (external, with the customer), the OLA (Operational Level Agreement, within the same organisation) and the UC (Underpinning Contract, with external subcontractors). ITIL 4 dropped that three-way split for a pragmatic reason: in practice everyone calls everything an SLA, and the only difference is your perspective. For SMEs, the simple question is: "What can I expect as a customer?"

Why a good SLA matters so much for SMEs

We regularly see contracts in which the SLA consists of three sentences: "best-effort basis, office hours 9 to 5, service credits on request". Legally worthless: they measure nothing, oblige nothing and offer no way out.

IT downtime costs money in SMEs too. For example: if 25 employees can't work for a day because of a network outage and you conservatively estimate €300 per employee per day, that's €7,500. Two days a year and you're looking at €15,000, more than many annual contracts with an IT partner. A good SLA lets you claim those costs back, or at the very least gives you the right to leave without a penalty. See also What does outsourcing IT management cost in 2026.

The four building blocks of a strong SLA

Every serious SLA for IT services rests on four foundations:

1. Availability and service window. When can you reach someone (office hours, 24/7, weekends, public holidays) and through which channels (phone, portal, email, chat).
2. Response and resolution times per priority. How quickly a ticket is responded to, and within what timeframe it's resolved, differentiated by the impact of the problem.
3. Uptime and service availability. Percentages that indicate how often a service should be available and what happens when it isn't.
4. Consequences: service credits, exit clause and reporting. What it costs the provider if they don't meet their commitments, and what your legal options are.

The rest of this article walks through these four building blocks, plus a few extra components that are often forgotten in practice.

Availability and service window: what's realistic?

The first question: do you need 24/7 support? For a manufacturer, an e-commerce store or a healthcare organisation, the answer is yes. For a law firm that operates from 8 am to 6 pm, it's less clear-cut. With Dutch IT partners, 24/7 support typically costs 20 to 50 per cent more than extended office hours (for example 7 am to 7 pm on weekdays). Be honest with yourself about whether you'll actually use that night cover before you pay for it.

The second question: which channels? In practice, the portal and email handle most of the volume, but phone contact is essential for critical incidents. Ask for concrete figures: what percentage of calls are answered within 30 seconds? What's the average waiting time? Our separate guide to 24/7 IT support in the Netherlands explains how to weigh up those two questions.

Important: with modern service providers, the SLA clock pauses by default when a ticket is waiting on the customer ("pending customer" state). That's reasonable, but agree in writing what happens if the customer doesn't respond for a long time. Otherwise it's too tempting to "park" tickets in that state.

Response and resolution times per priority

An SLA without priority levels is useless, because a password reset doesn't have the same urgency as a complete email outage. The standard classification in IT services:

• P1 Critical. The business is (largely) at a standstill. Response within 15 minutes, resolution within 2 to 4 hours. Examples: mail server down, entire network down, ERP unreachable, suspected ransomware.
• P2 High. An important function or a group of users is affected. Response within 30 to 60 minutes, resolution within 4 to 8 hours. Examples: print server down, one of your branches without internet.
• P3 Medium. An individual user or a non-critical function. Response within 4 hours, resolution within 1 to 2 working days.
• P4 Low. A question or request with no impact. Response within 8 hours, resolution by agreement.

An important detail: response time is not resolution time. Response means someone calls you back; resolution means the problem is fixed. Some providers hide behind a fast response and drag out the actual fix. Always ask for both figures, and agree that the provider will notify you if the resolution target is at risk of being missed.

Who sets the priority is also part of the SLA. In healthy contracts the customer determines the priority; the provider may argue the point but may not downgrade it unilaterally.

Uptime and availability: what do those percentages mean?

Uptime percentages look impressive until you convert them into actual hours:

• 99% uptime. Up to 3 days and 15 hours of downtime a year. Not good enough for critical services.
• 99.9% uptime (three nines). Up to 8 hours 46 minutes a year, roughly 43 minutes a month. Standard for most business SaaS applications.
• 99.99% (four nines). Up to 52 minutes a year. Often required for banking, payment and healthcare solutions.
• 99.999% (five nines). Up to 5 minutes and 15 seconds a year. Only for hyperscale cloud infrastructure, telecoms and life-critical systems.

Two pitfalls. First: 99.9% per month isn't the same as 99.9% per year. A provider that doesn't commit to a monthly cap can be down for 8 hours in one go and still meet its target for the year. Second: the measurement definition. Is planned maintenance included? Does a partial outage (one of five functions not working) count as downtime? Pin this down in the SLA, or every incident becomes a game of semantics.

For SMEs, 99.9% per month for your core systems (email, SharePoint, ERP) is a reasonable minimum. Critical production environments often warrant 99.95% or 99.99%, with financial consequences if the target is missed.

Service credits and the exit clause

What happens if the provider misses its SLA? The usual instrument is service credits: a percentage of the monthly invoice is credited back. A typical sliding scale with Dutch IT partners: 5% when response times are exceeded in a month, 10 to 25% when the uptime target is missed, and 50% for repeated serious breaches.

Credits are a useful incentive, but they don't solve the underlying problem if a service is unreliable for months on end. That's why a strong SLA includes a chronic failure clause: if performance is below target for three or four months in a row, or there are more than two critical incidents within 12 months that aren't resolved within the resolution time, you can terminate the contract for cause without an early termination fee. Also ask for a cash-out option: unused credits should be paid out at the end of the contract rather than expire.

Reporting and transparency

An SLA that isn't measured doesn't exist. In a healthy contract the provider delivers a monthly SLA report containing at least:

• Number of tickets per priority and per category.
• Response and resolution times per priority, with an adherence percentage.
• MTTR (Mean Time to Resolve) and FCR (First Call Resolution) rate.
• Uptime measurements for core systems.
• CSAT score (customer satisfaction, measured after tickets are closed).
• Number of SLA breaches with root cause analysis.
• A look ahead: which process changes are coming up.

Best-in-class MSPs consistently achieve more than 95% SLA adherence; for P1 tickets, realistic targets are between 98 and 99%. On customer satisfaction, strong partners aim for 90% or higher. Ask for these figures before you sign; if the provider can't produce them, they aren't measuring them themselves and the SLA is just paper. For background on how an MSP makes its work visible, see what is system administration.

What's often forgotten

Three topics are missing from two-thirds of SLAs. Security SLAs: detection and response times for incidents such as an EDR alert, patch cycles and awareness training, all explicitly required under NIS2. Change management: lead times for standard and emergency changes; a helpdesk SLA often requires 4 to 8 hours for standard changes and 30 minutes for emergencies. And exit clauses with data portability: in which formats and at what cost do you get your data back when you leave? Since September 2025 the EU Data Act has enforced more transparency here.

Negotiating: where is there room to manoeuvre?

Standard SLA templates are negotiable, even for SMEs. The room is mainly in response times (P2 and P3 can often be tightened), service credit percentages and trigger thresholds, the chronic failure clause and cash-out, exit fees and data portability, and the contract term (12 months gives more flexibility, 36 months often better rates). Rarely negotiable: uptime percentages for external cloud services the MSP doesn't manage itself. There, the MSP itself depends on underpinning contracts with the hyperscaler.

Frequently asked questions about SLAs for IT services

What's the difference between response time and resolution time in an SLA? Response time is the time between your report and the provider's first substantive reply. Resolution time is the time within which the problem is actually fixed. Some contracts only specify response and fail to commit to resolution; ask for both, differentiated by priority.

What uptime should an IT partner offer an SME? For most core systems (email, file storage, ERP), 99.9% per month is a reasonable minimum, meaning no more than 43 minutes of downtime a month. Critical production or healthcare environments warrant 99.95 to 99.99%. Check the measurement definition: planned maintenance windows shouldn't be quietly excluded.

What are service credits, and do they actually work? Service credits are discounts on the monthly invoice when the SLA is breached. They work as a financial incentive but rarely cover your actual losses. That's why, alongside credits, there should be a chronic failure clause: if performance is structurally below par, you can terminate the contract without early termination fees.

Can I leave if my IT partner consistently fails to meet the SLA? Only if your contract says so. A good SLA includes a chronic failure clause: if performance is below target for three months in a row, you can terminate for cause without a penalty. Without such a clause, you're tied in until the contract term expires.

How often should I receive SLA reports? At least monthly, with a quarterly and annual review. A complete report includes volumes per priority, adherence percentages, MTTR, uptime measurements, CSAT and a list of breaches including root cause analysis. If the provider can't deliver that, they aren't measuring anything and the SLA is merely words on a page.

Does my SME need 24/7 support? Only if your business also runs outside office hours, or if customer services need to be available 24/7. 24/7 support typically costs 20 to 50% more; for a 9-to-5 office, a good 7 am to 7 pm model is often the better fit.

Conclusion

An SLA for IT services isn't an appendix you skim through. It's the document you use at the end of a bad month to show what the provider should have delivered, and the one that lets you walk away without a penalty if performance is structurally poor. The four building blocks are availability, response and resolution times per priority, uptime with a clear measurement definition, and consequences in the form of service credits with a chronic failure clause. Don't forget security SLAs, change management and exit clauses.

Are you in the middle of a negotiation, or considering outsourcing your IT management? We're happy to help Dutch SMEs set up or renegotiate an SLA that really works. Explore our managed IT services or call +31 85 303 5869 for a conversation that gives you clarity, not a sales pitch. TRON Group. Moving IT Forward - IT that works, grows and protects.