In mijn projecten zie ik keer op keer hoezeer de verwachtingen voor voicebots zijn toegenomen. Veel organisaties gaan ervan uit dat ze binnen een paar weken een volwaardige AI-ondersteunde dienst kunnen opzetten. De realiteit ziet er anders uit. Voicebots kunnen tegenwoordig veel, maar ze hebben een solide basis nodig, duidelijke doelstellingen en organisaties die bereid zijn om in het begin wat meer energie te investeren.
In mijn webinar (alleen in het Duits) als onderdeel van de 16e Customer Service Week heb ik twee projecten gepresenteerd die heel goed laten zien wat er mogelijk is en op welke valkuilen je moet letten. Beide use cases komen uit de publieke sector en hadden hetzelfde doel: het servicecentrum ontlasten en standaardvragen automatiseren. Toch pakten de projecten heel anders uit.
Een voicebot als eerste contactpunt: wat werkt goed en wat niet?
In het eerste project was de uitdaging een zeer hoog aantal telefoontjes. Het personeel werd voortdurend gestoord terwijl het ook burgers ter plaatse moest helpen. Het doel was om de werkdruk met minstens 50% te verminderen.
De autoriteit besloot daarom alle openbare telefoontjes door te verbinden naar een voicebot. Alleen wanneer de bot de vraag niet kon beantwoorden, kon de beller een terugbelverzoek achterlaten. Deze terugbelverzoeken worden als e-mail met een samenvatting en een gedetailleerd transcript naar de mailbox van het personeel van de autoriteit gestuurd, zodat zij deze kunnen afhandelen wanneer ze daar tijd voor hebben.
De aanpak klonk in eerste instantie eenvoudig. Het idee was om de bestaande FAQ-teksten van de website te gebruiken om een bot te bouwen. We zijn daarom begonnen met een klassieke NLU-bot (Natural Language Understanding). De klant wilde geen risico lopen op hallucinaties en stond op een strikt gedefinieerd klanttraject.
Maar juist hier realiseerden we ons hoe uitdagend dit onderwerp eigenlijk is. Website-content wordt niet geschreven voor voicebots. Deze content groeit vaak in de loop van de tijd, met overlappende of onnauwkeurige informatie. Een bot heeft echter duidelijke, ondubbelzinnige en goed gestructureerde informatie nodig. De dialogen voelden stijf aan en zouden bellers niet tevreden hebben gesteld.
De overstap naar een LLM-bot (Large Language Model, LLM) was het echte keerpunt. Het enthousiasme was groot: menselijke dialogen, empathie, verschillende formuleringen. De bot zei "Oh, dat klinkt geweldig" of "Het spijt me dat te horen". De bot kon dezelfde vraag op verschillende manieren beantwoorden en reageerde menselijker zonder buiten de vastgestelde richtlijnen te treden.
Meetbare resultaten
Het resultaat was duidelijk meetbaar. Slechts ongeveer 20% van de oorspronkelijke oproepen resulteerde in terugbelverzoeken voor medewerkers. De meeste gevallen werden netjes opgelost door de bot. Een zeer prettig neveneffect: herhaalde bellers verdwenen omdat de bot geen 'bezet'-signaal heeft. Medewerkers hebben nu veel meer tijd voor burgers ter plaatse. Dit was precies de verlichting waar de klant op had gehoopt.
De bot hangt op bij 15% van de bellers, meestal na succesvolle gesprekken. Tussen 30 en 40% van de bellers hangt zelf op. Hier moesten we de transcripties bekijken om te beoordelen of dit goed of slecht was.
Wat we van dit project hebben geleerd
Personeelszaken
U kunt snel resultaten boeken, maar geen enkel voicebot-project werkt zonder actieve betrokkenheid van de klant. Dit omvat het onderhouden van de kennisbank, het opstellen van een woordenlijst, het testen, het samenstellen van een lexicon met correcte uitspraken voor tekst-naar-spraak en het herzien van de inhoud. Naast een materiedeskundige moet er technische ondersteuning zijn die zorgt voor de API's en kennis heeft van scripting in JavaScript of XML. Er zijn ook testmiddelen nodig. Voor een project van deze omvang hebt u minimaal twee toegewijde contactpersonen aan de klantzijde nodig, idealiter drie.
LLM-kennis
Een ander belangrijk punt is de ingebouwde algemene kennis van de LLM. Een model brengt altijd zijn eigen achtergrondkennis mee. Deze moet actief worden beperkt, zodat het binnen de verstrekte inhoud blijft. Dit werkt goed, maar niet honderd procent. Je moet waar nodig testen, corrigeren en aanpassen.
Natuurlijkheid
Wanneer een burger een vraag stelt, 'denkt' de bot – spraak naar tekst, tekst in de LLM, tekst naar spraak. Deze pauzes moeten worden opgevuld. Typen geluiden, kleine aarzelingen, variaties in volume. Variaties in achtergrondgeluiden helpen om de dialoog natuurlijk te laten klinken.
Barge-in
De meeste botproviders zijn nu ook in staat tot wat bekend staat als 'barge-in', oftewel het onderbreken van de dialoog. De bot moet accepteren dat hij onderbroken kan worden. Als de beller bijvoorbeeld al de informatie heeft gekregen die hij nodig heeft, hoeft hij niet te wachten tot de bot zijn script heeft afgewerkt. Het nadeel is dat achtergrondgeluiden ook als onderbreking kunnen worden geïnterpreteerd, bijvoorbeeld op een perron. Dit kan worden opgelost met gevoeligheidsinstellingen.
Een tweede voorbeeld: wanneer doorschakelen deel uitmaakt van het proces
Het tweede project had ook betrekking op veelgestelde vragen, maar de vereisten waren anders. De bot moest vragen beantwoorden en het servicecentrum ontlasten – het doel was ook 50%. Tijdens de openingstijden moesten oproepen echter indien nodig worden doorgeschakeld naar backend- of contactcentermedewerkers. Er was geen terugbeloptie. Bovendien moest het bestaande Avaya-systeem worden geïntegreerd met betrekking tot het doorsturen van de bot naar de medewerker.
Technische integratie
Technische integratie was een belangrijk aspect. De oproep komt binnen in het callcenter, wordt doorgeschakeld naar de voicebot en moet indien nodig worden teruggestuurd naar een medewerker. De routing-identificatie moet worden verstrekt en teruggekoppeld – via gebruikersinformatie of SIP-headermanipulatie. Dit zorgt ervoor dat de oproep correct wordt weergegeven in de historische rapportage.
We hebben ook de Call Data Service van Parloa geïntegreerd. Het overzicht van het gesprek verschijnt in de Avaya-frontend voordat de medewerker het gesprek aanneemt. Zo kunnen agenten van tevoren zien waar het gesprek over gaat.
Resultaten
Opnieuw hadden we hetzelfde patroon aan het begin: de klant wilde de FAQ's van de website importeren. En opnieuw werkte dit niet. De inhoud moest handmatig worden herzien.
Er werd een doorstuurpercentage van 50% behaald – een gedeeltelijk succes. Idealiter zou doorsturen niet nodig zijn, maar de andere 50% werd met succes geautomatiseerd.
Er was een hang-up percentage van 10% door de bot – een succes na het bekijken van de transcripties. 40% hang-up percentage door de klant – dit moet nader worden bekeken. Is het een succes of niet? De transcripties moeten opnieuw worden gecontroleerd en de gesprekken moeten worden bekeken. Een optie is om aan het einde van het gesprek in de bot een tevredenheidsenquête uit te voeren.
Lessen die zijn geleerd uit het tweede project
Benodigde tijd
Het project duurde drie maanden. Dat werkte goed. Het ontwerp, de configuratie en de technische tests aan onze kant kostten ongeveer 20 mandagen.
Personeelszaken
We hadden hier te weinig klantmiddelen. Dit leidde tot extra werk voor ons dat niet gepland was.
Opt-in
Een belangrijk punt voor beide bots. De burger moet toestemming geven voor de opname. De bot neemt altijd alles op – volledige transcripties zijn altijd beschikbaar, ongeacht of ze na 7 of 30 dagen worden verwijderd.
De opt-in moet worden aangevraagd. Burgers moeten ook de mogelijkheid hebben om te zeggen: "Nee, ik wil hier niet doorgaan." Of ze kunnen doorgaan – en, zoals we in het eerste geval hebben gezien – om een terugbelverzoek vragen en slechts minimale informatie over zichzelf verstrekken.
Hier kan het zinvol zijn om te beginnen met NLU, d.w.z. de gestructureerde aanpak, en vervolgens door te gaan met de LLM-Agentic-aanpak om ervoor te zorgen dat opt-in correct wordt afgehandeld. Bij een volledige LLM-start kan deze stap onbedoeld worden overgeslagen.
Wat we van beide projecten hebben geleerd
Voicebots zijn tegenwoordig krachtige tools. Maar het zijn geen plug-and-play-producten. Om succesvol te zijn, moet je drie dingen serieus nemen.
Ten eerste: inhoud. Een bot is slechts zo goed als de kennisbasis die je hem geeft. Website-teksten kunnen bijna nooit ongewijzigd worden gebruikt. Ze moeten worden herzien en gestructureerd.
Ten tweede: middelen. Zonder deskundigen aan de kant van de klant die de inhoud testen, corrigeren en onderhouden, zal het project traag en moeilijk verlopen.
Ten derde: verwachtingsmanagement. Er is bijna altijd een fase waarin de kwaliteit nog niet voldoende is. Als je blijft verbeteren, stijgt de kwaliteit snel. In beide projecten hebben we uiteindelijk hoge succespercentages en tevreden bellers behaald.
Conclusie
Voicebots zijn een echte uitkomst als ze correct zijn ingesteld. De technologie is volwassen, maar vereist een zorgvuldige implementatie. Als content, testen en samenwerking goed worden aangepakt, bereikt u een punt waarop de meeste vragen geautomatiseerd worden en teams meer tijd hebben voor zaken die echt menselijke aandacht vereisen.
