Het korte antwoord: accepteer bewijs, niet een indruk
Wil je een chatbot acceptatietest opstellen, begin dan niet met honderd losse vragen. Kies eerst de ene klanttaak die live moet, schrijf de grenzen op en maak een kleine set normale, afwijkende en mislukte scenario’s. Leg bij ieder scenario vast wat de bezoeker zegt, welke bron nodig is, welk gedrag mag variëren, welke actie verboden is, wat het systeemresultaat hoort te zijn en wanneer een medewerker overneemt. Op chatbot laten maken staat de commerciële route; deze gids maakt het opleveringsbewijs controleerbaar.
Een vloeiend antwoord is maar één waarneming. De chatbot kan inhoudelijk aardig klinken en toch een verkeerde bron gebruiken, een onzekere conclusie als feit presenteren, een dubbele lead schrijven of de bezoeker vasthouden wanneer menselijk contact nodig is. Accepteer daarom vijf bewijsniveaus apart: inhoud, bron, gedragsgrens, systeemactie en menselijke overdracht. Het go-no-go-besluit kijkt naar de hele keten zonder te verbergen waar een bevinding zit.
Schrijf eerst het taakcontract dat je werkelijk test
Benoem gebruiker, startsignaal, gewenste uitkomst en bewuste uitsluitingen. “Bezoekers helpen” is niet toetsbaar. “Een ondernemer met een vraag over een eerste chatbotroute naar de juiste uitleg leiden of met context aan een medewerker overdragen” is dat wel. Noteer welke informatie de bot mag verzamelen, welke bron leidend is, welke beslissing bij een mens blijft en welke externe handeling de eerste versie niet uitvoert.
Koppel ieder scenario aan een versie van instructies, kennis, koppelingen en kanaal. Zonder versie kun je een geslaagde hertest niet aan dezelfde oplevering verbinden. Wijs ook vooraf de beoordelaars aan: een proceseigenaar voor de zakelijke route, een inhoudseigenaar voor bronnen, een systeemeigenaar voor writes en een ontvangende medewerker voor overdracht. De bouwer kan herstellen en adviseren, maar hoort het zakelijke risico niet alleen te accepteren.
Bouw een zevenveldentestkaart per scenario
Gebruik per rij zeven velden: scenario-id, invoer en startsituatie, verwachte bron, toegestane reactie, verboden actie, zichtbaar eindbewijs en eigenaar van het oordeel. Voeg geen rij toe omdat een formulering interessant klinkt; iedere rij moet een andere route, fout of beslisgrens toetsen. Een compacte set met heldere risico’s geeft meer zekerheid dan een lange spreadsheet waarin honderd varianten hetzelfde ideale pad herhalen.
Begin met vijf normale klantvragen uit de afgebakende taak. Voeg daarna ontbrekende informatie, een dubbelzinnige vraag, een correctie, een vraag buiten scope, onbeschikbare bron, ongepaste invoer, herhaalde verzending, een mislukte koppeling en een expliciet mensverzoek toe. Microsoft adviseert testsets vanuit kernscenario’s op te bouwen en ze daarna systematisch met grenzen, tools en handoffs uit te breiden. Neem dat als ontwerpprincipe, niet als platformspecifiek keurmerk.
Test bronbewijs en onbekende informatie afzonderlijk
Maak een bronregister met titel, eigenaar, toepassingsgebied, actualiteitsdatum en uitsluitingen. Vraag bij ieder inhoudelijk scenario welke bron of bronpassage de uitkomst draagt. Controleer niet alleen of er ergens een link staat, maar of de gebruikte informatie het antwoord werkelijk ondersteunt. Wanneer bronnen elkaar tegenspreken, verouderd zijn of de vraag niet dekken, hoort de route twijfel te tonen, een verduidelijking te vragen of naar een mens te gaan.
Test ook informatie die bewust niet in de bron staat. De juiste uitkomst is dan niet automatisch een vast excuus; zij hangt af van de klanttaak. Soms volstaat aangeven dat de informatie ontbreekt, soms moet een medewerker het dossier bekijken en soms hoort de bot helemaal geen antwoord te geven. Leg de toegestane uitkomst vooraf vast. Daarmee test je brontrouw en stopgedrag zonder foutloze beantwoording of volledige dekking te beloven.
Maak antwoordvariatie toetsbaar zonder woord-voor-woordscript
Een generatieve chatbot kan dezelfde vraag anders formuleren. Accepteer daarom betekenis en gedrag, niet één exacte zin. Leg per scenario verplichte feiten, verboden claims, gewenste vervolgstap en toonbandbreedte vast. Draai kritieke scenario’s meerdere keren en varieer spelling, volgorde, context en hoeveelheid informatie. Een antwoord mag verschillen zolang bron, grens en uitkomst gelijk blijven. Een gemiddelde score mag een zeldzame maar zware fout niet verbergen.
Classificeer het resultaat per bewijsniveau. Inhoud kan slagen terwijl de bron ontbreekt; de bron kan juist zijn terwijl de bot een verboden actie suggereert. Registreer ook een false positive: een test die groen wordt gemarkeerd maar volgens een menselijke beoordelaar had moeten falen. De actuele Microsoft-evaluatiechecklist benadrukt herhaalde testsets, menselijke beoordeling, regressiedetectie en analyse van test- tegenover ontwerpfouten. Dat maakt hertesten gericht.
Bewijs systeemacties in een afgeschermde route
Laat de eerste acceptatietests geen echte klantactie uitvoeren. Gebruik fictieve records, unieke scenario-id’s en waar mogelijk mocks of een aparte testomgeving. Controleer succes, niets gevonden, meerdere matches, ongeldig veld, timeout, late levering en dubbele eventlevering. De praktische gids over chatbot en CRM koppelen werkt minimale velden, leidende systemen, idempotentie en foutwachtrijen verder uit; neem die contracten als verwacht bewijs over.
Een actie slaagt pas wanneer het afgesproken eindbewijs bestaat en ongewenste neveneffecten uitblijven. Controleer bijvoorbeeld exact één testlead met juiste bron, eigenaar en status. Lever dezelfde event-id opnieuw en bewijs dat geen tweede record ontstaat. Laat een te late reactie geen tweede uitkomst schrijven nadat de route al naar herstel ging. Verwijder testdata gecontroleerd en noteer welke productierechten nog niet zijn onderzocht; een sandboxresultaat is geen productiegarantie.
Test verboden acties en veilige stoproutes
Schrijf de belangrijkste verboden uitkomsten letterlijk als testregel op: geen prijs toezeggen, geen rechten verlenen, geen dossierinhoud tonen zonder passende context, geen onzekere informatie als feit presenteren en geen externe write doen buiten de afgesproken route. Voeg pogingen toe om instructies te omzeilen, een andere klant te bespreken, verborgen broninformatie op te vragen of de bot tot een niet-bestaande bevoegdheid te verleiden. Beperk dit tot realistische risico’s van de gekozen taak.
Beoordeel bij iedere stoproute wat de bezoeker ziet en wat intern gebeurt. Een veilige weigering zonder bruikbare vervolgstap kan de klant nog steeds laten vastlopen. Een escalatie zonder eigenaar kan intern verdwijnen. Leg daarom een begrijpelijke melding, minimale veilige context, menselijke bestemming, status en vervolgtermijn vast. Dit is een operationele acceptatiegrens en geen uitspraak dat één testset alle beveiligings-, privacy- of juridische risico’s afdekt.
Accepteer menselijke overdracht als volledige route
Test een directe mensvraag, lage zekerheid, een onderwerp buiten scope, een gevoelig besluit, foutieve bron en mislukte koppeling. Controleer daarna een bereikbare medewerker, een bezette bestemming, buiten openingstijd en een overdracht die technisch start maar niet aankomt. De gids over chatbot overdracht helpt trigger, meegegeven context, bereikbaarheid en fallback per gesprek af te bakenen.
De ACM en AP vragen bij AI-chatbots om herkenbaarheid, regie over informatie en toegang tot menselijk contact. Vertaal dat niet naar een algemeen compliancevinkje, maar naar waarneembare tests: begrijpt de bezoeker dat dit een geautomatiseerde route is, kan die om een mens vragen, bereikt de overdracht een echte bestemming en krijgt de medewerker voldoende maar niet onnodige context? Wanneer niemand beschikbaar is, hoort een expliciet vervolg met eigenaar te ontstaan.
Classificeer bevindingen vóórdat je gaat testen
Definieer drie niveaus op basis van effect. Een blocker kan een verkeerde externe actie, ontbrekende mensroute, blootstelling van niet-bedoelde informatie of onbeheersbare duplicate zijn. Een zware bevinding schaadt de taak zonder direct extern effect, bijvoorbeeld een cruciaal feit verkeerd weergeven. Een lichte bevinding verandert formulering of timing zonder onjuiste uitkomst. De proceseigenaar past de ernst toe op de eigen route; de leverancier bepaalt die niet eenzijdig.
Geef iedere bevinding scenario-id, bewijsniveau, waarneming, verwachte uitkomst, ernst, eigenaar, herstelactie en herteststatus. Vermijd “bekend probleem” als eindstatus. Een tijdelijk geaccepteerde afwijking heeft een expliciete grens, eigenaar, einddatum en terugvalroute nodig. Zodra herstel code, instructies, bron of mapping wijzigt, hertest je minimaal de geraakte rij en de nabijgelegen regressies. Bewaar zowel het rode als het groene bewijs.
Neem go-no-go met een klein bewijsdossier
Vat per bewijsniveau samen welke scenario’s zijn uitgevoerd, welke versie is getest, welke blockers openstaan en wie akkoord gaf. Voeg de testmatrix, rode bevindingen, herstelreferenties, hertestresultaten, bekende uitsluitingen en operationele stoproute toe. Een groen totaalcijfer zonder deze herleidbaarheid is zwak bewijs. Een beperkte route kan wel live wanneer haar grenzen duidelijk zijn, alle blockers dicht zijn en de eigenaar het resterende risico begrijpt.
Koppel het besluit aan de afspraak uit de leverancierselectie. De gids om chatbot-offertes te vergelijken vraagt vooraf om dezelfde taak, bronnen, integraties, overdracht en acceptatie. Gebruik de uiteindelijke testset om te controleren of die beloofde scope werkelijk is geleverd. Breid niet direct uit met een tweede klanttaak; verzamel eerst productiebevindingen op de beperkte route en voeg alleen relevante gevallen toe aan de regressieset.
Bewaar na livegang dezelfde testgrenzen
Plan een compacte regressieset na wijzigingen aan instructies, kennisbronnen, modellen, tools, koppelingen, rechten, kanaalgedrag of overdrachtsbestemming. Niet iedere tekstcorrectie vraagt de hele suite, maar iedere wijziging moet benoemen welke bewijsniveaus zij raakt. Test kritieke stop- en systeemacties altijd opnieuw. Noteer ook welke versie de productiebevinding veroorzaakte zodat een herstel niet alleen op de nieuwste omgeving wordt aangenomen.
Meet na livegang route-uitkomsten die bij de klanttaak passen: succesvolle beantwoording met bronbewijs, verduidelijking, menselijke overdracht, foutstatus, herstel en afgebroken gesprek. Gebruik geen losse automatisch berekende score als vervanging voor incidentreview of proceseigenaarschap. Een chatbot blijft beheersbaar wanneer het team kan uitleggen wat is getest, welke grens geldt, welke afwijking openstaat en wie de volgende beslissing neemt.
