SLA's instellen die je team echt kan halen

Je SLA zegt: eerste reactie binnen 4 uur. Het is 17:00 en 12 tickets hebben die grens overschreden. Je team voelt zich alsof ze falen. Maar falen ze echt, of was de SLA het probleem? Te ambitieuze SLA's zijn net zo schadelijk als geen SLA's. Ze creëren een constante staat van falen die je team demotiveert, je data vertroebelt, en je geen bruikbare stuurinformatie geeft.

SLA's instellen voor je support team klinkt als een administratieve klus. Vul wat getallen in, druk op opslaan, klaar. Maar de teams die het goed doen, behandelen SLA's als een strategisch instrument. Ze vertellen je team wat wordt verwacht, ze laten je klanten weten waar ze op kunnen rekenen, en ze geven je als manager een dashboard dat je kunt vertrouwen.

Wat is een SLA eigenlijk (en wat niet)

Een Service Level Agreement is een belofte. Niet aan je management of je board — aan je klant. "Als je ons een bericht stuurt, reageren we binnen X tijd." Die belofte kan intern zijn (je team weet het, de klant niet) of extern (gepubliceerd op je site). Beide hebben waarde, maar ze werken anders.

Interne SLA's zijn een sturingsinstrument. Ze geven je team een helder doel en jou als manager de mogelijkheid om knelpunten te identificeren. Als 30% van je email-tickets de SLA overschrijdt, weet je dat er iets niet klopt — te weinig capaciteit, te trage processen, of een verkeerde SLA.

Externe SLA's zijn een marketinginstrument en een vertrouwenssignaal. "We reageren binnen 1 uur" op je contactpagina geeft klanten zekerheid. Maar wees voorzichtig: een externe SLA die je niet haalt, is erger dan geen SLA. Een gebroken belofte schaadt het vertrouwen meer dan helemaal geen belofte.

Begin altijd met interne SLA's. Als je die drie maanden lang consistent haalt (minimaal 90% compliance), kun je overwegen ze extern te communiceren.

Wat een SLA niet is: een prestatiebeoordeling voor individuele agents. SLA's meten het systeem, niet de persoon. Als een agent structureel SLA's mist, is de oorzaak vaker een routing-probleem of capaciteitsprobleem dan een individueel prestatieprobleem.

Benchmarks per kanaal

Niet elk kanaal verdient dezelfde SLA. Een klant die live chat opent, verwacht een reactie binnen seconden. Diezelfde klant accepteert uren wachttijd op een email. Stel per kanaal een aparte SLA in op basis van wat klanten daadwerkelijk verwachten.

Live chat — eerste reactie: 2 minuten, oplossing: 15 minuten. Chat is instant. Klanten die chat openen, zijn actief aan het wachten. Elk moment voorbij de 2 minuten voelt als een eeuwigheid. De oplossings-SLA van 15 minuten houdt rekening met chats die meerdere berichten nodig hebben.

Email — eerste reactie: 4 uur, oplossing: 24 uur. Email is asynchroon. Klanten verwachten geen directe reactie, maar wel dezelfde werkdag. Topteams halen onder het uur voor eerste reactie, maar 4 uur is een realistische startpunt voor de meeste ecommerce teams.

Social media — eerste reactie: 1 uur, oplossing: 4 uur. Social media zit tussen chat en email. Berichten op Instagram of Facebook zijn publiek zichtbaar, wat extra druk geeft. Een DM die uren onbeantwoord blijft, is zichtbaar voor iedereen die het profiel bezoekt.

Telefoon — opnemen: 30 seconden, afhandeling: 10 minuten. Als je telefoonondersteuning biedt, is de verwachting helder: neem snel op en los het in dat ene gesprek op. Doorverbinden telt als een negatieve klantervaring.

Belangrijk: dit zijn benchmarks, geen commandmenten. Als je team van twee agents zowel chat als email als social beheert, is een chat-SLA van 2 minuten misschien niet realistisch. Stel een SLA in die je team in 85-90% van de gevallen kan halen. Dat is de sweet spot tussen ambitie en haalbaarheid.

Prioriteitsniveaus: niet elk ticket is even urgent

Een SLA zonder prioriteitsniveaus behandelt elk ticket gelijk. Maar een klant die vraagt of jullie ook in het geel leveren, heeft een andere urgentie dan iemand wiens betaling is afgewezen. Zonder prioriteiten krijgen beide dezelfde deadline, en je team heeft geen richtlijn voor wat eerst moet.

Hier is een framework dat werkt voor de meeste ecommerce teams:

P1 — Kritiek (5-10% van tickets). Betalingsproblemen, bestellingen die niet zijn geleverd, security-gerelateerde vragen. Eerste reactie: 30 minuten. Oplossing: 4 uur. Dit zijn de tickets waar geld of vertrouwen direct op het spel staat.

P2 — Hoog (15-20% van tickets). Productdefecten, retourverzoeken bij grote bestellingen, klachten van terugkerende klanten. Eerste reactie: 2 uur. Oplossing: 8 uur. Serieuze problemen die dezelfde dag opgelost moeten worden.

P3 — Normaal (50-60% van tickets). Standaard productvragen, levertijden, retourbeleid, accountwijzigingen. Eerste reactie: 4 uur. Oplossing: 24 uur. Het gros van je volume — belangrijk maar niet urgent.

P4 — Laag (15-20% van tickets). Suggesties, algemene feedback, vragen over toekomstige producten. Eerste reactie: 8 uur. Oplossing: 48 uur. Vervelend om te laten liggen, maar geen directe impact op de klantervaring.

De verdeling van 5/20/60/15 is een richtlijn. Analyseer je eigen tickets om te zien hoe de verdeling bij jou uitpakt. Als 40% van je tickets P1 is, heb je ofwel te brede P1-criteria ofwel een structureel probleem dat je buiten support moet oplossen.

Stel de prioriteit niet handmatig in. Gebruik ticket workflows die automatisch prioriteit toekennen op basis van trefwoorden, klantwaarde, kanaal en sentiment. Een agent die bij elk ticket moet nadenken "is dit P2 of P3?" verliest tijd die beter naar het antwoord gaat.

SLA's instellen in de praktijk

Stap 1 is niet het invullen van getallen. Stap 1 is meten wat je nu doet. Trek je data van de afgelopen 4-6 weken. Wat is je gemiddelde eerste responstijd per kanaal? Wat is de mediaan? En cruciaal: wat is je 90e percentiel? Dat getal vertelt je hoelang de langzaamste 10% van je tickets wacht.

Als je gemiddelde email-FRT 3 uur is maar je 90e percentiel 14 uur, dan heb je een staartprobleem. Die 14 uur zijn waarschijnlijk tickets die binnenkomen na 17:00 en pas de volgende ochtend worden opgepakt. Dat probleem los je niet op met een strakkere SLA — dat los je op met een andere planning.

Stap 2: Stel SLA's in op het 85e-90e percentiel van je huidige prestaties. Als 85% van je email-tickets nu binnen 5 uur een eerste reactie krijgt, stel dan je SLA in op 5 uur. Niet op 2 uur omdat dat mooier klinkt. Een SLA die je in 85-90% van de gevallen haalt, is een bruikbare SLA. Een SLA die je in 60% haalt, is een wensdroom.

Stap 3: Configureer in je helpdesk. Stel per kanaal en per prioriteitsniveau een SLA in. Configureer waarschuwingen: een notificatie als een ticket 75% van de SLA-tijd heeft bereikt (zodat een agent het kan oppakken voor het te laat is) en een escalatie als de SLA is overschreden.

Stap 4: Definieer wat "klok tikt" betekent. Telt de SLA-klok alleen tijdens kantooruren? Pauzeer je de klok als je wacht op antwoord van de klant? Dit zijn cruciale keuzes die je upfront moet maken. De meeste teams tellen alleen kantooruren voor email en 24/7 voor chat.

Stap 5: Communiceer met je team. Een SLA die niemand kent, is geen SLA. Bespreek de doelen met je team. Leg uit waarom ze zo zijn ingesteld. Maak duidelijk dat het doel 90% compliance is, niet 100% — perfectie is geen vereiste.

Meten en bijsturen zonder je team gek te maken

SLA-dashboards zijn krachtig en gevaarlijk. Krachtig omdat ze je precies laten zien waar de knelpunten zitten. Gevaarlijk omdat ze een afrekencultuur kunnen creëren als je niet oplet.

De gezonde aanpak: review SLA-compliance wekelijks met je team. Niet als een rapportcijfer, maar als een gezamenlijke diagnose. "We haalden 87% op email vorige week. Dinsdag was een uitbijter met 12 SLA-breaches. Wat was er aan de hand?" Misschien was het een productlancering die een piek veroorzaakte. Misschien was een agent ziek. Misschien is de SLA te strak voor het dinsdagvolume.

Focus op trends, niet op individuele weken. Een SLA-compliance die drie weken op rij daalt, is een signaal. Een slechte week na zes goede weken is ruis. Reageer op het eerste, niet op het tweede.

Belangrijke metrics voor je wekelijkse review:

• SLA compliance percentage per kanaal. Doel: 85-90%.
• Gemiddelde tijd tot breach. Als tickets gemiddeld 20 minuten over de SLA gaan, is dat minder erg dan 4 uur over de SLA.
• Breaches per dagdeel. Identificeert capaciteitsproblemen op specifieke momenten.
• Breaches per ticket-type. Misschien haal je je SLA op productvragen maar niet op retouren. Dat is een procesprobleem, niet een capaciteitsprobleem.

Vier verbeteringen. Als je compliance stijgt van 82% naar 88%, benoem dat. Niet met een pizza-party voor elke procentpunt, maar met een simpel "goed gedaan, het werkt." Teams die alleen horen wat er misgaat, stoppen met proberen.

En als je structureel onder de 80% compliance zit? Pas de SLA niet aan naar boven — dat maskeert het probleem. Analyseer of het een volume-, capaciteits- of procesprobleem is. Vaak lost slimmere routing of AI-ondersteuning het op zonder extra personeel. Pas als je routing geoptimaliseerd is, je processen gestroomlijnd zijn, en je agents ondersteund worden met AI-concepten — pas dan kijk je naar extra capaciteit.

SLA's die werken

De beste SLA's zijn geen ambitieuze targets die op een whiteboard staan. Het zijn realistische beloften die je team elke dag waarmaakt. Ze zijn specifiek per kanaal, gedifferentieerd per prioriteit, en gebaseerd op data — niet op gevoel.

Begin met meten wat je nu doet. Stel SLA's in op je 85e percentiel. Review wekelijks. Verbeter stapsgewijs. Over drie maanden heb je een support-operatie met voorspelbare, betrouwbare responstijden waar je team trots op is.

Wil je weten hoe je SLA's zich verhouden tot de benchmarks in jouw branche? Download onze Support KPI Benchmark Guide voor uitgebreide cijfers per sector, teamgrootte en kanaal. Of stel je SLA's direct in met ticket workflows in SamDesk — inclusief automatische prioritering en escalatie.