Een AI voice agent test je door gesprekken door de hele keten te sturen voordat hij één klant te woord staat: de telefoonlijn, de spraakherkenning, elke tak van de flow, de systemen waaruit hij leest en waarin hij schrijft, en de overdracht naar een medewerker. Schrijf per testgesprek op wat er moet gebeuren, vergelijk dat met wat er echt gebeurde, los het op en draai de set opnieuw. Herhaal dezelfde set na elke wijziging in de flow, want een aanpassing in de ene stap kan een andere stap breken. Een demo in de browser bewijst het idee. Alleen testgesprekken via een echte telefoonlijn bewijzen dat de agent klaar is voor je bellers.

Kort samengevat: wat een testplan afdekt

• De hele keten, niet alleen het gesprek: audio, herkenning, flowlogica, backend, gesproken antwoord en overdracht.
• Een testset uit echte gespreksredenen, met de randgevallen er bewust in.
• Een vastgelegd slaagcriterium per testgesprek, gecontroleerd in de backend en niet alleen op gehoor.
• Regressietests na elke wijziging, in een testomgeving, voordat de wijziging bij bellers terechtkomt.
• Een periode van meekijken na de livegang, waarin afgeronde, doorverbonden en afgebroken gesprekken per stap laten zien wat de tests hebben gemist.

Waarom een voice agent testen anders is dan een chatbot testen

Een chatbot krijgt nette tekst binnen. Een voice agent krijgt een telefoongesprek, en het meeste dat misgaat, gebeurt voordat het taalmodel één woord ziet.

• Telefoonaudio is smalband. De documentatie van Google Speech-to-Text zegt dat “most legacy telephony audio, for example, use sample rates of 8000 Hz, which may give less accurate results”, en raadt aan audio aan te leveren op de oorspronkelijke samplefrequentie in plaats van die om te zetten (Google Cloud). Een test in de browser, met een goede microfoon, verbergt dat.
• Bellers pauzeren, onderbreken en praten door de agent heen. Het systeem moet bepalen wanneer een beller begint en stopt met praten. Spraakdiensten geven dat door als voice activity events, met time-outs voor als er geen spraak begint of eindigt (Google Cloud). Of je flow goed omgaat met een lange stilte of een beller die onderbreekt, zie je alleen in een gesprek.
• Stilte valt op. Alleen al voor netwerkvertraging noemt de ITU-richtlijn die Cisco aanhaalt tot 150 ms enkele reis acceptabel voor de meeste toepassingen (Cisco, over ITU-T G.114). Herkenning, redeneren en spraaksynthese tellen daar nog bij op. Waarom dat ertoe doet, lees je in latency in AI Voice Agents.
• De agent werkt met live data. Hij verifieert bellers, zoekt dossiers op en schrijft uitkomsten terug. Een gesprek dat perfect klonk maar het verkeerde dossier wijzigde, is mislukt.

Twijfel je nog tussen een tekst- en een spraakkanaal, dan zet AI Voice Agent versus chatbot de verschillen op een rij.

Wat test je: zes lagen van de keten

Laag	Wat gaat er mis	Zo test je het	Geslaagd als
Telefoonlijn en audio	Echo, afgekapte eerste woorden, slechte kwaliteit op mobiel	Bel in vanaf een vaste lijn, een mobiel met zwak bereik en een rumoerige ruimte	Het eerste woord van de begroeting en van de beller gaat nooit verloren
Spraakherkenning	Namen, nummers, postcodes, datums en kentekens verkeerd verstaan	Spreek de lastige invoer uit, met verschillende accenten en snelheden	De waarde die de agent terugleest, klopt met wat de beller zei
Intentie en flow	Verkeerde gespreksreden herkend, een tak die rondloopt of doodloopt	Eén testgesprek per tak, plus bellers die halverwege van onderwerp wisselen	Elke tak komt uit bij de eindtoestand die ervoor bedoeld is
Backend en CRM	Verkeerd dossier gevonden, niets teruggeschreven, time-outs	Testklanten in een testomgeving, ook een klant die niet bestaat	De backend toont precies de wijziging die het gesprek moest maken
Overdracht	Context kwijt, naar het verkeerde team, beller moet alles herhalen	Vraag in verschillende stappen om een medewerker en activeer de terugvalroutes	De collega ziet wie er belt en waarom, voordat die “goedemorgen” zegt
Gesproken antwoord en timing	Lange stiltes, verkeerde uitspraak, door de beller heen praten	Luister opgenomen testgesprekken van begin tot eind terug	Geen stilte die een beller opvalt, elke naam en elk nummer goed uitgesproken

De lastige invoer verdient eigen tests. Hoe een voice agent daarmee omgaat, lees je in de artikelen over adresvalidatie, kentekenherkenning, datums en bellers verifiëren.

Bouw de testset uit echte gesprekken

De beste testset begint bij de redenen waarom klanten nu bellen, niet bij het flowdiagram.

1. Zet je belangrijkste gespreksredenen op een rij en de manier waarop bellers ze verwoorden, inclusief omwegen en halve zinnen. Overleg met je privacyfunctionaris welke opnames en transcripties je daarvoor mag gebruiken.
2. Schrijf per reden een gewoon verloop uit, en daarna de randgevallen: een onbekend klantnummer, twee vragen in één gesprek, een beller die zichzelf verbetert, stilte, “ik wil iemand spreken”, een backend die niet antwoordt.
3. Gebruik testdata, geen productiedossiers. Maak testklanten aan in een testomgeving, zodat een mislukte test geen echt klantaccount kan wijzigen.
4. Zet naast elk testgesprek het verwachte resultaat: welke tak, welke waarde vastgelegd, wat er naar welk systeem is geschreven en hoe het gesprek eindigt.
5. Laat collega’s uit de klantenservice meebellen. Zij weten hoe klanten praten en vinden de plekken waar de flow wringt sneller dan de mensen die hem bouwden.

Meet de herkenning waar het telt

Voor spraakherkenning bestaat een standaardmaat: de word error rate (WER). De documentatie van Microsoft definieert die als het aantal ingevoegde, weggelaten en vervangen woorden gedeeld door het aantal woorden in een door mensen gemaakt transcript. Een WER van 5 tot 10% noemt Microsoft goede kwaliteit, 20% acceptabel en 30% of meer slecht. Om hem te meten heb je audio met door mensen gemaakte transcripties nodig, en Microsoft adviseert 30 minuten tot 5 uur representatieve audio (Microsoft Learn).

Voor een voice agent zegt de totale WER minder dan de nauwkeurigheid op de woorden waar de flow op leunt. Een verkeerd verstaan stopwoord kost niets. Een verkeerd verstaan cijfer in een polisnummer stuurt het gesprek de verkeerde kant op. Beoordeel de waarden die de agent aan de beller terugleest daarom apart.

Slaagcriteria: leg ze vast voordat je test

Een test zonder vastgelegd verwacht resultaat wordt een mening. Leg per testgesprek vast:

• Uitkomst: afgerond door de agent, doorverbonden naar een medewerker, of afgebroken. Dat zijn dezelfde drie uitkomsten die je volgt zodra de agent live is.
• Route: volgde het gesprek de tak die het moest volgen?
• Data: klopt de vastgelegde waarde, en klopt de wijziging in de backend?
• Overdracht: als het gesprek werd doorverbonden, kwam de context dan bij het juiste team aan?
• Beleving: een stilte, herhaling of verkeerde uitspraak die een beller zou opvallen?

Bepaal vooraf wat moet slagen voor de livegang. De meeste teams zien een verkeerde wijziging in de backend of een overdracht zonder context als blokkerend, en een wat onhandige formulering als iets voor de volgende release.

Test opnieuw na elke wijziging

Gespreksredenen veranderen, en flows dus ook. Een nieuwe tak voor de ene gespreksreden kan veranderen hoe de agent een andere herkent. Daarom draait dezelfde testset na elke wijziging opnieuw:

1. Maak de wijziging in een testomgeving, nooit direct op de live lijn.
2. Draai de volledige regressieset, niet alleen de tests voor de stap die je hebt aangepast.
3. Vergelijk met de laatste goedgekeurde run. Een test die eerst slaagde en nu faalt, bekijk je als eerste.
4. Keur goed en zet dan live, en weet hoe je teruggaat naar de vorige versie als de live cijfers iets anders zeggen.

Hoe een releaseproces voor voice agents kan werken, met versies en een weg terug, lees je in versiebeheer voor AI-agenten.

Compliancechecks horen in de testset

• Laat je openingsbericht (melden dat de beller met AI spreekt, opname van het gesprek) vóór de livegang checken door je juridische of privacyteam.

Na de livegang: laat echte gesprekken zien wat de tests misten

Geen testset is compleet. Begin met één gespreksreden of een deel van de bellers, en breid uit als de cijfers kloppen. Kijk in de eerste weken per stap van de flow hoeveel gesprekken zijn afgerond, doorverbonden en afgebroken: de stap waar bellers ophangen of om een medewerker vragen, is waar je testset een gat had. Voeg die gesprekken toe aan de regressieset. Hoe je die cijfers leest, staat in zo meet je een voice agent.

Veelgestelde vragen

Hoe test je een AI voice agent? Bel hem via een echte telefoonlijn met een testset uit je eigen gespreksredenen. Schrijf per testgesprek op welke tak het moet volgen, welke waarden moeten worden vastgelegd, wat er in de backend moet veranderen en hoe het gesprek moet eindigen, en vergelijk dat met wat er gebeurde. Test het gewone verloop en de randgevallen van elke stap, en herhaal de set na elke wijziging.

Hoeveel testgesprekken heb je nodig voor de livegang? Tel dekking, geen gesprekken. Elke tak van de flow heeft minstens één gewoon verloop en de bijbehorende randgevallen nodig, elke lastige invoer (namen, nummers, datums) tests met verschillende stemmen, en elke route naar een medewerker een overdrachtstest. Voor herkenningsnauwkeurigheid adviseert Microsoft 30 minuten tot 5 uur representatieve audio met door mensen gemaakte transcripties.

Kun je een voice agent testen zonder echte klantdata? Ja, en dat moet je ook doen. Gebruik testklanten in een testomgeving, zodat een mislukte test geen echt klantaccount kan wijzigen. Echte gespreksopnames helpen om realistische testzinnen te maken; overleg met je privacyfunctionaris welke opnames en transcripties je mag gebruiken.

Wat test je opnieuw na een wijziging in de flow? De hele regressieset, niet alleen de gewijzigde stap. Een nieuwe tak of prompt kan veranderen hoe de agent andere gespreksredenen herkent, dus vergelijk elk resultaat met de laatste goedgekeurde run voordat de wijziging live gaat.

Wat is het verschil tussen een voice agent testen en monitoren? Testen gebeurt voordat bellers er iets van merken, met gesprekken die je zelf hebt ontworpen en verwachte resultaten die je hebt vastgelegd. Monitoren gebeurt na de livegang, op echte gesprekken: afgerond, doorverbonden en afgebroken per stap van de flow. Monitoren laat zien wat je testset miste, en die gesprekken gaan terug de testset in.

Zo testen teams op AssistYou

AssistYou is het platform waarmee klantenserviceteams betrouwbare AI voice agents bouwen, en ons team helpt je bij het opzetten. Je team ontwerpt en past de flow aan in de Flow Designer en ziet elk gesprek in de portal, en elke wijziging wordt getest voordat hij live gaat. Na de livegang laat Agent Statistics zien hoeveel gesprekken de AI Voice Agent heeft afgerond, doorverbonden of afgebroken, met de uitval per stap direct op de flow in de Flow Designer. Bekijk de productpagina, of neem contact op met ons salesteam om een testplan voor je eigen gespreksredenen door te lopen.

← Terug naar blog