Uitgewerkt voorbeeld. Dit is een illustratief uitgewerkt voorbeeld, geen klantresultaat: het supportteam en zijn cijfers zijn aannames. Het laat retrieval aan de agentkant zien, een tool die achter de supportmedewerker zit, niet voor de klant. De medewerker stelt een vraag in gewone taal, krijgt een antwoord met bron, blijft in het ticket en verstuurt de reactie.
Stel je een mid-market e-commerce cx-team voor dat de eerste-reactietijd op complexe tickets wil verbeteren. Dit artikel behandelt waaruit het ontwerp bestaat, wat je meet en wat het niet doet. Het meldt geen resultaat, omdat er geen klant achter zit.
Het team is hypothetisch, en elk cijfer dat je hier zou verwachten ook. Het ontwerp steunt op het supportwerk dat we beschrijven op /ai-for/customer-support. Nog iets vooraf: het is alleen agent-assist. Op geen enkel moment praat een chatbot met een klant.
#Wat vertraagde de medewerkers?
De antwoorden bestaan. Ze vinden schaalt niet. Een complex ticket betekent dat een medewerker de zendesk-historie, een productdocument en een PDF met verzendbeleid opent en het antwoord met de hand in elkaar zet. Jaren aan eerdere tickets bevatten het precedent, en niemand kan dat archief 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 klantsupport verkorten zonder chatbot?
Ja, dat is het doel. Een interne retrieval-tool laat medewerkers in gewone taal vragen stellen over historische tickets, productdocumenten en beleids-pdf's en geeft één antwoord met bron. De medewerker schrijft en verstuurt de reactie nog steeds zelf. Een team zou de eerste-reactietijd op complexe tickets vóór en na meten, zonder klantgerichte bot.
#Waaruit bestaat het ontwerp?
één interne retrieval-tool over drie bronnen: 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 alle 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 hoort bij het ontwerp, het is geen overdracht aan het eind. De KPI om af te spreken is de eerste-reactietijd op complexe tickets, vóór en na gemeten. Wat het in beweging brengt, moeten je eigen data zeggen, niet dit artikel.
#Is dit niet hetzelfde als een deflectiebot?
Nee, en het verschil is precies het punt. Een deflectiestrategie probeert het ticketvolume te verlagen door klanten rechtstreeks te antwoorden. Dit ontwerp mikt op een ander getal: de eerste-reactietijd, door retrieval achter de medewerker te zetten. De klant praat nog steeds met een mens.
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 de suggesties van gorgias werken binnen hun eigen muren: je macro's, je helpartikelen, je opgeslagen antwoorden. Dit ontwerp voegt retrieval toe over de rest. De historische tickets, de productdocumenten, de PDF's met verzendbeleid, de runbooks. Daar zitten de antwoorden op complexe tickets verstopt.
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? Jaren aan tickets, een stapel beleids-pdf's, productdocumenten die veranderen. Als medewerkers minuten verliezen met zoeken vóór elke complexe reactie, is dat de tijd die retrieval moet teruggeven.
Dit ontwerp hoort bij ons ai-consultancy-werk, met de training van het supportteam meegenomen vanuit onze ai-training-kant. Wil je zien hoe de stukken in elkaar passen, dan staan er meer uitgewerkte voorbeelden als dit in het journal.
Als je medewerkers vóór elke complexe reactie naar antwoorden zoeken, is dat de vertraging waar dit ontwerp op mikt. vertel ons wat je bouwt en we zeggen je of retrieval de juiste hefboom is, of niet.
