Hulp nodig bij deze handleiding?Vraag het DripTell-team
Een klant vraagt in de chat om het e-mailadres van een account te vervangen. De klant kent de naam, het bestelnummer en de postcode. Daarmee kan een medewerker het dossier vinden. Het bewijst niet dat deze persoon de wijziging mag uitvoeren.
De veilige reactie is niet om in dezelfde chat meer geheimen te verzamelen. Begin bij de gevraagde handeling, bepaal wat er kan gebeuren als je die voor de verkeerde persoon uitvoert en stuur gevoelige verzoeken naar een vooraf goedgekeurd verificatiepad. Laat geen wachtwoorden, eenmalige codes, identiteitsdocumenten of herstelantwoorden in het gesprek achter.
Begin bij de gevraagde handeling
Identiteitscontrole beschermt een concrete handeling. Het is geen reden om iedere klant dezelfde vragen te stellen. Een openbaar retourbeleid uitleggen, bestelgegevens tonen, een herstelfactor wijzigen en geld vrijgeven hebben niet hetzelfde risico.
- 1Benoem de handelingLeg precies vast wat de klant wil zien, wijzigen of vrijgeven.
- 2Beoordeel de schadeBepaal het gevolg van goedkeuring voor de verkeerde persoon.
- 3Kies de routeGebruik het goedgekeurde verificatie- of herstelpad voor dat risico.
- 4Houd bewijs apartVraag niet om wachtwoorden, codes of documenten in de chat.
- 5Noteer de uitkomstBewaar resultaat, eigenaar en volgende stap in plaats van ruwe geheimen.
Leg vast welke handelingen zonder accounttoegang kunnen, wanneer een ingelogde klant nodig is en wanneer een sterker herstel- of goedkeuringspad geldt. Die regel hoort zichtbaar te zijn in de team inbox, niet alleen in het geheugen van een medewerker.
De actuele Digital Identity Guidelines van NIST beschrijven formele processen en eisen voor identiteitscontrole, authenticatie en federatie, met aandacht voor beveiliging, privacy en klantervaring. Ze zijn geen script dat elk supportteam letterlijk moet volgen. De praktische les is wel breed bruikbaar: ontwerp het pad voordat een gesprek onder druk begint.
Stem de controle af op mogelijke schade
Vraag eerst wat er mogelijk wordt als het verzoek voor de verkeerde persoon wordt goedgekeurd. Het antwoord bepaalt de sterkte van de controle en wie een uitzondering mag goedkeuren.
| Gevraagde handeling | Mogelijke schade bij een fout | Veiliger verificatiepad | Wat in het gesprek blijft |
|---|---|---|---|
| Een openbaar retourbeleid uitleggen | Weinig of geen accountschade | Identiteitsbewijs is normaal niet nodig | Vraag en antwoord |
| Bestel- of accountgegevens tonen | Privégegevens bereiken een ander | Bestaand ingelogd account of goedgekeurde factor | Uitkomst en tijdstip |
| E-mail of herstelfactor wijzigen | Toekomstige toegang kan worden omgeleid | Vastgelegd herstelpad en strengere beoordeling | Resultaat, beoordelaar en volgende stap |
| Geld, toegang of een waardevol object vrijgeven | Direct verlies of ongeoorloofde toegang | Goedgekeurde controle voor hoog risico en zo nodig een tweede akkoord | Besluit en autorisatiereferentie |
Voeg geen vragen toe omdat een klant nerveus, boos, buitenlands of opvallend zelfverzekerd klinkt. De handeling en het bewijs horen de beslissing te sturen. Consistente regels beperken zowel fraude als ongelijke behandeling.
Verplaats bewijs uit de open chat
Een openbaar chatvenster bewijst alleen dat iemand erin kan typen. Zelfs een bekend WhatsApp-nummer kan gedeeld, opnieuw uitgegeven of via een gecompromitteerd toestel gebruikt zijn. Gespreksgeschiedenis geeft context, maar is geen authenticatie.
Verplaats gevoelig werk naar een vertrouwde route die de organisatie beheert. Dat kan een ingelogd account, een goedgekeurde bevestigingslink, een gecontroleerd terugbelgesprek of een formeel herstelproces zijn. Vraag de klant niet om een wachtwoord, eenmalige code, volledig betaalnummer of kopie van een identiteitsbewijs in een gewone chat te plakken.
Deze grens hoort in het beveiligingsmodel en in de kanaalhandleiding. Een WhatsApp-supportproces moet zeggen wat het kanaal kan doen, wat het niet kan bewijzen en hoe een gevoelig verzoek verdergaat zonder de klant los te laten.
Noteer de uitkomst niet het geheim
Support heeft nog steeds een auditspoor nodig. Meestal volstaat een compacte registratie van de gevraagde handeling, het goedgekeurde verificatiepad, de uitkomst, de eigenaar van een uitzondering en de volgende stap. Ruw bewijs vergroot vaak het risico zonder de volgende medewerker te helpen.
NIST SP 800-63A-4 definieert identiteitscontrole als een proces waarin bewijs een identiteitsclaim op een bruikbaar betrouwbaarheidsniveau ondersteunt. Ook een supportteam moet die grens helder houden. Een account vinden is niet hetzelfde als de aanvrager authenticeren, en voor geen van beide hoeft onbewerkt bewijs in de chat te blijven. Bewaar alleen de uitkomst die het beleid vereist.
Bewaar waar nodig de verificatiestatus bij het klantrecord in de CRM. Beperk de toegang en stel bewaartermijnen vast. Beloon medewerkers niet voor het verzamelen van meer bewijs dan het beleid vraagt.
Bied een eerlijk pad wanneer het mislukt
Een echte klant kan de oude telefoon, mailbox of authenticator kwijt zijn. Blijf dan niet steeds makkelijkere vragen stellen tot er één klopt. Volharding is geen bewijs.
Beschrijf een herstelpad met een duidelijke eigenaar, toegestaan bewijs en begrijpelijke updates. Uitzonderingen met veel risico kunnen een tweede beoordelaar vereisen. Als veilige verificatie niet lukt, moet de handeling stoppen zonder het gesprek als opgelost te sluiten.
Goede supportprocessen maken zo'n weigering bruikbaar. Vertel wat nog niet kan, welke goedgekeurde optie resteert, wie de volgende stap bezit en wanneer de klant iets hoort.
Bouw een proces dat medewerkers kunnen volgen
Neem tien veelvoorkomende gevoelige verzoeken. Benoem per verzoek de schade, route, eigenaar van uitzonderingen, verboden transcriptgegevens, auditvelden en klanttekst. Test het proces met nieuwe medewerkers en met mensen die de standaardmethode niet kunnen gebruiken.
Gebruik automatisering om te routeren en herinneren, niet om identiteit af te leiden uit zwakke signalen. Een regel kan een accountwijziging pauzeren en een beoordelaar toewijzen. Een overeenkomende naam of een bekend nummer wordt daardoor geen bewijs.
Bekijk geslaagde, mislukte en afgebroken controles. Zoek naar geïmproviseerde vragen, herhaalde dataverzameling, uitzonderingen zonder eigenaar en geheimen in gesprekken. De beste controle is niet de langste. Het is de kleinste goedgekeurde controle die de handeling beschermt en een duidelijke volgende stap achterlaat.
Veelgestelde vragen
Is een bestelnummer genoeg om een klant te verifiëren
Meestal niet voor een gevoelige handeling. Het nummer helpt om een record te vinden, maar kan in e-mail, op een verpakking of in een gedeeld document staan. Gebruik het goedgekeurde pad voor de handeling.
Mag een medewerker om een eenmalige code vragen in chat
Nee. De klant voert de code alleen in binnen de goedgekeurde authenticatiestroom. Een code in chat zet een actief geheim in het transcript en leert onveilig gedrag aan.
Bewijst een bekend telefoonnummer de identiteit
Nee. Het nummer biedt context, maar een telefoon of account kan gedeeld, opnieuw uitgegeven of gecompromitteerd zijn. Stem de controle af op de gevolgen van de handeling.
Wat gebeurt er als verificatie mislukt
Stop de gevoelige handeling, houd eigenaarschap over het gesprek en bied het vastgelegde herstel- of uitzonderingspad. Noteer de uitkomst en volgende stap zonder onnodig bewijs te bewaren.
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