Wat is een SLA? Uitleg en voorbeeld voor IT-dienstverleners

Een SLA (Service Level Agreement) is de afspraak tussen jou en je klant over reactietijd, oplostijd en beschikbaarheid. Voor IT-bureaus is het dé basis onder support: zonder SLA is ‘zo snel mogelijk’ de norm — en dat is voor niemand meetbaar. Een goede SLA beschermt twee kanten op: je klant weet waar hij aan toe is, en jij kunt nee zeggen tegen ‘alles is spoed’ zonder dat het persoonlijk wordt.

Wat staat er minimaal in

• Reactietijd per prioriteit — hoe snel iemand van jouw team inhoudelijk reageert, per urgentieniveau. Bijvoorbeeld: kritiek binnen 1 uur, laag binnen 2 werkdagen.
• Oplostijd of werkwijze — wat er ná de eerste reactie gebeurt: een streeftijd voor de oplossing, of een vaste escalatieroute als die tijd niet haalbaar blijkt.
• Openingstijden en dekking — kantooruren of 24/7, en wat er gebeurt met een melding die om 23:00 binnenkomt. Loopt de klok dan door, of start hij de volgende ochtend?
• Wat er buiten valt — nieuwe features, wijzigingsverzoeken en problemen in systemen die jij niet beheert horen niet onder de SLA, maar in een apart contract.

Voorbeeld: een werkbare SLA voor een IT-bureau

Onderstaande matrix is een startpunt dat voor de meeste bureaus met 5–50 medewerkers goed werkt. De tijden gaan uit van kantooruren (ma–vr, 08:30–17:30); buiten die uren pauzeert de klok.

Prioriteit	Voorbeeld	Reactietijd	Oplostijd
Kritiek	Productie ligt eruit, niemand kan werken	1 uur	4 kantooruren
Hoog	Belangrijke functie stuk, omweg beschikbaar	4 uur	1 werkdag
Normaal	Eén gebruiker of niet-kritiek proces geraakt	1 werkdag	3 werkdagen
Laag	Vraag, cosmetisch issue of klein ongemak	2 werkdagen	in overleg

Twee dingen maken deze opzet werkbaar. Ten eerste: de reactietijd is een harde afspraak, de oplostijd een streeftijd met een escalatieroute — je kunt niet beloven dat elke storing binnen vier uur opgelost is, wél dat er dan iemand aantoonbaar mee bezig is en de klant een tussenstand krijgt. Ten tweede: de prioriteit wordt bepaald door impact, niet door wie het hardst belt. Leg de voorbeelden per niveau daarom net zo expliciet vast als de tijden zelf, en richt je ticketstatussen zo in dat ‘wachten op klant’ een eigen kolom op het kanbanbord is — zo zie je meteen bij wie de bal ligt.

Veelgemaakte fouten

• Alles is prioriteit 1. Zonder duidelijke impact-criteria wordt elke melding ‘kritiek’ en is je matrix waardeloos. De voorbeeldkolom hierboven is daarom geen decoratie, maar het belangrijkste deel van de afspraak.
• 24/7 beloven zonder 24/7-bezetting. Een dekking die je niet waarmaakt is slechter dan kantooruren die je wél haalt. Begin krap en breid uit als de klant er echt voor wil betalen.
• De SLA belandt in een la. Een afspraak die niemand meet, bestaat niet. Als deadlines niet per ticket zichtbaar zijn, merk je een overschrijding pas als de klant boos belt.
• Geen afspraak over wat erbuiten valt. Zonder die grens wordt elk wijzigingsverzoek een ‘storing’ — en betaal jij het verschil.

SLA-afspraken waarmaken in de praktijk

Een SLA opstellen is één middag werk; hem waarmaken is een kwestie van inrichting. In Plugzy komen klantvragen als tickets binnen op het kanbanbord, met prioriteit en status die je klant zelf volgt in het klantenportaal — zo zie je in één oogopslag wat aandacht nodig heeft. Hoe je je bord daarvoor inricht, lees je in Ticketstatussen en workflows instellen.