interne retrieval. een tool die achter de supportmedewerker zit, niet voor de klant. de medewerker stelt een vraag in gewone taal en krijgt in één zoekopdracht een antwoord met bron. geen klantgerichte bot. de medewerker blijft in het ticket en verstuurt de reactie.
we bouwden er een voor een mid-market e-commerce cx-team. de eerste-reactietijd op complexe tickets daalde met 40%. dit artikel is het bewijs: wat we bouwden, wat er veranderde, en wat niet.
de klant is geanonimiseerd. de 40% is het geleverde resultaat van het traject, gebaseerd op het customer-support-werk dat we beschrijven op /ai-for/customer-support. nog één ding vooraf: dit was uitsluitend medewerkersondersteuning. geen chatbot sprak op enig moment met een klant.
#wat vertraagde de medewerkers?
de antwoorden bestonden al. ze vinden schaalde niet mee. een complex ticket betekende dat een medewerker de zendesk-geschiedenis, een productdocument en een pdf met verzendbeleid opende, en dan het antwoord handmatig samenstelde. vier jaar aan eerdere tickets bevatte het precedent. niemand kon vier jaar aan tickets doorzoeken in de tijd dat een klant wacht.
dus de eerste reactie bleef in de wachtrij staan terwijl de medewerker aan het zoeken was. die wachttijd is het cijfer waar de supportlead naar wordt gevraagd. eerste-reactietijd, niet ticketvolume.
kan ai de eerste-reactietijd in customer support verlagen zonder chatbot?
ja. een interne retrieval-tool laat medewerkers vragen in gewone taal stellen over historische tickets, productdocumenten en beleids-pdf's, en krijgt daar één antwoord met bron voor terug. de medewerker schrijft en verstuurt de reactie zelf nog steeds. bij één mid-market e-commerce cx-team verlaagde dit de eerste-reactietijd op complexe tickets met 40%, zonder klantgerichte bot.
#wat hebben we precies opgeleverd?
één interne retrieval-tool over drie bronnen: 4 jaar historische tickets, de productdocumenten en de pdf's met verzendbeleid. een medewerker typt een vraag zoals hij die aan een senior collega zou stellen. het antwoord komt terug met de bron erbij, zodat de medewerker het kan checken voordat het naar een klant gaat.
- doorzoek 4 jaar aan eerdere tickets in één zoekopdracht, niet tabblad voor tabblad.
- antwoorden met bron, zodat de medewerker de bron checkt in plaats van een zwarte doos te vertrouwen.
- antwoorden gebaseerd op de pdf's met verzendbeleid, waar de uitzonderingsregels echt staan.
- de medewerker blijft in het ticket. de tool reageert nooit zelfstandig naar een klant.
het trainen van het supportteam maakte deel uit van de bouw, geen overdracht achteraf. de kpi die we afspraken te verbeteren was de eerste-reactietijd op complexe tickets. we maten die ervoor en erna. hij daalde met 40%.
#is dit niet hetzelfde als een deflectiebot?
nee, en dat verschil is precies het punt. een deflectiestrategie probeert het ticketvolume te verlagen door klanten rechtstreeks te antwoorden. dit veranderde een ander cijfer. de metriek was de eerste-reactietijd, bereikt door retrieval achter de medewerker te zetten. de klant sprak nog steeds met een persoon.
we are
stennir bouwt ai die achter je supportmedewerkers zit: retrieval, triage, opstellen-en-beoordelen, gemeten aan eerste-reactietijd en oplossingskwaliteit.
we aren't
stennir is geen leverancier van klantgerichte chatbots en verkoopt deflectie niet als doel; de medewerker blijft in het ticket en je klanten blijven met mensen praten.
tools zoals zendesk ai, intercom fin of gorgias suggestions werken binnen hun eigen muren: je macro's, je helpartikelen, je opgeslagen antwoorden. wij bouwden retrieval over de rest. de historische tickets, de productdocumenten, de pdf's met verzendbeleid, de runbooks. daar verstoppen de antwoorden op complexe tickets zich.
de kpi's die we verbeteren zijn eerste-reactietijd en oplossingskwaliteit op complexe tickets, niet headcount. dat zeggen we op dag één, en we meten het.
#zou dit werken voor ons supportteam?
de fit-test is simpel. staan je antwoorden al op plekken die traag te doorzoeken zijn? vier jaar aan tickets, een stapel beleids-pdf's, productdocumenten die veranderen. als medewerkers minuten verliezen met zoeken vóór elke complexe reactie, is dat de minuut die retrieval teruggeeft.
deze bouw hoort bij ons consultancy-werk, met de training van het supportteam meegenomen vanuit onze training-kant. wil je zien hoe de stukken in elkaar passen, dan vind je meer van dit soort bewijs in het journal.
als je medewerkers vóór elke complexe reactie op zoek zijn naar antwoorden, is dat de 40% waar we hier achteraan gingen. vertel ons wat je aan het bouwen bent en we vertellen je of retrieval de hefboom is, of niet.