Een SLA IT-beheer bepaalt zwart op wit wat je van een IT-partner mag verwachten, welke prestaties meetbaar zijn en wat er gebeurt als die prestaties uitblijven. Zonder duidelijke afspraken ontstaan discussies over storingen, reactietijden, prioriteiten en verantwoordelijkheden. Met een goede SLA voorkom je dat “beheer” een vaag begrip blijft en maak je van verwachtingen concrete service-afspraken.
Voor veel organisaties is een SLA meer dan een bijlage bij een contract. Het is het praktische stuurmiddel tussen directie, interne IT-contactpersonen en externe beheerpartij. Zeker bij uitbestede werkplekken, servers, Microsoft 365, netwerkbeheer of servicedesk-ondersteuning geeft een service level agreement IT houvast. Wie zich breder oriënteert op uitbesteding, vindt extra context in IT-beheer uitbesteden: kosten, voordelen en aandachtspunten.
SLA IT-beheer: de kern van goede beheerafspraken
Een SLA beschrijft meetbare serviceniveaus binnen een beheercontract IT. Denk aan:
- Welke systemen en diensten onder beheer vallen
- Op welke tijden support beschikbaar is
- Welke responstijden IT-beheer gelden per type melding
- Welke oplostijden worden nagestreefd of gegarandeerd
- Hoe beschikbaarheid IT wordt gemeten
- Welke taken bij de klant blijven liggen
- Hoe escalatie en rapportage verlopen
Het verschil tussen een contract en een SLA is praktisch belangrijk. Het contract regelt meestal juridische en commerciële zaken, zoals looptijd, tarieven, aansprakelijkheid en opzegging. De SLA vertaalt dat naar dagelijkse uitvoering. Juist daar gaat het vaak mis als afspraken te algemeen zijn geformuleerd.
Wat moet er minimaal in een service level agreement IT staan?
Een bruikbare SLA bevat minimaal zeven onderdelen. Ontbreekt een van deze punten, dan wordt handhaving lastig.
1. Scope van het IT-beheer
Beschrijf exact welke onderdelen onder de SLA vallen. Bijvoorbeeld:
- Werkplekbeheer voor 85 laptops en 20 vaste werkstations
- Beheer van Microsoft 365, Entra ID en Exchange Online
- Netwerkbeheer voor firewall, switches en wifi
- Serverbeheer voor 3 virtuele Windows-servers
- Back-upcontrole en hersteltests
Neem ook expliciet op wat niet binnen de scope valt. Bijvoorbeeld softwareontwikkeling, gebruikersadoptie, hardwarevervanging of ondersteuning van privéapparaten. Juist die afbakening voorkomt onduidelijkheid.
2. Servicetijden en bereikbaarheid
IT-support afspraken zijn pas bruikbaar als je weet wanneer support beschikbaar is. Veelgebruikte modellen zijn:
- Kantooruren: maandag tot en met vrijdag van 08:30 tot 17:30
- Verlengde support: 07:00 tot 22:00
- 24/7 voor kritieke infrastructuur
Leg ook vast via welke kanalen meldingen binnenkomen: portaal, e-mail en telefoon. Voor kritieke incidenten is een telefoonnummer vrijwel onmisbaar.
3. Prioriteiten van incidenten
Niet elke storing is even urgent. Werk daarom met een prioriteitenmatrix. Een praktisch voorbeeld:
- P1 kritiek: volledige uitval van bedrijfsbrede systemen, geen workaround
- P2 hoog: belangrijke functie werkt niet voor meerdere gebruikers
- P3 middel: verstoring voor één gebruiker of beperkte workaround beschikbaar
- P4 laag: serviceverzoek, wijziging of niet-kritieke vraag
Definieer per prioriteit wie de urgentie bepaalt. Idealiter stelt de leverancier de prioriteit vast op basis van vooraf afgesproken criteria, niet alleen op basis van beleving van de melder.
4. Responstijden en oplostijden
Responstijden IT-beheer zijn een van de meest besproken onderdelen van een SLA. Maak onderscheid tussen een eerste reactie en een daadwerkelijke oplossing. Een leverancier kan immers snel reageren, maar alsnog te laat oplossen.
Een realistisch voorbeeld van IT-support afspraken:
- P1: reactie binnen 15 minuten, start werkzaamheden direct, tijdelijke workaround binnen 4 uur
- P2: reactie binnen 30 minuten, oplossing of workaround binnen 8 werkuren
- P3: reactie binnen 4 werkuren, oplossing binnen 2 werkdagen
- P4: reactie binnen 1 werkdag, afhandeling binnen 5 werkdagen
Let op nuance: een harde oplostijd is niet altijd haalbaar als een softwareleverancier of hardwarefabrikant afhankelijkheden veroorzaakt. In zulke gevallen is een inspanningsverplichting met duidelijke escalatie vaak realistischer dan een absolute garantie.
5. Beschikbaarheid van systemen
Beschikbaarheid IT moet meetbaar zijn. Schrijf dus niet “hoge beschikbaarheid”, maar bijvoorbeeld “99,9% per kalendermaand” voor een specifieke dienst. Dat lijkt een klein verschil, maar het betekent concreet iets:
- 99,5% beschikbaarheid = ongeveer 3 uur en 39 minuten uitval per maand
- 99,9% beschikbaarheid = ongeveer 43 minuten uitval per maand
- 99,95% beschikbaarheid = ongeveer 22 minuten uitval per maand
Neem erbij op:
- Welke meetmethode wordt gebruikt
- Of gepland onderhoud buiten de berekening valt
- Welke systemen bedrijfskritisch zijn
- Vanaf welk punt een storing telt als onbeschikbaarheid
Voor definities van uptime en service commitments kan documentatie van cloudleveranciers nuttig zijn, zoals de uitleg van Microsoft over service level agreements op Microsoft Learn.
6. Rollen en verantwoordelijkheden
Een SLA werkt alleen als beide partijen taken hebben. Leg daarom vast:
- Wie changes mag aanvragen
- Wie contactpersoon is bij escalaties
- Wie gebruikers toevoegt of verwijdert
- Wie verantwoordelijk is voor licenties
- Wie goedkeuring geeft op onderhoud buiten kantooruren
Een klassiek knelpunt: de beheerpartij is verantwoordelijk voor patching, maar de klant levert geen onderhoudsvenster of testprocedure aan. Dan ontstaat vertraging zonder dat één partij volledig schuld heeft. Dat moet je vooraf ondervangen.
7. Rapportage, evaluatie en sancties
Vraag om maand- of kwartaalrapportages met ten minste:
- Aantal meldingen per prioriteit
- Gemiddelde en gerealiseerde responstijden
- Overschrijdingen van SLA-afspraken
- Beschikbaarheid IT per systeem of dienst
- Openstaande problemen en structurele verbeteracties
Voeg ook een afspraak toe over service credits of herstelmaatregelen bij structurele afwijkingen. In de praktijk zijn service credits vaak beperkt, bijvoorbeeld 5% tot 10% van de maandelijkse beheervergoeding voor specifieke overschrijdingen. Dat compenseert de schade zelden volledig, maar het geeft wel prikkel tot naleving.
Veelgemaakte fouten in een beheercontract IT
Veel SLA’s zien er professioneel uit, maar zijn inhoudelijk te vaag. Dit zijn de meest voorkomende fouten:
- Te brede formuleringen. “Snelle support” is niet meetbaar.
- Geen onderscheid tussen incidenten en verzoeken. Een wachtwoordreset is iets anders dan een serverstoring.
- Geen meetmethode. Zonder meetregels ontstaat discussie over prestaties.
- Geen uitzonderingen benoemd. Gepland onderhoud, afhankelijkheden van derden en force majeure horen beschreven te zijn.
- Onrealistische garanties. 100% uptime klinkt aantrekkelijk, maar is meestal niet geloofwaardig.
- Geen klantverantwoordelijkheden. Dan wordt elke vertraging automatisch bij de leverancier neergelegd.
Hoe bepaal je passende responstijden IT-beheer?
Goede responstijden IT-beheer hangen af van bedrijfsimpact, niet van gevoel. Stel daarom drie vragen:
- Welke processen mogen niet stilvallen?
- Hoeveel gebruikers worden geraakt bij uitval?
- Is er een werkbare tijdelijke oplossing?
Voor een accountantskantoor in de btw-aangifteperiode kan uitval van het dossier- of boekhoudsysteem direct kritisch zijn. Voor een intern printprobleem geldt dat meestal niet. Een productiebedrijf met 24/7 operatie heeft vaak strengere eisen dan een zakelijke dienstverlener die alleen tijdens kantooruren werkt.
Praktisch gezien zie je vaak drie serviceniveaus:
- Basis: support tijdens kantooruren, reactie binnen 4 tot 8 werkuren
- Uitgebreid: snellere reactietijden, proactieve monitoring, periodieke rapportage
- Kritiek: 24/7 bereikbaarheid, strakke escalatie, hoge beschikbaarheidseisen
Hoe hoger het serviceniveau, hoe hoger meestal de prijs. Bij een beheercontract IT is het daarom slim om alleen voor echt kritieke onderdelen zware SLA-eisen te stellen.
Welke KPI’s maken een SLA echt bruikbaar?
Naast responstijden en beschikbaarheid zijn er meer KPI’s die waarde toevoegen:
- First time fix-percentage: hoeveel meldingen in één keer worden opgelost
- Mean time to resolve: gemiddelde oplostijd per prioriteit
- Patchcompliance: percentage systemen met actuele beveiligingsupdates
- Back-upsucces: percentage geslaagde back-ups en periodieke restore-tests
- Escalatiegraad: hoeveel incidenten moeten worden doorgeschoven
Niet elke KPI hoort in elke SLA. Voor een kleine organisatie met 25 werkplekken is een compacte set vaak beter dan een dashboard vol cijfers waar niemand op stuurt.
Wanneer moet je een SLA voor IT-beheer aanpassen?
Een SLA is geen statisch document. Herziening is logisch bij:
- Groei van het aantal gebruikers of locaties
- Overstap naar cloud- of hybride infrastructuur
- Nieuwe compliance-eisen
- Overname, fusie of reorganisatie
- Structurele overschrijding van afgesproken servicelevels
Plan daarom minimaal één formeel evaluatiemoment per jaar. Niet om alles te herschrijven, wel om te toetsen of de afspraken nog passen bij de bedrijfsvoering.
Veelgestelde vragen
Wat is het verschil tussen een SLA en een beheercontract IT?
Een beheercontract IT regelt de commerciële en juridische basis, zoals prijs, looptijd en aansprakelijkheid. De SLA beschrijft de operationele prestatie-afspraken, zoals supporturen, responstijden IT-beheer en beschikbaarheid IT.
Welke beschikbaarheid IT is realistisch voor mkb-organisaties?
Dat hangt af van de kritikaliteit van de dienst. Voor standaard werkplekdiensten is 99,5% of 99,9% vaak werkbaar. Voor productie- of klantkritische systemen kan een hogere eis nodig zijn, maar alleen als de onderliggende infrastructuur daar ook op is ingericht.
Moet een SLA ook oplostijden garanderen?
Bij voorkeur wel, maar niet altijd als harde garantie. Voor incidenten waarbij derden betrokken zijn, zoals internetproviders of softwareleveranciers, is een combinatie van responstijd, escalatieprocedure en streef-oplostijd vaak realistischer.
Zijn service credits zinvol bij het niet halen van de SLA?
Ja, mits ze duidelijk zijn omschreven. Service credits vergoeden de werkelijke schade meestal niet volledig, maar ze maken prestaties wel afdwingbaarder en geven een financiële prikkel om afspraken na te komen.
Hoe gedetailleerd moeten IT-support afspraken zijn?
Gedetailleerd genoeg om meetbaar te zijn, maar niet zo uitgebreid dat niemand ze nog gebruikt. Een goede vuistregel: als twee partijen dezelfde zin anders kunnen uitleggen, is de afspraak nog niet scherp genoeg.
