Of je nu een inkoper van software bent binnen de overheid of het bedrijfsleven, een contractmanager of een softwareleverancier, de kans is groot dat je ooit het woord ‘SLA’ zult horen in de wandelgangen. Geen idee of je collega het had over een krop sla of een document? Of weet je al het een en ander, maar wil je de verdieping in? Dan is deze gids voor jou. We behandelen de basis, maar gaan ook dieper in op de juridische (en praktische) aspecten van Service Level Agreements (SLA’s) voor software. Zo ben je goed voorbereid op alle mogelijke scenario’s en vermijd je de meest voorkomende valkuilen.
Wat is een SLA voor software?
Een SLA is een contract tussen een softwareleverancier en een klant waarin de overeengekomen service levels (prestatieniveaus) zijn vastgelegd die door de softwareleverancier moeten worden geleverd. Best een abstract verhaal, niet waar? Daarom hebben we het toch nog even opgesplitst in drie kernpunten:
1. Een SLA is een contract: het is dus geen vrijblijvend advies of ‘richtlijn’, maar een juridisch bindend document waar partijen zich aan moeten houden.
2. Een SLA heeft betrekking op een softwaredienst (niet op een product): Als klant van een ICT-dienst kan het, zonder SLA, lastig zijn om een bepaalde kwaliteit af te dwingen. Waar beroep je je op als het SaaS-platform voor de zoveelste keer buiten werking is wegens onderhoudswerkzaamheden? Ook als softwareleverancier is het fijn om de verwachtingen van klanten af te bakenen. Zo voorkom je dat die ene klant onrealistische eisen stelt. Een SLA is dus primair een instrument voor het managen van diensten: het beschrijft aan welke kwaliteitseisen de te leveren dienst moet voldoen.
3. In een SLA worden service levels vastgelegd: service levels zijn meetbare prestaties die de softwareleverancier moet leveren en die de kwaliteit van de software-dienst definiëren. Denk hierbij aan uptime-percentages, responstijden bij incidenten, en hoe snel problemen worden opgelost.
Een SLA als bijlage van een raamovereenkomst
Wij zien in de praktijk vaak dat softwareleveranciers ervoor kiezen om hun SLA als bijlage bij de overkoepelende raamovereenkomst op te nemen. Vaak zit er ook nog een verwerkersovereenkomst als bijlage bij. Zo krijgt de klant een ‘pakketje’ aan juridische documenten en hoeft hij niet allerlei afzonderlijke contracten te ondertekenen. Dit is een prima aanpak die vaak ook het meest klantvriendelijk is.
Het is echter wel belangrijk om een bepaalde rangorde in de documenten aan te leggen. Het kan namelijk voorkomen dat een bepaling in de raamovereenkomst tegenstrijdig is met een bepaling in de SLA of de verwerkersovereenkomst. Zo’n rangordebepaling ziet er bijvoorbeeld als volgt uit:
In geval van tegenstrijdigheid of inconsistentie tussen de bepalingen van de verschillende documenten die deel uitmaken van deze overeenkomst, geldt de volgende rangorde:
- Service Level Agreement (SLA): De bepalingen van de SLA hebben voorrang op alle andere documenten, inclusief de verwerkersovereenkomst.
- Verwerkersovereenkomst: Indien de bepalingen in de verwerkersovereenkomst in strijd zijn met die in de SLA, zullen de bepalingen in de verwerkersovereenkomst ondergeschikt zijn aan die in de SLA.
- Raamovereenkomst: De bepalingen van de raamovereenkomst zijn van toepassing voor zover zij niet in strijd zijn met de bepalingen in de SLA of verwerkersovereenkomst.
Door deze volgorde vast te leggen, voorkom je conflicten en is het meteen duidelijk welk document leidend is bij tegenstrijdige bepalingen.
Hoe definieer je ‘beschikbaarheid’ in een SLA?
Misschien wel het belangrijkste service level in een SLA: de beschikbaarheid (ook wel uptime genoemd) van de softwaredienst. Beschikbaarheid wordt meestal uitgedrukt als een percentage van de tijd dat de software beschikbaar moet zijn voor gebruik door klanten. Als klant zijnde wil je natuurlijk dat de beschikbaarheid zo hoog mogelijk is, omdat je vaak (deels) afhankelijk bent van de dienst voor je bedrijfsactiviteiten. Aan de andere kant wil je als softwareleverancier ook wat speling hebben, mocht het een keer misgaan. Omdat de belangen van de klant en softwareleverancier soms best uit elkaar kunnen lopen, behandelen we ze hieronder apart van elkaar:
De klant: Vanuit het oogpunt van de klant is het slim om een resultaatverplichting af te spreken en dus géén inspanningsverplichting. Een inspanningsverplichting is namelijk moeilijk afdwingbaar. Tip: scan de SLA op het woord ‘inspanning’ of ‘inspanningsverplichting’. Staat er zo’n soort clausule in, ga hierover dan in onderhandeling met de softwareleverancier:
“Softwareleverancier streeft ernaar om de SaaS-dienst 24 uur per dag, 7 dagen per week beschikbaar te stellen aan de opdrachtgever. Deze verplichting van Softwareleverancier moet worden beschouwd als een inspanningsverplichting.“
Ook is het belangrijk dat ‘beschikbaarheid’ goed is gedefinieerd in de SLA. Anders wordt het alsnog lastig om je recht te halen. Je kunt je zo voorstellen dat het voor bedrijfskritische software key is om de downtime tot een minimum te beperken. Of stel je eens voor dat je een webshop hebt en deze niet beschikbaar is tijdens Black Friday of kerst – een ramp voor je omzet waarschijnlijk. Daarom is het verstandig om intern goed te bekijken welke beschikbaarheid er voor jullie organisatie of bedrijf noodzakelijk is en of deze eisen duidelijk vast zijn gelegd in de SLA. Een paar extra aandachtspunten om op te letten:
Tip 1. Vaak staat er in een SLA dat onderhoud niet wordt meegerekend in het meten van de downtime/uptime. Als ‘onderhoud’ verder niet gedefinieerd wordt, loop je het risico dat er misbruik van gemaakt wordt. Hierdoor kan de leverancier geplande downtime als ‘onderhoud’ bestempelen, waardoor de daadwerkelijke beschikbaarheid lager is dan beloofd.
Tip 2. Zorg ervoor dat de SLA specifieke tijden vermeldt voor gepland onderhoud, zodat je weet wanneer de dienst mogelijk niet beschikbaar is.
Tip 3. Kijk goed naar de uitzonderingen: zijn er situaties waarin de leverancier niet verantwoordelijk is voor downtime, zoals storingen bij externe providers?
Tip 4. Let op de compensatieregelingen: wat gebeurt er als de beschikbaarheid niet wordt gehaald? Denk aan terugbetalingen, service credits, of verlengingen van de dienst. Zo sta je niet met lege handen als de beloofde uptime niet wordt gehaald.
De softwareleverancier: Vanuit het oogpunt van de softwareleverancier is het vooral belangrijk om een realistische uptime in de SLA vast te leggen. Wat realistisch is, hangt natuurlijk af van het type software, afhankelijkheden van externe providers, enzovoorts. Als onze juristen de vraag krijgen om mee te denken over wat haalbaar is, vragen we altijd eerst aan de softwareleverancier om een overzicht te maken van externe providers waarvan hij, voor het leveren van de softwaredienst, (deels) afhankelijk is en de bijbehorende SLA’s op te sturen. Stel je voor: je hebt een prachtige uptime van 99,9% beloofd aan je klanten, maar een cruciale externe provider kan slechts 95% garanderen. Dat gaat vroeg of laat problemen opleveren.
Ook is het belangrijk om je ‘beschikbaarheid’ af te bakenen. De volgende vragen kunnen je daarbij helpen:
- Wil je de beschikbaarheid per week, per maand of per jaar meten?
- Is het haalbaar om een belofte af te geven aan je klanten (‘je belooft een bepaald resultaat’) of is het verstandiger om een inspanningsverplichting af te spreken (‘je gaat je best doen, maar belooft niets’)?
- Wil je voor de hele softwaredienst één en hetzelfde beschikbaarheidsniveau hanteren, of is het beter om voor elk afzonderlijk onderdeel van je dienst een apart niveau vast te leggen? Een SaaS-oplossing bestaat vaak uit diverse subsystemen die elk hun eigen mankementen kunnen vertonen. Soms is het daarom slimmer om niet voor de gehele SaaS-dienst 99% uptime te beloven, maar de SaaS-dienst op te splitsen in subsystemen en die elk een eigen beschikbaarheidsniveau te geven. Een voorbeeld: de kernfunctionaliteit van je dienst zou een hogere beschikbaarheid kunnen hebben dan minder kritische onderdelen. Dit zorgt ervoor dat je realistische beloftes kunt maken aan je klanten zonder dat je jezelf vastlegt op onhaalbare doelen.
- Wanneer is er volgens jou sprake van downtime? Je kunt hier zo precies in zijn als je wilt. Een voorbeeld van een relatief gedetailleerde downtime-omschrijving is: “Downtime is de totale opgetelde hoeveelheid minuten waarin de dienst niet beschikbaar is. Een minuut telt als downtime als alle opeenvolgende pogingen om geldige handelingen uit te voeren via de API’s in die minuut resulteren in een foutcode of niet leiden tot een succescode.”
Beschikbaarheidspercentages in een SLA monitoren
Wij zien nog te vaak dat softwareleveranciers denken dat ze er met het opstellen van een SLA wel zijn. Vaak verdwijnt de SLA ergens in een map op de computer, en wordt er niet actief gemonitord of de gemaakte afspraken ook daadwerkelijk worden nageleefd. Niet alleen is het niet erg klantvriendelijk of professioneel, maar je loopt ook het risico dat als het een keer goed fout gaat (of je een vervelende klant hebt), je bijvoorbeeld niet kunt aantonen dat de downtime binnen de afgesproken normen valt.
Kans is overigens ook groot dat jouw jurist, bij het opstellen van de SLA, een monitoringsverplichting heeft opgenomen. Doe je dit niet? Dan schend je jouw contractuele verplichtingen en is er waarschijnlijk sprake van wanprestatie.
Je zult dus jouw beschikbaarheidspercentages actief moeten monitoren. Vaak maken softwareleveranciers daarvoor gebruik van gespecialiseerde monitoringstools die continu de beschikbaarheid van hun systemen controleren. Zo’n tool genereert dan een melding zodra een storing wordt ontdekt.
Reactie- en responstijden in een SLA
De tijd die het duurt om een eerste antwoord te geven aan de klant, wordt ook wel de ‘reactietijd’ genoemd. De responstijd is de tijd die verstrijkt tussen het moment dat een klant een probleem meldt en het moment dat het probleem daadwerkelijk is opgelost. Het zijn belangrijke service levels in een SLA, omdat ze de verwachtingen van de klant helder stellen en zorgen voor een duidelijke meetlat voor de geboden service.
Als softwareleverancier is het vooral belangrijk om realistische reactie- en responstijden vast te leggen in je SLA. Je wilt natuurlijk dat je klanten zich gehoord voelen, maar je wilt ook voorkomen dat je team onder onnodige druk komt te staan of dat je beloftes maakt die je niet kunt waarmaken. ‘Underpromise, overdeliver’ is een wijsheid die we ter harte nemen.
We geven je alvast een paar tips voor het bepalen van realistische reactie- en responstijden:
- Analyseer het verleden: kijk naar eerdere prestaties en gemiddelde reactietijden. Dit geeft je een goed beeld van wat je team aankan zonder overbelasting.
- Communiceer duidelijk met je team: Zorg ervoor dat je team weet wat er van hen verwacht wordt en betrek hen bij het opstellen van de SLA. Hun input is cruciaal voor het bepalen van haalbare doelen.
- Houd rekening met verschillende scenario’s: Niet elk probleem is even urgent. Stel verschillende niveaus van prioriteit in en bepaal voor elk niveau passende reactietijden en responstijden.
- Blijf flexibel en pas aan: Monitor de prestaties regelmatig en wees bereid om de SLA aan te passen als blijkt dat de gestelde tijden niet haalbaar zijn of juist te ruim bemeten zijn.
Bij het opstellen van een SLA is het bovendien belangrijk om de responstijd duidelijk te definiëren. Met andere woorden, wanneer wordt een probleem als opgelost beschouwd? Is een probleem pas opgelost wanneer de klant tevreden is? Of wordt de responstijd gemeten aan, bijvoorbeeld, de tijd die de respectieve API nodig heeft om te reageren op een oproep? Je kunt je zo voorstellen dat er een aanzienlijk verschil kan zijn tussen het moment waarop een API reageert en het moment waarop een klant daadwerkelijk tevreden is met de oplossing.
Communiceren en rapporteren over service levels
Communiceren en rapporteren over service levels is een cruciaal onderdeel binnen een SLA. Als klant heb je er belang bij dat de softwareleverancier transparant is over het (wel of niet) behalen van de afgesproken service levels. Zo kun je controleren of de service levels worden gehaald, behoud je zeggenschap en kun je de softwareleverancier erop wijzen als er afwijkingen zijn.
Voor de softwareleverancier is het slim om een realistische rapportage-clausule op te nemen in de SLA. Het is waarschijnlijk niet heel praktisch om iedere klant, elke week, een gedetailleerd handgeschreven rapport toe te sturen via de mail. Misschien is het daarentegen praktischer om af te spreken dat rapporten beschikbaar zijn op uitdrukkelijk verzoek.
SLA: een aantal voorbeelden
Hieronder vind je enkele voorbeeldbepalingen die vaak voorkomen in een SLA voor software. De specifieke details hangen natuurlijk af van jouw bedrijfssituatie en zijn daarom altijd maatwerk.
Reactie- en responstijden (voorbeeld):
Met deze SLA heeft u recht op de volgende reactie- en responstijden:
| Reactie- en responstijden | Prioriteit Laag | Prioriteit Medium | Prioriteit Hoog |
|---|---|---|---|
| Bevestiging van aanmelding | < 1,5 uur na aanmelding | < 1,5 uur na aanmelding | < 1,5 uur na aanmelding |
| 1ste respons | < 10 uur na aanmelding | < 9 uur na aanmelding | < 8 uur na aanmelding |
| 1ste update | < 16 uur na 1ste respons | < 8 uur na 1ste respons | <2 uur na 1ste respons |
| Op locatie | Volgens afspraak | Volgens afspraak | < 4 uur indien remote inloggen geen oplossing biedt |
| Resultaat | Een (tijdelijke) oplossing binnen 4 kalenderdagen na aanmelding | Probleem prioriteit naar ‘laag’ binnen 3 kalenderdagen na aanmelding | Probleem prioriteit minimaal naar ‘medium’ binnen 8 uur na aanmelding |
Classificatie van incidenten (voorbeeld):
Gerapporteerde incidenten worden eerst geclassificeerd op basis van de informatie van de klant. Indien nodig start ons support team een onderzoek om ze te classificeren in een van de onderstaande categorieën. De ernst van een incident wordt bepaald door het support team. Over het algemeen worden gerapporteerde incidenten geclassificeerd in een van de volgende typen:
| Gewicht | Incidenttypes |
|---|---|
| 0 | Geen incidenten |
| 1 | Kleine incidenten |
| 2 | Grote incidenten |
| 3 | Kritieke incidenten |
Voor de classificatie van incidenten, hanteren we de volgende regels:
| Subsysteem | Klein | Groot | Kritiek |
|---|---|---|---|
| CMS | Een aantal functionaliteiten in het CMS functioneren niet correct, maar er is een alternatieve oplossing beschikbaar. | Een aantal functionaliteiten in het CMS werkt niet goed, zonder alternatieve oplossing. | Het CMS is niet operationeel, waardoor niemand ermee kan werken. |
| Gebruikersbeheer | Gebruikers kunnen niet inloggen, maar er is een alternatieve manier om in te loggen beschikbaar. | Gebruikers kunnen niet inloggen en er is geen alternatieve manier om in te loggen beschikbaar. | Gebruikers kunnen niet inloggen, waardoor niemand toegang heeft tot het systeem. |
| Dataopslag | Toegang tot bepaalde data is beperkt, maar er is een workaround beschikbaar. | Toegang tot bepaalde data is beperkt en er is geen workaround beschikbaar. | Toegang tot alle data is verloren gegaan, waardoor het systeem niet bruikbaar is. |
| Admin Portal | Een belangrijke functie werkt niet, waardoor nieuwe gebruikers niet kunnen worden aangemaakt én er is een workaround beschikbaar. | Een belangrijke functie werkt niet, waardoor nieuwe gebruikers niet kunnen worden aangemaakt én er is geen workaround beschikbaar. | Het Admin Portal is niet beschikbaar, waardoor niemand er mee kan werken. |
Beschikbaarheidspercentage (voorbeeld):
Het beschikbaarheidspercentage van de dienst wordt berekend als volgt:
Beschikbaarheidspercentage = ((Maximaal beschikbare minuten – Downtime) / Maximaal beschikbare minuten) × 100
Het beschikbaarheidspercentage wordt maandelijks berekend op basis van de bovenstaande formule. Downtime wordt gemeten in minuten en omvat alle periodes waarin de dienst niet beschikbaar is vanwege gepland onderhoud, storingen of andere gebeurtenissen die buiten de controle van de dienstverlener vallen.
Jouw SLA laten opstellen door onze ICT-juristen?
Onze ICT-juristen zijn gespecialiseerd in het ICT-recht en zorgen ervoor dat jouw SLA juridisch waterdicht en op maat gemaakt is. Met hun expertise ben je verzekerd van duidelijke afspraken en optimale bescherming voor jouw bedrijf.
Neem gerust contact met ons op voor een vrijblijvende intake.
