Een storing in uw boekhoudpakket op maandagochtend, een medewerker die niet kan inloggen of een verdachte e-mail die mogelijk tot datalek leidt: dan wilt u niet discussiëren over wat uw ICT-leverancier precies beloofd heeft. Goede SLA afspraken geven duidelijkheid op het moment dat die het hardst nodig is. Deze SLA afspraken uitleg helpt mkb-bedrijven om technische beloftes te vertalen naar afspraken die de bedrijfscontinuïteit daadwerkelijk beschermen.

Een SLA is geen standaardbijlage die u alleen ondertekent omdat deze bij een offerte hoort. Het is een praktisch stuurmiddel. De inhoud bepaalt welke dienstverlening u krijgt, hoe snel problemen worden opgepakt, wie welke rol heeft en wat er gebeurt wanneer prestaties achterblijven.

Wat zijn SLA afspraken precies?

SLA staat voor Service Level Agreement. In dit document legt u met een ICT-leverancier meetbare afspraken vast over de dienstverlening. Denk aan bereikbaarheid van de servicedesk, reactietijden bij incidenten, onderhoud, back-ups, beveiligingsupdates en rapportages.

De nadruk ligt op meetbaar. Een formulering als „de leverancier lost storingen zo snel mogelijk op” klinkt geruststellend, maar biedt weinig houvast. Wat is snel? Geldt dit ook buiten kantooruren? Is een tijdelijke oplossing voldoende, of moet de oorzaak definitief zijn verholpen? Zonder concrete definities kunnen leverancier en klant een heel ander beeld hebben van dezelfde verplichting.

Een bruikbare SLA sluit daarom aan op uw bedrijfsprocessen. Een productiebedrijf dat digitaal plant, heeft andere eisen dan een advieskantoor waar e-mail en klantdossiers cruciaal zijn. Ook binnen één organisatie verschillen belangen: een storing in de wifi voor gasten is vervelend, maar een onbereikbare cloudomgeving voor alle medewerkers kan de bedrijfsvoering stilleggen.

SLA afspraken uitleg: kijk eerst naar bedrijfsrisico

De meest gemaakte fout is beginnen met het SLA-format van de leverancier. Dat format is meestal gebaseerd op diens werkwijze en capaciteit. Het kan prima zijn, maar is niet automatisch passend bij uw risico’s.

Begin daarom met de vraag: welke processen mogen niet uitvallen, welke gegevens vragen extra bescherming en hoeveel uitval is financieel of operationeel acceptabel? Pas daarna bepaalt u welk serviceniveau nodig is. Zo voorkomt u dat u betaalt voor 24/7-bereikbaarheid terwijl dit niet nodig is, maar ook dat u met een goedkoop contract ontdekt dat kritieke ondersteuning alleen tijdens kantooruren beschikbaar is.

Maak onderscheid tussen incidenten, serviceverzoeken en structurele problemen. Een incident is een verstoring, zoals een server die niet bereikbaar is. Een serviceverzoek is bijvoorbeeld een nieuw gebruikersaccount of laptop. Een structureel probleem vraagt om oorzaakanalyse, bijvoorbeeld wanneer dezelfde storing steeds terugkomt. Voor elk type werk kunnen andere termijnen en verwachtingen gelden.

Prioriteiten bepalen bij storingen

Prioriteiten zijn de kern van veel SLA’s. Vaak worden ze aangeduid als P1 tot en met P4, maar de labels zijn minder belangrijk dan de omschrijving. Leg vast wanneer een storing als kritiek geldt en wie die classificatie bepaalt.

Een P1-situatie kan bijvoorbeeld zijn dat alle medewerkers niet bij essentiële systemen kunnen, dat bedrijfsgegevens mogelijk zijn gelekt of dat een cruciale productielijn stilstaat. Bij een P2-storing werkt een belangrijk proces beperkt, maar is een tijdelijke werkwijze mogelijk. Kleinere individuele problemen vallen vaak in een lagere categorie.

Let op het verschil tussen reactietijd en oplostijd. Reactietijd is de periode totdat een leverancier de melding bevestigt en ermee start. Oplostijd is de periode totdat de dienst weer volgens afspraak werkt. Een leverancier kan dus binnen vijftien minuten reageren, maar pas de volgende werkdag herstellen. Dat hoeft niet verkeerd te zijn, zolang het past bij de impact op uw organisatie.

Leg ook vast of de klok buiten werktijden doorloopt. Een afspraak van vier uur betekent iets anders bij een 8×5-servicemodel dan bij een 24×7-model. Voor een webshop, zorggerelateerde dienstverlening of een bedrijf met ploegendiensten kan dat verschil doorslaggevend zijn.

Welke onderdelen mogen niet ontbreken?

Een SLA hoeft niet onnodig juridisch of technisch ingewikkeld te zijn. Wel moet het document antwoord geven op de vragen die ontstaan tijdens een storing, beveiligingsincident of meningsverschil. De volgende onderdelen verdienen altijd aandacht:

• De exacte diensten en systemen waarop de SLA van toepassing is, inclusief uitzonderingen.
• Bereikbaarheid, openingstijden en escalatiecontacten bij urgente situaties.
• Prioriteitsniveaus met reactietijden, hersteltijden en communicatieafspraken.
• Taken van leverancier én klant, zoals toegangsbeheer, meldprocedures en medewerking bij onderzoek.
• Rapportage, evaluatiemomenten, consequenties bij onderprestatie en een procedure voor wijziging.

Vooral de afbakening is belangrijk. Staat cloudback-up wel in het contract, maar herstel van bestanden niet? Is Microsoft 365-beheer inbegrepen, maar ondersteuning voor een specifieke bedrijfsapplicatie uitgesloten? Dan wordt de grens pas zichtbaar wanneer er druk op de ketel staat.

Beschikbaarheid is meer dan een percentage

Veel SLA’s noemen een beschikbaarheidspercentage, bijvoorbeeld 99,9 procent. Dat lijkt hoog, maar zonder context zegt het weinig. Bij een maand van dertig dagen betekent 99,9 procent beschikbaarheid nog steeds ruim 43 minuten uitval. Bij 99,5 procent loopt dit op tot meer dan drieënhalf uur.

Vraag daarom hoe beschikbaarheid wordt gemeten. Telt gepland onderhoud mee? Geldt het percentage voor de gehele dienst of alleen voor de infrastructuur van de leverancier? En wat gebeurt er als een externe cloudpartij uitvalt? Uw leverancier kan niet altijd alles zelf oplossen, maar moet wel duidelijk maken welke regie hij voert en hoe hij communiceert.

Beschikbaarheid alleen is bovendien geen garantie voor bruikbaarheid. Een systeem kan technisch online zijn, terwijl medewerkers niet kunnen werken door trage verbindingen, foutmeldingen of ontbrekende rechten. Combineer beschikbaarheidsafspraken daarom met heldere prestatie- en herstelafspraken.

Verdeel verantwoordelijkheden zonder grijs gebied

Een SLA werkt alleen als beide partijen weten wat zij moeten doen. De leverancier kan een incident moeilijk oplossen als contactpersonen ontbreken, toegang niet is geregeld of meldingen via losse WhatsApp-berichten binnenkomen. Andersom mag een leverancier niet verwachten dat een mkb-ondernemer technische keuzes maakt zonder begrijpelijke uitleg over risico’s en gevolgen.

Leg vast wie incidenten mag melden, hoe een melding wordt geregistreerd en wie beslissingen neemt bij een beveiligingsincident. Neem ook de verantwoordelijkheden rond cybersecurity mee. Wie installeert updates? Wie bewaakt back-ups? Wie controleert afwijkende inlogpogingen? Wie beoordeelt of en wanneer betrokkenen of toezichthouders moeten worden geïnformeerd bij een datalek?

Bij uitbestede ICT is ketenregie extra relevant. Uw vaste ICT-partij kan afhankelijk zijn van internetproviders, softwareleveranciers en cloudplatforms. Een goede SLA benoemt die afhankelijkheden, zonder dat de leverancier zich achter iedere derde partij kan verschuilen. U wilt weten wie eigenaar blijft van de communicatie, coördinatie en opvolging.

Controleer de SLA in de praktijk

Een ondertekend document is het begin, niet het eindpunt. Vraag om periodieke rapportages met aantallen incidenten, prioriteiten, gerealiseerde reactietijden, terugkerende oorzaken en openstaande verbeteracties. Bespreek niet alleen of een norm formeel is gehaald, maar ook wat medewerkers in de praktijk hebben ervaren.

Evalueer de afspraken minimaal jaarlijks en altijd na grote veranderingen. Nieuwe software, hybride werken, groei, een overname of strengere eisen van klanten kunnen het risicoprofiel veranderen. Wat vorig jaar voldoende was, kan dan onvoldoende bescherming bieden.

Neem service credits met realisme op. Een financiële vergoeding bij het niet halen van een serviceniveau kan nuttig zijn, maar herstelt geen verloren productiedag of reputatieschade. De grootste waarde zit in preventie, transparante rapportage en tijdige escalatie. Gebruik eventuele credits vooral als prikkel voor verbetering, niet als vervanging voor goede dienstverlening.

Onafhankelijk beoordelen voorkomt eenzijdige afspraken

Leverancierscontracten bevatten vaak technische termen, uitzonderingen en verwijzingen naar andere documenten. Daardoor is het lastig te zien of de SLA werkelijk aansluit op de offerte, algemene voorwaarden, verwerkersafspraken en uw eigen continuïteitsbehoefte. Een onafhankelijke beoordeling brengt die documenten samen en maakt zichtbaar waar risico’s, ontbrekende afspraken of kosten kunnen ontstaan.

Uw ICT Adviseur kijkt daarbij niet vanuit de verkoop van een pakket of beheerdienst, maar vanuit uw bedrijfsbelang. Dat betekent soms dat een zwaarder serviceniveau nodig is. Soms blijkt juist dat u betaalt voor ondersteuning die weinig toevoegt. In beide gevallen ontstaat een onderbouwde keuze waar u een leverancier gericht op kunt aanspreken.

De beste SLA is uiteindelijk niet de langste overeenkomst. Het is een afspraak die iedereen begrijpt, die aansluit op de momenten waarop uw bedrijf kwetsbaar is en die ook tijdens een incident uitvoerbaar blijft. Leg die afspraken vast voordat er iets misgaat. Dan houdt u de regie wanneer rust, snelheid en duidelijke verantwoordelijkheden het verschil maken.