journal

hoe een supportteam van 18 medewerkers een derde van zijn tickets oploste zonder chatbot

we bouwden interne retrieval plus opstellen-en-beoordelen voor een mid-market e-commerce cx-team. ~32% van terugkerende tickets opgelost bij eerste aanraking. geen chatbot.

oliver r.founding engineer··4 min lezen

de build. we bouwden twee dingen voor een mid-market e-commerce supportteam van ongeveer 18 medewerkers: interne retrieval over 4 jaar historische tickets, productdocs en verzendbeleid, plus een assistent die antwoorden opstelt voor beoordeling. medewerkers kregen snellere, goed onderbouwde antwoorden. ongeveer 32% van de terugkerende tickets bereikte geen tweede medewerker meer.

er werd geen klantgerichte chatbot gebouwd. het team had er jaren geleden één uitgezet en wilde hem niet terug. de afname komt doordat medewerkers bij het eerste antwoord al de juiste reactie geven, niet doordat een bot klanten bij de deur onderschept.

de cijfers waar een supportverantwoordelijke om geeft: eerste-responstijd op complexe tickets daalde met 40%, en ongeveer 32% van terugkerende 'waar is mijn bestelling'- en beleidsvragen werd bij eerste aanraking opgelost via een voorgesteld antwoord in plaats van doorgestuurd. het afnamecijfer komt uit de eigen tickettag-baseline van het team, niet uit een schatting van een leverancier.

#wat is ai-ticketafname als er geen chatbot is?

wat is ai-ticketafname voor supportteams zonder chatbot?

het betekent dat een terugkerend ticket bij het eerste antwoord wordt opgelost in plaats van te stuiteren tussen medewerkers of te escaleren. hier haalde interne retrieval het juiste beleid en de eerdere oplossing op, en schreef een assistent een onderbouwd antwoord dat de medewerker aanpaste en verzond. de klant sprak nog steeds met een mens.

de meeste 'afname'-pitches bedoelen dat een bot antwoordt zodat de klant nooit een persoon bereikt. dat is niet wat hier gebeurde. een 'waar is mijn bestelling'-vraag die vroeger werd doorgezet naar een senior medewerker, wordt nu correct beantwoord door de eerste medewerker — omdat de assistent het verzendbeleid en de drie meest vergelijkbare eerdere tickets met hun oplossingen toont.

#wat bouwden we precies voor het supportteam?

twee onderdelen, beide intern. retrieval over de eigen geschiedenis van het team, en een antwoordassistent die er concepten op baseert. niets wat de klant ziet, niets dat automatisch wordt verzonden.

  • interne retrieval: indexeert 4 jaar afgehandelde tickets, de productdocs en het verzend- en retourbeleid. als een medewerker een ticket opent, toont het de meest vergelijkbare eerdere gevallen en de exacte beleidsclausule, met een link naar de bron.
  • opstellen en beoordelen: schrijft een eerste conceptantwoord in de toon van het team, met vermelding van het gebruikte beleid. de medewerker past het aan en verstuurt. niets vertrekt zonder dat een mens op verzenden drukt.
  • tagging: elk voorgesteld antwoord wordt gelogd bij de tickettag, zodat het team ziet welke categorieën afnemen en welke nog een persoon nodig hebben.

we are

een interne retrieval- en conceptlaag die elke medewerker een onderbouwd eerste antwoord geeft om te bewerken, zodat terugkerende tickets bij eerste aanraking door een mens worden opgelost.

we aren't

een klantgerichte chatbot die mensen bij het helpwidget onderschept en antwoorden geeft op basis van een geraden kennisbank voordat ze een persoon bereiken.

het geciteerde-bron-onderdeel is wat medewerkers vertrouwen gaf. een concept dat zegt 'volgens het retourbeleid bijgewerkt in maart 2026 worden artikelen gratis verzonden boven $50' met een link slaat een zelfverzekerde gok. dit is hetzelfde patroon dat we beschreven in ticket triage: het systeem leest en stelt op, de medewerker beslist.

#waarom verkorting van de eerste responstijd ook tickets vermindert?

omdat een verkeerd of vaag eerste antwoord het tweede en derde ticket veroorzaakt. een klant vraagt waar zijn bestelling is, krijgt een generiek 'we kijken ernaar', en schrijft twee keer terug. elk vervolg is een nieuwe aanraking voor het team.

wanneer de eerste medewerker correct antwoordt met de trackingstatus en het feitelijke beleid, sluit de thread. de eerste responstijd op complexe tickets daalde 40%, en de herhaalde vervolgvragen die vroeger opstapelden achter een zwak eerste antwoord, bleven weg. daar kwam het grootste deel van de 32% vandaan.

we verminderen niet het contact met klanten. we verminderen het tweede en derde ticket dat een slecht eerste antwoord vroeger veroorzaakte.

de supportverantwoordelijke van het team

#hoe lang duurde het voor de afname zichtbaar werd?

niet in week één. de eerste twee weken toonde de retrieval te veel losjes gerelateerde eerdere tickets, en medewerkers stopten met het lezen van de suggesties. we besteedden die tijd aan afstemmen welke historische gevallen telden en het ruis wegknippen zodat de top drie echt de meest verwante was.

de afnamecijfers hielden stand tegen week 5, zodra medewerkers de topsuggesties genoeg vertrouwden om er mee te openen. dit engagement heeft dezelfde vorm als de rest van ons customer-support-werk: interne retrieval, triage en opstellen-en-beoordelen, training voor het team ingebakken zodat zij de workflow bezitten en niet alleen de tool. meer build-in-public-verslagen staan in het journal.

als je een supportteam runt en afweegt of ai de responstijd kan verkorten en terugkerende tickets kan verminderen zonder een bot tussen jou en je klanten te zetten, is het eerlijke antwoord ja, en het ziet er zo uit: onderbouwde concepten, een mens op elk verzendmoment, je eigen ticketgeschiedenis doet het werk. dat is de versie die wij bouwen. vertel ons wat je wilt bouwen.

terug naar journal
build in publiccustomer supportticket deflectioncase studyfirst response time

vertel ons wat jeopgeleverd wilt hebben.

plan een gesprek van 30 min