SLA's instellen die je team écht haalt
Te strakke SLA's demotiveren, te losse zeggen niets. Zo vind je de balans, met voorbeelden uit de praktijk.
In het kort
- 01Baseer je SLA's op wat je team nu haalt en verscherp ze stap voor stap, niet op een wensbeeld.
- 02Maak onderscheid per kanaal en prioriteit, en reken in werkuren als je team alleen overdag werkt.
- 03Een gemiste SLA is een signaal over bezetting of proces, geen reden om iemand aan te spreken.
Een SLA is een belofte: zo snel reageren we. Stel je die te strak af, dan kleurt je werkvoorraad de hele dag rood en went je team eraan dat doelen toch niet gehaald worden. Stel je hem te ruim af, dan haal je hem altijd en zegt hij niets meer.
Een goede SLA zit daartussen. Hij is haalbaar op een normale dag, voelt als een uitdaging op een drukke dag en vertelt je iets als hij structureel gemist wordt. Zo kom je daar.
Begin bij wat je nu haalt
Een veelgemaakte fout is een SLA kiezen omdat hij goed klinkt. 'Binnen een uur reactie' staat mooi op je website, maar als je team nu gemiddeld een halve dag nodig heeft, maak je vooral een belofte die je gaat breken.
Kijk daarom eerst in Zendesk Explore wat je huidige reactietijden zijn, per kanaal en per prioriteit. Het gemiddelde zegt weinig, want een paar uitschieters trekken het scheef. De mediaan zegt meer, net als de tijd waarbinnen je negen van de tien tickets beantwoordt. Zet je eerste doel net iets scherper dan wat je nu haalt. Verscherp het pas als je team dat doel een paar maanden stabiel haalt.
Kies een paar doelen, niet alle
Zendesk kent verschillende SLA-doelen, elk met een eigen klok:
- First reply time: de tijd tot de eerste publieke reactie van een medewerker.
- Next reply time: de tijd tussen de oudste onbeantwoorde reactie van de klant en je volgende publieke antwoord.
- Periodic update: de maximale tijd tussen twee publieke updates, zolang een ticket loopt.
- Requester wait time en agent work time: hoe lang een ticket in totaal bij je team ligt. Requester wait time telt de status On-hold mee, agent work time niet. Tijd in Pending telt bij geen van beide.
Voor de meeste teams zijn first reply time en next reply time genoeg om mee te beginnen. Dat zijn de momenten die een klant zelf ervaart. Elk extra doel is een extra badge in je views, en na een tijdje kijkt niemand er nog naar.
Periodic update is vooral nuttig voor tickets die lang lopen, zoals een reparatie of een uitzoekvraag bij een leverancier. De klant weet dan dat hij niet vergeten is, ook als er nog geen oplossing is.
Let op wat telt als reactie. Bij first reply time en next reply time stopt een publieke reactie de klok. Een gewone ontvangstbevestiging per e-mail telt niet mee, en een interne notitie ook niet. Laat je een trigger automatisch een publieke reactie aan het ticket toevoegen, dan kan die wel meetellen. Goed voor de cijfers, maar de klant is er nog niet mee geholpen.
Maak onderscheid per kanaal en prioriteit
Een klant in de chat verwacht binnen minuten antwoord, een klant die mailt rekent eerder op uren. Eén SLA voor alles is daarom bijna altijd te streng voor het ene kanaal of te ruim voor het andere. Een opzet kan er bijvoorbeeld zo uitzien:
- E-mail, normale prioriteit: eerste reactie binnen 8 werkuren.
- E-mail, hoge prioriteit: eerste reactie binnen 2 werkuren.
- Chat of messaging: eerste reactie binnen 5 minuten, tijdens openingstijden.
- Vervolgreacties op e-mail: binnen 8 werkuren na een reactie van de klant.
Dit zijn voorbeelden, geen normen. De juiste getallen volgen uit je eigen data. Houd het aantal varianten ook beperkt: een paar combinaties van kanaal en prioriteit zijn voor de meeste teams genoeg. Twaalf varianten begrijpt niemand meer.
Reken voor e-mail in werkuren (business hours) als je team alleen overdag werkt. Een herkenbaar voorbeeld: op maandagochtend staat de mail van het hele weekend klaar. Telt je SLA in kalenderuren, dan zijn die tickets al rood voordat iemand is ingelogd. Leg je openingstijden daarom vast in een schedule, inclusief feestdagen. Per SLA-doel kies je daarna of het in werkuren of in kalenderuren telt.
Zo richt je het in Zendesk in
- Maak een schedule met je openingstijden en feestdagen.
- Zorg dat elk ticket een prioriteit heeft. Zonder prioriteit krijgt een ticket geen SLA-doel, dus een trigger die standaard Normaal invult voorkomt gaten.
- Maak je SLA-beleid (SLA policies) aan, met voorwaarden op bijvoorbeeld kanaal of groep. Zendesk past per ticket het eerste beleid toe waarvan de voorwaarden kloppen, dus de volgorde telt.
- Sorteer je views op de eerstvolgende SLA-deadline. Dan laat de SLA-badge je team zien wat eerst moet.
- Test met een paar tickets of het juiste beleid wordt toegepast, voordat je live gaat.
Voorkom dat je team de klok gaat bespelen
Zodra SLA's zwaar wegen, ontstaat creativiteit. Een snel 'we kijken ernaar'-berichtje om de first reply time te halen. Een ticket op Pending terwijl er eigenlijk niet op de klant gewacht wordt. Het cijfer ziet er dan goed uit, maar de klant schiet er niets mee op.
Bespreek gemiste SLA's daarom als signaal, niet als schuldvraag. Zijn het steeds dezelfde uren? Dan zit het in je bezetting. Steeds hetzelfde onderwerp? Dan helpt een macro, een beter artikel in je Help Center of een andere routering vaak meer dan harder werken.
Plan na een maand een evaluatie. Kijk per doel hoe vaak het gehaald is en waar het misging, en stel bij waar nodig. Een SLA is geen afspraak voor de eeuwigheid, maar een instelling die meegroeit met je team.