Het playbook voor supportautomatisering: naar 90% zonder je CSAT te slopen

Support is de eerste plek waar de meeste e-commercemerken automatiseren, en met goede reden: het volume is hoog, de patronen zijn repetitief, de kosten schalen lineair mee met groei, en het werk is voor de mensen die het doen oprecht onaangenaam.

Het is ook de plek waar het het vaakst slecht gebeurt, want een slechte supportbot is erger dan geen supportbot. Klanten onthouden hem.

Dit is de volgorde die wij draaien. Hij is bewust saai.

Stap 0: Meet de wachtrij vóór je hem aanraakt

Je kunt niet automatiseren wat je niet hebt geteld. Voordat je een regel code schrijft, haal je 90 dagen tickets op en classificeer je ze — een goedkoop model doet dat in een middag over een paar duizend tickets.

Haal per categorie vier getallen op:

• Volume — hoeveel per maand
• Afhandeltijd — mediaan in minuten van openen tot oplossen
• Complexiteit — hoeveel systemen raakt een medewerker aan om het op te lossen?
• Vereist oordeel — vraagt de oplossing om een beslissing, of alleen om opzoeken?

Vermenigvuldig volume met afhandeltijd en je hebt de uren. Die kolom, aflopend gesorteerd, is je roadmap. Hij komt niet overeen met wat iemand verwacht — teams overschatten consequent de kosten van de tickets die ze haten en onderschatten de kosten van de saaie die ze snel en constant wegwerken.

Een typische verdeling voor een D2C-merk:

Categorie	Aandeel volume	Automatiseerbaar
Waar blijft mijn bestelling (WISMO)	30–40%	Vrijwel volledig
Retouren & terugbetalingen	15–20%	Grotendeels, met beleid in code
Productvragen (maat, materiaal, compatibiliteit)	10–15%	Grotendeels, met goede retrieval
Orderwijziging (adres, maat, annuleren)	8–12%	Hangt af van het fulfilmentmoment
Kortings- en betaalproblemen	5–8%	Deels
Beschadigd / verkeerd artikel	5–8%	Deels — vraagt fotoverificatie
De rest	10–20%	Per geval

Stap 1: Altijd eerst WISMO

Dertig tot veertig procent van het volume, vrijwel geen oordeel vereist, en het antwoord staat in systemen die je al hebt.

Het cruciale detail: stuur niet gewoon een trackinglink. Dat deed de geautomatiseerde e-mail al, en de klant schrijft je juist omdat die link zijn vraag niet beantwoordde. Er staat "onderweg" en hij wil weten of het vóór het weekend aankomt.

Een goede WISMO-agent:

1. Identificeert de bestelling uit het bericht — nummer, e-mail, of via context
2. Haalt de live vervoerdersstatus op, niet de gecachete
3. Interpreteert die tegen typische transittijden op dat traject
4. Geeft een concreet antwoord: "Hij is gisteren door de hub in Rotterdam gegaan en ligt op koers voor donderdag"
5. Herkent de uitzonderingsgevallen — scans die stilstaan, douanevertraging, mislukte bezorgpogingen — en onderneemt per geval de juiste actie in plaats van de status voor te lezen

Punt 5 is waar de waarde zich concentreert. Een pakket dat zes dagen niet is gescand heeft een claim nodig, geen statusupdate.

Realistische uitkomst: het WISMO-ticketvolume daalt met 80–90%, en wat overblijft zijn echte uitzonderingen.

Stap 2: Retouren en terugbetalingen, met het beleid in code

Hogere inzet, en de discipline is anders: het beleid gaat in code, niet in de prompt.

Schrijf een functie die een bestelling aanneemt en een rechtenbeslissing teruggeeft — termijn, staat van het artikel, categorie-uitsluitingen, marktspecifieke regels, of het artikel in de uitverkoop was. Het model roept die functie aan en communiceert het resultaat. Het leest geen beleidsdocument en beslist niet zelf.

Dit is belangrijk omdat retourbeleid vol staat met uitzonderingen die triviaal in code zijn uit te drukken en oprecht dubbelzinnig in proza. "Afgeprijsde artikelen zijn definitief, behalve tijdens het januarivenster, en gepersonaliseerde artikelen zijn altijd uitgesloten behalve bij productiefouten" is drie regels logica en een alinea die geen twee mensen hetzelfde lezen.

Stel een waardegrens in waarboven een mens beoordeelt. Begin laag — zeg €150 — en verhoog naarmate het nauwkeurigheidsdossier van de agent zich opbouwt. Je finance-team zal je dankbaar zijn voor het audittrail.

Stap 3: Productvragen, wat eigenlijk een retrieval-probleem is

Maatvoering, materialen, wasvoorschriften, compatibiliteit, allergenen. Succes wordt hier volledig bepaald door de vraag of de informatie in ophaalbare vorm bestaat.

Meestal niet. Ze staat op de PDP als marketingtekst, in een specsheet die niemand heeft geïndexeerd, in het hoofd van de inkoper, en in 4.000 eerdere ticketantwoorden.

De oplossing is een contentproject, geen AI-project:

• Haal gestructureerde attributen uit specsheets naar een bevraagbare vorm
• Delf eerdere ticketoplossingen af voor echte antwoorden — dit is je dichtste bron en hij staat al in je merkstem
• Indexeer reviews voor pasvorm en kwaliteit in de praktijk ("valt klein" wordt in reviews beantwoord, niet op de PDP)
• Schrijf op wat alleen in iemands hoofd bestaat

Doe dit één keer, goed, en het betaalt tegelijk uit in support, PDP-content, advertenties en SEO.

Stap 4: De escalatielaag, parallel gebouwd

Niet als laatste. Bouw hem naast stap één, want hij is wat de rest veilig maakt.

Escaleer op categorie. Juridische dreigementen, veiligheidskwesties, overlijden, chargeback-disputen, persvragen, iedereen die twee keer om een mens vroeg. Die verlaten de automatisering, ongeacht of de agent het technisch kon beantwoorden.

Escaleer op sentimentverschuiving. Volg het verloop binnen een gesprek, niet alleen het openingsbericht. Het gesprek dat neutraal begint en omslaat, is degene die je moet vangen. Dit draait als aparte classifier met een eigen eval-set — vouw het niet in het oordeel van de hoofdagent.

Escaleer op zekerheid. Geen retrieval boven de relevantiedrempel, of een beslissing buiten de gecodeerde grenzen, betekent overdragen.

Maak de overdracht echt goed. De medewerker hoort te ontvangen: een geschreven samenvatting van wat de klant wil, de opgehaalde context, de al ondernomen acties, en de concrete reden voor escalatie. Is de overdracht uitstekend, dan kun je de drempels behoudend zetten zonder dat je team ertegen ageert — en behoudende drempels beschermen je CSAT.

De metrieken die ertoe doen

Deflectieratio is het getal dat iedereen rapporteert en het makkelijkst te manipuleren — een agent die onbehulpzaam antwoordt en het ticket sluit, deflecteert prachtig. Volg in plaats daarvan:

Echte oplossingsratio. Percentage geautomatiseerde gesprekken zonder heropening binnen zeven dagen en zonder vervolgvraag over hetzelfde onderwerp. Dit is de eerlijke versie van deflectie.

CSAT, gesegmenteerd. Geautomatiseerd vs. door mensen afgehandeld vs. geëscaleerd. Let vooral op het geëscaleerde segment — scoren geëscaleerde gesprekken lager dan puur menselijke, dan verliest je overdracht context.

Doorlooptijd tot oplossing, niet tot eerste reactie. Automatisering maakt de eerste reactie per definitie direct. Dat is de winst niet. De winst is dat het probleem van de klant sneller opgelost is.

Escalatieprecisie en -recall. Van de geëscaleerde tickets: hoeveel hadden echt een mens nodig? Van de tickets die geautomatiseerd bleven: hoeveel hadden moeten escaleren? Beide richtingen tellen, en de tweede is de gevaarlijke.

Kosten per opgelost ticket. Volledig belast: modelverbruik, infrastructuur, plus de menselijke minuten die er nog in zitten. Dit is het getal dat in de directiepresentatie hoort.

Wat je eerlijk mag verwachten

Voor een typisch D2C-merk met een schone productcatalogus en redelijke systemen:

• Maand 1: WISMO live. 25–35% van het totale volume geautomatiseerd.
• Maand 2: Retouren en terugbetalingen. Cumulatief 45–60%.
• Maand 3–4: Productvragen, zodra het contentwerk landt. Cumulatief 70–80%.
• Maand 6+: Staart, randgevallen, proactieve outreach. 85–92% is waar goed uitgevoerde implementaties uitvlakken.

De laatste 8–15% is geen technologiegat. Het zijn echt nieuwe situaties, echte oordeelskwesties en klanten die een mens willen — en dat hoort zo te blijven. Een operatie die op 100% mikt, optimaliseert het verkeerde getal.

De fout die vrijwel iedereen maakt

Beginnen met de moeilijkste tickets.

Er is een intuïtieve neiging om de gevallen te automatiseren die het team het meest haat — de complexe, beladen, systeemoverstijgende. Ze zijn het meest memorabel en emotioneel het duurst.

Ze zijn ook het laagste in volume, het hoogste in risico, en de slechtst denkbare plek om je eerste agent te bouwen. Begin met de saaie hoogvolumecategorie, krijg de infrastructuur goed, bouw de eval-set, bouw het nauwkeurigheidsdossier op, verdien het vertrouwen van het team. Klim daarna omhoog.

Het team dat de moeilijke tickets haat, wordt veel gelukkiger met die moeilijke tickets zodra het tijd heeft om ze fatsoenlijk te doen — en dat is precies wat het automatiseren van de saaie oplevert.

---

Wij leveren een eerste supportagent binnen 14 dagen na getekende spec, inclusief eval-set en escalatiebeleid. Plan een auditgesprek.