Een klant begint een live gesprek met de vraag of een bestelling nog kan worden aangepast. Dat is veilig anoniem te beantwoorden. Vijf minuten later wil de klant het bezorgadres wijzigen. Nu gaat het gesprek over privéwerk aan een account. Het team heeft een betrouwbare identiteit nodig, maar de klant hoort niet opnieuw te beginnen.
Daarvoor is authenticatie tijdens een gesprek bedoeld. De functie werkt niet al omdat er een inlogvenster verschijnt. Ze werkt wanneer de juiste persoon binnen hetzelfde nuttige gesprek is geverifieerd, privéwerk tot dat moment dicht blijft en een mislukking een veilige uitweg heeft.
Test de grens vóór de knop
Microsoft vermeldt verbeterde authenticatie voor Dynamics 365 Contact Center als algemeen beschikbaar in september 2026. De release voegt OAuth 2.0 toe naast authenticatie op basis van JWT, brengt de methode in lijn met Copilot Studio en laat een anonieme klant in synchrone live chat tijdens het gesprek authenticeren na een verzoek van een medewerker of AI-agent. Microsoft waarschuwt dat releaseplanningen kunnen veranderen. Controleer de functie daarom eerst in de bedoelde tenant (Microsoft releasedetails).
- 1Begin veiligLaat een klant een algemene vraag stellen zonder identiteitsbewijs.
- 2Vraag op de grensLaat authenticatie pas starten vóór privéwerk aan het account.
- 3Koppel de juiste klantBevestig uitsluitend het bedoelde actieve klantrecord.
- 4Behoud het gesprekBewaar transcript, eigenaar en uitleg van de klant na inloggen.
- 5Herstel zonder lekHoud privégegevens dicht bij een fout of verlopen sessie.
Leg de bevoegdheidsgrens vast. Een medewerker kan openingstijden of het algemene retourbeleid uitleggen zonder te weten wie de bezoeker is. Een order bekijken, een adres wijzigen, een factuur bespreken of accounthistorie tonen hoort te wachten op een geverifieerde identiteit en de aparte autorisatie voor die handeling. Authenticatie bewijst wie iemand is. Ze geeft niet automatisch toestemming voor alles.
Schrijf twee routes vóór de configuratie
Veel teams schrijven alleen de succesvolle route. Schrijf er twee. In de eerste logt een anonieme klant in en gaat verder. In de tweede ontbreekt het token, is het verlopen of ongeldig, komt het te laat of hoort het bij het verkeerde actieve record. Juist die tweede route voorkomt dat een haastige omweg privégegevens blootlegt.
| Situatie | Verwachte identiteitsstatus | Wat het team mag doen | Bewijs om te bewaren |
|---|---|---|---|
| Algemene vraag | Anoniem | Publieke uitleg geven | Gesprek start zonder accountrecord |
| Privéverzoek | Authenticatie vereist | Uitleggen waarom controle nodig is | Verzoek verschijnt op de afgesproken grens |
| Geldige identiteit | Geverifieerd | Verder binnen toegestane rechten | Juiste actieve klantrecord is gekoppeld |
| Ongeldig of verlopen token | Anoniem | Opnieuw proberen of veilig handmatig helpen | Privévelden blijven onbeschikbaar |
| Dubbelzinnig record | Onopgelost | Gecontroleerde beoordeling starten | Geen record wordt geraden of samengevoegd |
Microsoft legt uit dat Dynamics 365 anonieme en geverifieerde klanten kan onderscheiden en ingestelde contextvariabelen in regels kan gebruiken. De medewerker ziet bij Authenticatie Ja of Nee in het gespreksoverzicht. Voor een eigen portal beschrijft Microsoft ondertekende JWT-claims, controle met een openbare sleutel en een clientfunctie die het token binnen tien seconden moet leveren. Een ongeldig of verlopen token veroorzaakt een foutgebeurtenis (Microsoft authenticatie-instellingen).
Houd hetzelfde gesprek bij veranderde bevoegdheid
De klant moet na het inloggen het oorspronkelijke probleem niet herhalen. Test of transcript, huidige eigenaar, wachtrijgeschiedenis en contactreden blijven bestaan. Controleer daarna of precies het bedoelde actieve contact of account is gekoppeld. Een technisch geldig token bij het verkeerde record is een mislukking.
Die continuïteit telt in webchat en na overdracht. Komt het gesprek in een gedeelde inbox, dan moet de volgende medewerker de geverifieerde status en nuttige context zien zonder een herbruikbaar token of onnodige identiteitsgegevens. Wanneer een AI-assistent om authenticatie vraagt, test dan of automatisering stopt als identiteit niet bewezen is en een mens duidelijk eigenaar wordt.
Test fouten vóór het succespad
Doorloop verlopen, beschadigde en vertraagde tokens. Zet voor één test de identityprovider uit. Log in als een klant met een inactief record. Open twee browsertabbladen en controleer dat de status van de ene klant niet in de andere sessie terechtkomt. Laat een token tijdens een lang gesprek verlopen en kijk welk werk terecht onbeschikbaar wordt.
Beloon een fout niet met een zwakkere omweg. De medewerker kan de volgende stap uitleggen, het publieke deel van het gesprek bewaren, een nieuwe authenticatiepoging aanbieden of overstappen op een goedgekeurd handmatig proces. De medewerker mag een klant niet raden aan de hand van naam, telefoonnummer of een omschrijving van een recente bestelling.
Scheid identiteit toegang en routering
Contextvariabelen kunnen een geverifieerde klant routeren, maar test elke beslissing apart. Klopt de identiteitskoppeling. Mag deze persoon de gevraagde gegevens zien of wijzigen. Moet het gesprek naar een andere wachtrij. Eén positieve uitkomst mag niet stilzwijgend alle drie goedkeuren.
Controleer rolgebaseerde toegang voor medewerkers die geverifieerde gesprekken behandelen. Bevestig dat beveiligingsmaatregelen tokenmateriaal en onnodige identiteitsvelden uit transcripties, exports en gewone medewerkersweergaven houden. Test ook de anonieme route, zodat authenticatie geen algemene slagboom voor een eenvoudige publieke vraag wordt.
Bepaal welk bewijs livegang toestaat
Een startdossier noemt de geteste tenant en het kanaal, de identityprovider, testaccounts, tokenlevensduur, verwachte recordmatch, toegestane privéacties, routeringsuitkomst, foutuitkomst en verantwoordelijke eigenaar. Leg resultaten vast zonder echte geheimen of volledige tokens. Laat minstens één test uitvoeren door iemand die de functie niet heeft ingesteld.
Stel een stopregel in. Pauzeer als een verkeerd record kan worden gekoppeld, privégegevens na een fout zichtbaar worden, het transcript verdwijnt, eigenaarschap onduidelijk raakt of herstel afhangt van een geïmproviseerde uitzondering.
DripTell vervangt de identityprovider of Dynamics-autorisatie niet. Het helpt daarna, wanneer geverifieerde gesprekken duidelijk eigenaarschap, beperkte zichtbaarheid en veilige overdracht nodig hebben. Het implementatieteam kan helpen dit bewijs te definiëren voordat je verder automatiseert.
Veelgestelde vragen
Vervangt authenticatie tijdens het gesprek autorisatie
Nee. Authenticatie bewijst de identiteit. De applicatie en het servicebeleid bepalen nog steeds welke records en handelingen die identiteit mag gebruiken.
Moet elke live chat authenticatie eisen
Nee. Laat veilige publieke vragen anoniem toe. Vraag authenticatie wanneer het werk privéaccountgegevens of een beschermde handeling raakt.
Wat is de belangrijkste fouttest
Gebruik een geloofwaardige identiteit die aan het verkeerde of een inactief klantrecord wordt gekoppeld. Het systeem mag niet raden, samenvoegen of gegevens tonen.
Wat gebeurt er als authenticatie mislukt
Houd privégegevens dicht, bewaar het veilige deel van het gesprek, leg de nieuwe poging of handmatige route uit en wijs een eigenaar aan.
Hulp nodig bij deze handleiding?Vraag het DripTell-team
Van lezen naar doen
Hulp nodig om dit voor jouw bedrijf toe te passen?
Laat je gegevens achter. We nemen dit artikel als context en beginnen met een bruikbaar antwoord voor je team.
DripTell Editorial
Praktische uitleg, gecontroleerd door het product- en klantworkflowteam van DripTell.
Lees hoe DripTell productclaims controleert, primaire bronnen gebruikt en correcties verwerkt.
Redactioneel en bronnenbeleid
