Stel: je tekent een contract voor IT-support. Er staat een mooie SLA in — een Service Level Agreement.
▶Inhoudsopgave
- Wat is een SLA eigenlijk — in gewoon Nederlands?
- Begin met wat echt ertoe doen
- Schrijf in actieve taal — niet passief
- Gebruik concrete cijfers — maar leg ze uit
- Maak duidelijk wat “ernstig” betekent
- Zeg ook wat je niet doet
- Gebruik voorbeelden en scenario’s
- Houd het kort — en maak het scanbaar
- Laat het testen door echte eindgebruikers
- Een SLA is geen document — het is een belofte
Maar als je die voorleest aan iemand die geen IT’er is, krijg je alleen maar knikken uit beleefde onwetendheid. Geen idee wat er echt staat. Geen idee wat ze kunnen verwachten.
En zeker geen idee wat er gebeurt als dingen misgaan. Dat is precies het probleem met de meeste SLA’s: ze zijn geschreven voor juristen en technici, niet voor de mensen die er dagelijks mee werken.
Maar een SLA moet juist duidelijk zijn voor iedereen — van de helpdeskmedewerker tot de eindgebruiker achter zijn scherm. Anders is het gewoon papier. In dit artikel laat ik zien hoe je een SLA schrijpt die écht begrijpen is.
Geen jargon, geen juridisch woordenboek nodig. Gewoon helder, eerlijk en bruikbaar.
Wat is een SLA eigenlijk — in gewoon Nederlands?
Een SLA is simpel gezegd een afspraak over kwaliteit van service. Het zegt: “Wij beloven dit, en jij mag dit verwachten.” Denk aan een restaurant dat belooft dat je eten binnen 15 minuten op tafel staat.
Als dat niet gebeurt, heb je recht op iets — misschien een gratis drankje of korting. In IT-termen gaat het vaak om dingen als: Maar zolang die afspraken alleen staan in technische taal of vage percentages, begrijpt niemand er iets van. En dan werkt het niet.
- Hoe snel wordt gereageerd op een melding?
- Hoe lang mag een storing duren?
- Wat als het niet lukt binnen die tijd?
Begin met wat echt ertoe doen
Voordat je begint met schrijven, stel jezelf deze vraag: Wat wil de eindgebruiker weten? Niet wat jij wilt zeggen.
Niet wat je juridisch moet dekken. Maar wat heeft zij of hij nodig om gerust te zijn?
Meestal zijn dat drie dingen: Alles wat daarbuiten staat, is vaak ruis. En ruis verwart.
- Hoe snel krijg ik hulp?
- Hoe lang mag het duren voordat het is opgelost?
- Wat als het niet goed gaat?
Schrijf in actieve taal — niet passief
Kijk naar deze twee zinnen: De eerste zin is vaag en passief.
“Er zal worden gestreefd naar een reactietijd van maximaal 4 uur.”
“Wij reageren binnen 4 uur na ontvangst van je melding.”
De twee is duidelijk en verantwoordelijk. Gebruik altijd actieve werkwoorden: “wij doen”, “wij lossen op”, “wij informeren”. Zo weet de lezer wie wat doet — en wie hij kan bellen als het misgaat.
Gebruik concrete cijfers — maar leg ze uit
Ja, cijfers zijn belangrijk. Maar alleen als mensen begrijpen wat ze betekenen.
Bijvoorbeeld: “99,9% uptime” klinkt indrukwekkend. Maar wat betekent dat echt? Leg het uit:
Zo maak je abstracte begrippen tastbaar. En dat bouwt vertrouwen op.
“99,9% uptime betekent dat je systeem maximaal 8,7 uur per jaar onbereikbaar mag zijn. Dat is minder dan 1 dag per jaar.”
Maak duidelijk wat “ernstig” betekent
Veel SLA’s gebruiken termen als “kritieke storing” of “prioriteit 1”. Maar wat is dat voor de gebruiker? Definieer elk niveau in gewone taal: Zodra mensen weten wat ze mogen verwachten, voelen ze zich geholpen — niet gefrustreerd.
- P1 – Kritiek: Het systeem werkt helemaal niet. Niemand kan werken. Wij lossen het binnen 2 uur op.
- P2 – Hoog: Een belangrijk onderdeel werkt niet goed. Wij lossen het binnen 4 uur op.
- P3 – Normaal: Iets werkt niet optimaar, maar je kunt wel doorwerken. Wij pakken het binnen 1 werkdag.
Zeg ook wat je niet doet
Een goede SLA is ook eerlijk over grenzen. Want niets is erger dan valse verwachtingen.
Zeg bijvoorbeeld: Of: Zo voorkom je discussies later. En dat is juist professioneel.
“Wij bieden geen ondersteuning voor software van derden, tenzij dit expliciet in onze overeenkomst staat.”
“Onze SLA geldt alleen tijdens kantooruren: maandag tot en met vrijdag, van 8:00 tot 18:00 uur.”Gebruik voorbeelden en scenario’s
Mensen onthouden verhalen beter dan regels. Dus geef voorbeelden. Bijvoorbeeld: Zodra iemand zich dat kan voorstellen, wordt de SLA levend.
“Stel: je kunt niet inloggen op je e-mail om 10:00 uur. Je meldt het bij ons. Wij bevestigen je melding binnen 15 minuten. Als het een P1-storing is, lossen we het binnen 2 uur op.”Houd het kort — en maak het scanbaar
Geen mens leest een hele SLA van begin tot eind. Dus maak het makkelijk om snel te scannen.
Gebruik: En als je echt wilt dat mensen het lezen: voeg een “TL;DR”-sectie toe. Ja, serieus. Zeg gewoon: “In het kort: wij beloven X, Y en Z. Als we dat niet halen, dan krijg je A, B of C.”
- Kopjes per onderwerp
- Opsommingstekens
- Vetgedrukte kernbegrippen
- Een samenvatting bovenaan
Laat het testen door echte eindgebruikers
Voordat je de SLA definitief maakt, laat hem dan lezen door iemand die niet in IT werkt, of gebruik hem als basis voor je interne helpdesk handboek.
Een collega uit HR. Je buurman. Je oma. Vraag: “Begrijp je wat hier staat? Wat zou jij verwachten als je dit leest?” Als ze het kunnen uitleggen in hun eigen woorden, dan werkt het. Dan heb je iets gemaakt dat écht duidelijk is en past bij de manier waarop je een kennisbank opbouwt die je helpdesk team écht gebruikt.
Een SLA is geen document — het is een belofte
Uiteindelijk draait het om vertrouwen. Een SLA is geen juridisch hulpmiddel om jezelf te beschermen, maar een essentieel onderdeel van een goed ticketsysteem governance model.
Het is een belofte aan je gebruikers: “Wij nemen je serieus. En hier staat precies wat je van ons kunt verwachten.”
Schrijf het alsof je het tegen een vriend zou zeggen. Heldere taal. Eerlijke afspraken. Geen excuses. Want als je dat doet, dan lezen mensen het écht. En dan werkt het.