Als een IT-dienstverlener zegt te werken met ‘best effort’, betekent dit dat ze hun best doen om jouw IT-omgeving te ondersteunen, maar zonder concrete garanties over reactietijden, beschikbaarheid of herstel na een storing. Er is geen contractuele verplichting om binnen een bepaalde tijd te reageren of een probleem op te lossen. Voor jouw organisatie is het cruciaal om te begrijpen wat dit verschil in de praktijk betekent, want de gevolgen kunnen groter zijn dan je op het eerste gezicht zou denken. In dit artikel beantwoorden we de meest gestelde vragen over ‘best effort’ en wat jij daarmee moet doen.
Wat is het verschil tussen ‘best effort’ en een SLA?
Het verschil tussen ‘best effort’ en een SLA (Service Level Agreement) is eenvoudig: een SLA legt in een contract vast wat je mag verwachten, terwijl ‘best effort’ alleen een intentie uitdrukt zonder afdwingbare afspraken. Bij een SLA staan responstijden, beschikbaarheidspercentages en escalatieprocedures zwart op wit. Bij ‘best effort’ is er geen meetlat.
Een SLA geeft jou als klant concrete houvast. Als jouw IT-partner een reactietijd van twee uur afspreekt voor kritieke storingen, kun je hem daarop aanspreken. Wordt die termijn structureel overschreden, dan heeft dat contractuele consequenties. Dat schept duidelijkheid voor beide partijen en zorgt ervoor dat prioriteiten intern bij de IT-partij ook echt worden gesteld.
Bij ‘best effort’ ontbreekt die zekerheid volledig. De IT-partij doet wat haalbaar is op dat moment, maar jij hebt geen enkel juridisch of contractueel middel als dat niet genoeg blijkt. In de praktijk werkt dit prima zolang er weinig misgaat. Maar juist op het moment dat het er echt toe doet, zoals bij een serieuze storing of een beveiligingsincident, merk je het verschil.
Welke risico’s brengt ‘best effort’ met zich mee voor jouw organisatie?
De grootste risico’s van ‘best effort’ voor jouw organisatie zijn onvoorspelbare hersteltijden, geen garantie op prioritering en een gebrek aan verantwoordelijkheid bij de IT-partij. Zonder afspraken op papier ben jij afhankelijk van de drukte, de bezetting en de goodwill van je leverancier op het moment dat er iets misgaat.
Denk aan een situatie waarbij jouw systemen uitvallen op een drukke maandag. Jouw IT-partij heeft op dat moment meerdere klanten met urgente problemen. Zonder SLA heeft niemand formeel voorrang. De kans bestaat dat jij uren, of zelfs een halve dag, moet wachten terwijl jouw medewerkers stilstaan.
Andere concrete risico’s zijn:
- Geen vastgelegde beschikbaarheidsgarantie voor kritieke systemen
- Geen escalatieprocedure als een probleem niet snel genoeg wordt opgelost
- Geen compensatiemogelijkheid bij langdurige uitval
- Onduidelijkheid over wie verantwoordelijk is voor welk deel van jouw IT-omgeving
- Moeilijk plannen van continuïteit als je niet weet hoe snel hulp beschikbaar is
Voor organisaties in de zorg of het MKB, waar continuïteit van systemen direct invloed heeft op de dienstverlening aan klanten of patiënten, zijn deze risico’s bijzonder relevant.
Wanneer is ‘best effort’ acceptabel en wanneer niet?
‘Best effort’ is acceptabel voor niet-kritieke systemen of situaties waarbij downtime geen directe bedrijfsschade veroorzaakt. Het is niet acceptabel als jouw organisatie afhankelijk is van continue toegang tot systemen, klantdata of bedrijfskritische applicaties. De grens ligt bij de impact die uitval heeft op jouw dagelijkse bedrijfsvoering.
Een paar voorbeelden waarbij ‘best effort’ redelijk is:
- Ondersteuning bij een interne testomgeving die niet in productie draait
- Advies over hardware die niet operationeel kritiek is
- Incidentele vragen over software die medewerkers zelden gebruiken
Situaties waarbij ‘best effort’ onvoldoende is:
- Jouw primaire bedrijfssoftware of ERP-systeem
- IT-beveiliging en monitoring van jouw netwerk
- E-mail en communicatieplatforms die dagelijks worden gebruikt
- Cloudopslag en back-upoplossingen waarvan de integriteit gewaarborgd moet zijn
- Systemen in de zorg waarbij uitval directe gevolgen heeft voor patiëntveiligheid
De vuistregel is simpel: als uitval jou geld, reputatie of veiligheid kost, heb je een SLA nodig. Niet een belofte.
Hoe herken je ‘best effort’ in een IT-contract?
Je herkent ‘best effort’ in een IT-contract aan vage formuleringen zonder meetbare normen. Zinnen als “wij streven ernaar”, “zo snel mogelijk”, “naar beste vermogen” of “binnen een redelijke termijn” zijn typische signalen dat er geen afdwingbare afspraken zijn gemaakt. Concrete getallen en garanties ontbreken.
Let bij het lezen van een IT-contract specifiek op de volgende elementen:
- Reactietijden: Staat er een specifiek aantal uren of minuten, of alleen een intentie?
- Beschikbaarheidspercentage: Is er een uptime-garantie, bijvoorbeeld 99,9%, of ontbreekt dit?
- Prioriteitsniveaus: Worden storingen ingedeeld op ernst met bijbehorende responstijden?
- Escalatieprocedure: Is er een vastgelegde route als een probleem niet op tijd wordt opgelost?
- Boeteclausules of compensatie: Zijn er consequenties als de IT-partij haar verplichtingen niet nakomt?
Ontbreekt een of meerdere van deze elementen, dan werk je feitelijk op basis van ‘best effort’, ook al staat dat woord er niet letterlijk in. Een goed contract is concreet, meetbaar en geeft jou als klant een duidelijk recht op actie als afspraken niet worden nagekomen.
Wat moet je vragen aan een IT-partij over hun serviceniveau?
Vraag een IT-partij altijd naar concrete responstijden per urgentieniveau, het beschikbaarheidspercentage dat zij garanderen, hoe escalatie werkt bij langdurige storingen en wat de consequenties zijn als zij hun afspraken niet nakomen. Wie geen duidelijk antwoord geeft op deze vragen, werkt waarschijnlijk op ‘best effort’.
Een goede IT-partij heeft geen moeite met transparantie over haar serviceniveaus. Gebruik onderstaande vragen als leidraad bij een gesprek:
- Wat is jullie gegarandeerde reactietijd bij een kritieke storing buiten kantooruren?
- Welk beschikbaarheidspercentage garanderen jullie voor onze primaire systemen?
- Hoe worden storingen geprioriteerd als meerdere klanten tegelijk problemen hebben?
- Wat gebeurt er contractueel als jullie de afgesproken responstijd overschrijden?
- Is er een vaste contactpersoon die onze IT-omgeving kent?
- Hoe worden wijzigingen in het serviceniveau gecommuniceerd en vastgelegd?
De antwoorden op deze vragen vertellen je meer dan de mooiste brochure. Een IT-partij die werkt met echte IT-beveiliging en managed services legt haar beloftes vast in een contract, zodat jij weet waar je aan toe bent. Wil je weten hoe Symbis dit aanpakt en welk serviceniveau bij jouw organisatie past? Neem dan contact op voor een vrijblijvend gesprek.
Veelgestelde vragen
Kan ik een bestaand 'best effort'-contract omzetten naar een SLA?
Ja, dat is in de meeste gevallen mogelijk. Neem het initiatief door een gesprek aan te vragen met jouw huidige IT-partij en geef concreet aan welke garanties jij nodig hebt, zoals reactietijden, uptime-percentages en escalatieprocedures. Als jouw huidige leverancier niet bereid is om deze afspraken contractueel vast te leggen, is dat een sterk signaal om de markt te verkennen en over te stappen naar een partij die wél met formele SLA's werkt.
Wat zijn de gemiddelde kosten van een SLA ten opzichte van 'best effort'-ondersteuning?
Een SLA brengt doorgaans hogere maandelijkse kosten met zich mee dan 'best effort'-ondersteuning, omdat de IT-partij capaciteit moet reserveren om gegarandeerde responstijden te kunnen waarmaken. Toch zijn die extra kosten voor de meeste organisaties snel terugverdiend: één serieuze storing met meerdere uren stilstand kost al gauw meer dan maanden aan SLA-premie. Vergelijk de kosten van een SLA altijd met de potentiële schade van ongegarandeerde downtime voor jouw specifieke bedrijfssituatie.
Wat is een realistisch uptime-percentage om te eisen in een SLA?
Voor bedrijfskritische systemen is een uptime-garantie van minimaal 99,5% een gangbare ondergrens, waarbij 99,9% (ook wel 'three nines' genoemd) de standaard is bij professionele managed service providers. Ter vergelijking: 99,9% uptime staat gelijk aan maximaal circa 8,7 uur geplande of ongeplande uitval per jaar. Zorg dat in de SLA ook duidelijk staat of geplande onderhoudsmomenten buiten deze berekening vallen, zodat je niet voor verrassingen komt te staan.
Hoe ga ik om met een IT-partij die wel een SLA aanbiedt, maar de afspraken in de praktijk niet nakomt?
Documenteer alle incidenten zorgvuldig, inclusief het tijdstip van melding, de responstijd en de uiteindelijke oplostijd, zodat je een aantoonbaar patroon van niet-nakoming kunt opbouwen. Stap vervolgens formeel naar de IT-partij met deze gegevens en verwijs naar de contractueel vastgelegde boeteclausules of compensatieregelingen. Als structurele verbetering uitblijft, geeft een goed opgestelde SLA jou ook de juridische basis om het contract te ontbinden en over te stappen naar een betrouwbare partner.
Geldt 'best effort' ook voor cybersecuritydiensten, en wat zijn daarvan de risico's?
Ja, ook cybersecuritydiensten worden soms aangeboden op 'best effort'-basis, en dat is bijzonder risicovol. Bij een beveiligingsincident, zoals een ransomware-aanval of datalek, telt elke minuut: hoe langer het duurt voordat er actie wordt ondernomen, hoe groter de schade en hoe hoger de kans op reputatieschade of boetes onder de AVG. Zorg er daarom voor dat monitoring, detectie én respons bij beveiligingsincidenten altijd gedekt zijn door concrete, afdwingbare afspraken in een SLA.
Zijn er sectoren of organisatietypen waarvoor een SLA wettelijk verplicht is?
In de zorgsector gelden strenge eisen rondom de beschikbaarheid en beveiliging van systemen, mede vanuit de NEN 7510-norm en de AVG, waardoor een SLA in de praktijk vrijwel onmisbaar is. Ook organisaties die vallen onder de NIS2-richtlijn (zoals aanbieders van essentiële diensten en digitale infrastructuur) zijn verplicht om aantoonbare maatregelen te nemen voor continuïteit en incidentrespons, wat een formele SLA met hun IT-leverancier sterk aanbeveelt of zelfs vereist. Laat je bij twijfel adviseren door een juridisch of IT-compliance specialist die bekend is met de regelgeving in jouw sector.
Hoe snel kan ik overstappen naar een IT-partij met een volwaardige SLA als ik nu op 'best effort' zit?
De doorlooptijd van een overstap hangt af van de complexiteit van jouw IT-omgeving en de opzegtermijn in je huidige contract, maar een gestructureerde migratie naar een nieuwe managed service provider duurt gemiddeld vier tot twaalf weken. Begin met het inventariseren van jouw huidige systemen, contractuele verplichtingen en kritieke afhankelijkheden, zodat je een nieuwe partij een volledig beeld kunt geven. Een goede IT-partner helpt je bij het opstellen van een migratieplan dat continuïteit garandeert en het risico op uitval tijdens de overstap minimaliseert.