AI-telefonie: de acceptatietest voor je pilot
Een praktische pilotopzet voor AI-telefonie: toets eerste antwoord, onderbreken en een afgeronde escalatie voordat je meer belvolume toevoegt.
Ook beschikbaar in het Engels: AI voice support pilot: the acceptance tests that matter
Een stempilot is geen korte demo met een welwillende beller. Het is een gecontroleerd bewijs dat een klant gehoord wordt, veilig kan onderbreken en niet strandt bij een doorverbinding. Begin met één afgebakend beldoel, een bezette overdrachtsbestemming en een vooraf afgesproken stopvoorwaarde. Zo beslist het team op basis van bewijs in plaats van op basis van enkele opvallende gesprekken.
Waarom de acceptatiegrens hoger ligt
Op 2 september 2026 kondigde Genesys updates voor virtual agents aan. Dat is marktcontext, geen bewijs dat een afzonderlijke implementatie klaar is. De praktische les: toets de hele belroute, inclusief het moment waarop automatisering stopt, en niet alleen een los antwoord.
Wie CustomerEagle AI Voice evalueert, vraagt toegang aan en behandelt de pilot als een private-beta-evaluatie. Het product ondersteunt geconfigureerde begeleide scenario’s, transfers, belhistorie en kwaliteitscontroles, maar configuratie, informatie aan bellers en lokale tests blijven releasegrenzen. Leid geen direct live telefoonnummer, algemene beschikbaarheid, opnamebeschikbaarheid of responstijdsgarantie af uit een marketingpagina.
Kies één beldoel en een kleine matrix
Kies een doel met een duidelijke afloop: openingstijden, afspraaktriage, routering van orderstatus of een bekende set veelgestelde vragen. Begin niet met klachten, betalingswijzigingen of identiteitsgevoelig werk. Noteer vóór het eerste gesprek de bellersintentie, toegestane kennis, verboden acties, overdrachtsbestemming en de exacte fallbackzin.
| Test | Wat de beller doet | Wat je vastlegt |
|---|---|---|
| Eerste antwoord | Stelt na de disclosure een bekende vraag | Tijd tot eerste bruikbare audio; blijft het antwoord binnen goedgekeurde kennis? |
| Onderbreking | Praat tweemaal door de assistent heen, vroeg en laat in een uiting | Stopt oude audio, wordt de nieuwe intentie vastgelegd en is de volgende beurt relevant? |
| Escalatie | Vraagt om een mens en herhaalt dat na een mislukte overdracht | Bereikte bestemming, meegegeven context, fallbacktekst en eindstatus van het gesprek |
| Onzekere vraag | Vraagt naar informatie die niet in de goedgekeurde bron staat | Heldere beperking, geen verzonnen antwoord en een bruikbare volgende stap |
Gebruik je eigen drempels. Een doel krijgt pas betekenis als duidelijk is wie een misser oplost en of de pilot dan pauzeert.
Meet latentie als gesprekservaring
Een snelle eerste begroeting kan een trage tweede beurt verbergen. Leg daarom twee tijden vast: verbinding tot eerste hoorbare reactie, en einde van de spraak van de beller tot de volgende antwoordaudio. Noteer naast elke uitschieter de omstandigheden: netwerk, providerstatus, toolopvraag en eventuele onderbreking. Bekijk een percentiel pas als je voldoende vergelijkbare gesprekken hebt; een mediaan verbergt juist de stiltes die klanten onthouden.
Luister ook naar stiltes die telemetrie geen naam geeft. Een lange pauze na een onderbreking, een afgekapt bevestigingswoord of een antwoord dat start terwijl de beller nog praat kan technisch geslaagd zijn en toch kapot voelen. Laat de tester vastleggen of hij wist wat de volgende stap was. Dat kwalitatieve veld is bewijs, een aanvulling op de meetgegevens.
Toets onderbreken als veiligheidsfunctie
Barge-in is geen afwerking. Een beller onderbreekt wanneer hij corrigeert, ongeduldig wordt of iets urgents hoort. Doe één onderbreking voordat de assistent bij de kern is en één vlak voor het einde. De verwachte volgorde is eenvoudig: de eerdere audio stopt, de beller wordt gehoord, en de assistent beantwoordt de nieuwe intentie of stelt één korte verduidelijkingsvraag. Speelt het oude script door, dan is de pilot niet geslaagd.
Bewijs dat escalatie wordt afgerond
Dit is iets anders dan een algemeen overdrachtsbeleid. Een beltest moet de live overgang bewijzen: de beller vraagt om een mens, de gekozen bestemming gaat over, de ontvangende persoon heeft voldoende context en de beller krijgt een veilige reactie als niemand opneemt. Test bewust een onbereikbare bestemming. Een transfer die alleen een record maakt, eindeloos overgaat of de beller terug in dezelfde lus zet, faalt.
Gebruik dezelfde intentieregels als in je playbook voor AI-naar-mens-overdracht, maar voeg verantwoordelijkheid voor telefonie toe: wie heeft dienst, welke bestemmingen zijn na werktijd geldig en wie wijzigt routing tijdens een incident. Een warme transfer heeft alleen waarde als het ontvangende team met de context kan handelen.
Beoordeel bewijs vóór je opschaalt
- Bewaar de lijst met testgesprekken, transcript of notities, tijdmetingen en uitkomst in één reviewsheet.
- Groepeer missers op oorzaak: ontbrekende bron, audio-onderbreking, routing, transferbestemming of onduidelijke disclosure.
- Los één oorzaak op, herhaal de betreffende casus en noteer de geteste prompt- of scenarioversie.
- Pauzeer uitbreiding bij stille gesprekken, herhaalde transferlussen, onveilige antwoorden of ontbrekend auditbewijs.
- Voeg pas een tweede beldoel toe wanneer het eerste een eigenaar, fallback en herhaalbare resultaten heeft.
Koppel daarna het beldoel aan je kennisbank en productmogelijkheden en routingregels. Voor de bredere implementatiekeuze kun je AI-supportprijzen bekijken.
Hoeveel gesprekken moet een pilot voor AI-telefonie bevatten?
Gebruik genoeg gesprekken om elke kritieke situatie onder normale en foutomstandigheden te herhalen, niet een indrukwekkend klinkend aantal. Een kleine matrix met gedocumenteerde hertests is nuttiger, omdat die laat zien of een oplossing de uitkomst werkelijk veranderde.
Is een geslaagd transferverzoek genoeg voor een escalatietest?
Nee. De test slaagt pas wanneer de beller een echt persoon bereikt of de afgesproken veilige fallback krijgt, met genoeg context voor de volgende stap. Test ook een onbeantwoorde bestemming, want daar ontstaan meestal lussen, stiltes en misleidende beloften.
Welke latentie mogen we aan bellers beloven?
Publiceer geen belofte voordat je de beoogde belroute onder realistische omstandigheden hebt gemeten. Kies een interne acceptatiegrens, rapporteer de verdeling en onderzoek lange pauzes. Provider, netwerk, tools en transfers kunnen allemaal de ervaring beïnvloeden.
Waarom onderbreken testen vóór je meer kennis toevoegt?
Onderbreken is een controle die de beller beschermt wanneer het systeem fout, te lang of op het verkeerde spoor zit. Meer kennis repareert geen gesprek waarin oude audio doorspeelt en de beller het woord niet terugkrijgt, dus bewijs die controle eerst.
Los meer tickets automatisch op.
Kijk hoe eerlijk gemeten AI-resoluties je supportdruk verlagen — begin op het gratis plan, zonder creditcard en zonder verkoopgesprek.