Module configuratie
SLA
Tijdsafspraken op meldingen en taken — meten, monitoren en escaleren wanneer doorlooptijden dreigen te breken.
Bijgewerkt op 23 jan 2026
Configuratie · Modules · 4.4
Een SLA (Service Level Agreement) is een tijdsafspraak op een melding of taak. De SLA-module legt vast wát je belooft, voor welke gevallen het geldt, en bewaakt of je de afspraak haalt — met een timer die alleen tijdens werkuren loopt.
Waarom dit voor de business belangrijk is
"Beloftes onmeetbaar"
Tijd-tot-eerste-reactie en tijd-tot-resolutie expliciet — rapporteerbaar per maand.
"Wachten op klant telt door"
Condities pauzeren de timer bij specifieke statussen — eerlijke metingen.
"Buiten kantoor gaat klok door"
Kalender koppelt aan SLA → timer loopt alleen tijdens werkuren.
"Te laat geëscaleerd"
Notificatie-sequence op SLA-percentage → herinnering, manager, stuurgroep automatisch.
Vier aspecten van elke SLA
| Aspect | Wat het bepaalt |
|---|---|
| Klasse | Tijd tot eerste reactie of tijd tot resolutie. Twee verschillende meetstrategieën. |
| Criteria | Wanneer geldt de SLA: organisatie, classificatie, prioriteit, soort (melding/taak), sjabloon, type. |
| Tijdsdoel | Maximaal toegestane doorlooptijd in uren/minuten + de kalender die werkuren definieert. |
| Condities | Wanneer start, pauzeert of stopt de timer (bv. status "Wachten op klant" pauzeert). |
De combinatie klasse + criteria is uniek — exact dezelfde setup tweemaal aanmaken levert een foutmelding.
Twee SLA-klasses
Tijd tot eerste reactie
Hoe snel reageert iemand op de melding? Stopt zodra eerste opvolging gegeven is.
Tijd tot resolutie
Hoe snel is het opgelost? Stopt op afhandelingstatus.
Wijzigingsgedrag
Wanneer op een ticket iets verandert (organisatie, prioriteit, classificatie), controleert Gfacility opnieuw of er een SLA matcht. Een nieuwe SLA wordt actief, of een bestaande wordt verborgen als geen criterium meer past.
Wanneer de SLA-configuratie zelf wijzigt, blijven al actieve SLA’s intact — de oude blijft tikken tot het ticket sluit. Pas wanneer iets op het ticket wijzigt, herevalueert Gfacility.
Welke beslissingen ga je nemen?
Welke prioriteits-bandes?
Kritisch · hoog · normaal · laag — elk eigen tijdsdoel. Te veel banden = onnodige complexiteit.
Werkuren vs 24/7?
Welke kalender koppel je? Eén kalender per service-team is meestal voldoende.
Welke statussen pauzeren?
"Wachten op klant", "On hold" — anders telt extern wachten door en breek je oneerlijk.
SLA op melding óf taak?
Beide kan, maar kies per use-case — anders rapporteer je dubbel.