Een SLA voor een ATS moet concrete en meetbare afspraken bevatten over beschikbaarheid, support, responstijden, herstel, incidenten, beveiliging, onderhoud en escalatie. Algemene formuleringen als ‘hoge beschikbaarheid’ of ‘snelle support’ zijn onvoldoende. Leg vast wat wordt gemeten, wanneer de meting start, welke uitzonderingen gelden en welke gevolgen optreden als de afgesproken service niet wordt gehaald.
Beschikbaarheid
Leg een beschikbaarheidspercentage vast en definieer hoe dit wordt berekend.
Maak duidelijk:
- welke onderdelen onder de SLA vallen;
- welke uren worden gemeten;
- hoe gepland onderhoud telt;
- welke storingen worden uitgesloten.
Een percentage zonder meetmethode is moeilijk te controleren.
Supporturen
Beschrijf wanneer support bereikbaar is.
Denk aan:
- kantooruren;
- avond of weekend;
- feestdagen;
- internationale tijdzones.
Een organisatie met 24/7 recruitmentactiviteiten heeft andere eisen dan een klein recruitmentteam.
Prioriteitsniveaus
Definieer incidentcategorieën.
Bijvoorbeeld:
- P1: systeem volledig onbeschikbaar;
- P2: kritieke functie werkt niet;
- P3: beperkte verstoring;
- P4: vraag of klein probleem.
Leg per niveau een reactie- en hersteltijd vast.
Reactietijd en hersteltijd
Reactietijd betekent niet hetzelfde als oplossingstijd.
Leg beide apart vast.
Een leverancier kan binnen dertig minuten reageren, terwijl herstel uren duurt. Voor kritieke recruitmentprocessen is juist die tweede maat belangrijk.
Escalatie
Maak duidelijk wat gebeurt wanneer een incident niet binnen de afgesproken tijd wordt opgelost.
Leg vast:
- wie escaleert;
- naar welk niveau;
- hoe vaak updates volgen;
- wie aan klantzijde wordt geïnformeerd.
Onderhoud
SaaS-systemen veranderen regelmatig.
Beschrijf:
- onderhoudsvensters;
- hoe lang vooraf wordt gemeld;
- hoe spoedonderhoud wordt behandeld;
- welke impact acceptabel is.
Beveiligingsincidenten
Een SLA kan aanvullende afspraken bevatten over securitymeldingen.
Denk aan:
- meldtermijn;
- contactpersonen;
- informatie over impact;
- voortgangsupdates;
- post-incidentrapportage.
In Hoe audit je een ATS of deze goed beveiligd is? wordt beschreven welke beveiligingsinformatie en controles relevant zijn.
Back-up en herstel
Leg vast welke hersteldoelen gelden.
Belangrijke begrippen zijn:
- hoe vaak back-ups worden gemaakt;
- hoe lang data maximaal verloren mag gaan;
- hoe snel herstel moet plaatsvinden;
- hoe herstel wordt getest.
Vraag ook hoe lang back-ups worden bewaard.
Integraties
Een ATS kan beschikbaar zijn terwijl een kritieke koppeling uitvalt.
Bepaal daarom welke integraties binnen de serviceafspraken vallen en wie verantwoordelijk is voor monitoring en herstel.
In het artikel over ATS-koppelingen wordt keteneigenaarschap expliciet als aandachtspunt genoemd.
Rapportage over SLA-prestaties
Spreek af hoe de leverancier rapporteert.
Een maand- of kwartaalrapport kan bevatten:
- beschikbaarheid;
- incidenten;
- reactietijden;
- hersteltijden;
- onderhoud.
Gebruik dezelfde definities als in het contract.
Servicecredits
Sommige contracten koppelen credits of compensatie aan het niet halen van de SLA.
Maak duidelijk:
- hoe die worden berekend;
- of de klant ze moet claimen;
- of er maxima gelden.
Een servicecredit vervangt niet automatisch de schade of operationele impact van een storing.
Continuïteit
Bespreek ook langdurige verstoring.
Wat gebeurt er als:
- de dienst meerdere dagen uitvalt;
- een datacenterprobleem optreedt;
- een kritieke subleverancier faalt;
- de leverancier zelf in problemen komt.
Maak een fallback- of continuïteitsplan voor recruitment.
Wijzig de SLA mee met het gebruik
Een SLA die past bij een klein team kan onvoldoende zijn wanneer het ATS bedrijfskritisch wordt.
Plan daarom periodiek een review van prioriteiten, supporturen en beschikbaarheid.
Definieer meetpunt en databron
Een SLA is alleen bruikbaar wanneer duidelijk is waar cijfers vandaan komen.
Leg vast welk monitoringsysteem beschikbaarheid meet, wie toegang heeft tot rapportages en hoe verschillen tussen leverancier en klant worden opgelost.
Maak onderscheid tussen storing en degradatie
Een systeem kan technisch bereikbaar zijn maar zo traag dat gebruikers nauwelijks kunnen werken.
Beschrijf daarom ook prestatieproblemen, foutpercentages of ernstige vertraging als mogelijk incident.
Leg communicatie tijdens incidenten vast
Bij een storing is niet alleen herstel belangrijk.
Spreek af:
- hoe snel een eerste melding komt;
- hoe vaak voortgang wordt gedeeld;
- welke informatie in updates staat;
- wanneer een eindrapport volgt.
Neem integratieketens mee
Een ATS kan beschikbaar zijn terwijl een koppeling naar HRIS of werken-bij-site faalt.
Maak daarom per kritieke keten duidelijk wie monitort en wie eerste aanspreekpunt is.
Definieer onderhoudsvensters concreet
Een onderhoudsvenster van meerdere uren kan voor een organisatie acceptabel zijn, maar niet tijdens een grote campagne.
Leg daarom tijdstippen, frequentie en aankondiging vast.
Maak security-events onderdeel van escalatie
Niet ieder securityincident betekent downtime.
Leg ook afspraken vast over verdachte toegang, datalekken, misbruik van accounts en kwetsbaarheden.
Bespreek hersteltests
Back-upbeleid is pas betrouwbaar wanneer herstel wordt getest.
Vraag daarom hoe vaak restores worden geoefend en welke uitkomsten worden vastgelegd.
Neem dataverlies expliciet op
Een ATS bevat kandidaat- en vacaturehistorie die niet zomaar opnieuw kan worden ingevoerd.
Leg daarom vast welke herstelpunten gelden en wat gebeurt wanneer gegevens verloren raken.
Beoordeel SLA in service reviews
Gebruik periodieke servicegesprekken om trends te bekijken.
Een leverancier kan formeel de SLA halen terwijl veel kleine incidenten toch veel gebruikersfrustratie veroorzaken.
Combineer daarom SLA-cijfers met supportdata en gebruikersfeedback.
Maak onderscheid tussen platform en klantconfiguratie
Niet iedere storing ligt bij de leverancier. Een fout in een eigen integratie of lokale configuratie kan buiten de SLA vallen.
Leg daarom vast hoe oorzaak wordt vastgesteld en welke partij verantwoordelijk is voor herstel.
Definieer ernstige verstoring
Een ATS kan formeel online zijn terwijl solliciteren, interviewplanning of hire-overdracht niet werkt.
Neem daarom kritieke businessfuncties op in de SLA en niet alleen technische beschikbaarheid van het platform.
Leg onderhoud aan API’s vast
API-wijzigingen kunnen integraties breken.
Spreek af hoeveel tijd vooraf breaking changes worden aangekondigd, hoe versiebeheer werkt en hoe lang oude versies ondersteund blijven.
Maak rapportage controleerbaar
Vraag voldoende detail om incidenten en beschikbaarheid zelf te kunnen toetsen.
Een enkel maandpercentage zonder onderliggende incidentenlijst is lastig te verifiëren.
Plan jaarlijkse SLA-herziening
Wanneer recruitment kritischer wordt voor de organisatie, kunnen eisen veranderen. Herzie daarom jaarlijks prioriteitsniveaus, supporturen, integraties en hersteldoelen.
Neem kandidaatkritieke processen apart op
Solliciteren, interviewplanning en kandidaatcommunicatie kunnen bedrijfskritisch zijn tijdens campagnes.
Leg daarom vast welke processen extra prioriteit krijgen en hoe storingen in die onderdelen worden behandeld.
Maak servicecredits niet het enige stuurmiddel
Een financiële compensatie herstelt geen verloren productiviteit of candidate experience.
Gebruik daarom servicecredits naast structurele probleemoplossing en verbeterafspraken.
Controleer subleveranciers
Een ATS kan afhankelijk zijn van hosting, e-mail of andere diensten.
Vraag hoe incidenten bij subleveranciers doorwerken in de SLA en wie verantwoordelijk blijft richting klant.
Maak uitzonderingen expliciet
Leg vast welke gebeurtenissen buiten de SLA vallen, zoals klantconfiguratie of gepland onderhoud. Te brede uitzonderingen maken een beschikbaarheidspercentage minder betekenisvol.
Leg ook vast hoe geschillen over meetresultaten worden opgelost, zodat leverancier en klant niet met verschillende beschikbaarheidscijfers blijven werken.
Neem deze evaluatie mee in het periodieke serviceoverleg.
