Eindgebruikers authenticeren in berichten

Authenticatie vertelt Zendesk wie de bezoeker is, zodat zijn historie hem volgt en niet de browser die hij toevallig gebruikte.

Authenticatie vertelt Zendesk wie de bezoeker is, zodat zijn historie hem volgt en niet de browser die hij toevallig gebruikte.

Wat er verandert

• Het gesprek hangt aan een persoon, niet aan een browser. Hij ziet het op zijn telefoon net zo goed als op zijn laptop.
• Agents weten met wie ze praten, met zijn tickets en zijn organisatie in het contextvenster.
• De historie is privé. Iemand anders op hetzelfde apparaat ziet hem niet.
• Je kunt beperken wat hij bereikt op basis van wie hij is.

Hoe het werkt

Je website, die al weet dat de bezoeker is aangemeld, geeft een ondertekend token aan de widget mee. Zendesk controleert dat en behandelt het gesprek als van die gebruiker.

Dit is werk aan de website en geen instelling, en het vraagt een ontwikkelaar. De Zendesk-kant is het aanzetten en de ondertekensleutel bewaren.

Twee aanroepen doen het werk, en dat is wat je overdraagt: zE("messenger", "loginUser", ...) meldt de bezoeker aan met een JWT, en zE("messenger", "logoutUser") meldt hem af. Het token heeft een geldigheidsduur, dus de site moet een nieuw token kunnen aanleveren in plaats van eenmalig een langlopend token uit te geven.

Kijk eerst naar de kortere weg

Verifieert je helpcenter al wie iemand is en staat de widget ingesteld om dat te gebruiken, dan neemt messaging die aangemelde identiteit vanzelf over, inclusief naam en e-mailadres. Dat dekt een flink deel van wat de tokenroute je geeft, zonder een regel code. Ga dus na of helpcenterverificatie aanstaat voordat je ontwikkelwerk laat inplannen.

Drie grenzen om vooraf te kennen

• Het geldt voor de Web Widget en de mobiele SDK, en voor geen enkel ander kanaal.
• Het geldt niet voor je eigen mensen: agents en admins worden hier niet mee geverifieerd.
• Bij messaging met meerdere gesprekken kan een gebruiker op hoogstens 100 actieve tickets tegelijk als geverifieerd gelden, waarbij alles meetelt wat niet opgelost of gesloten is.

Eén ontwerppunt voor wie het token schrijft: de external ID is de eerste identificatie, ook als er daarnaast een e-mailadres in het token staat. Bouw de identiteit dus op het ID dat je eigen systeem al gebruikt en niet op het adres.

Wanneer het de moeite waard is

• Klanten melden zich al aan op je site of in je app. Dan is het een kleine toevoeging met een grote opbrengst.
• Gesprekken zijn persoonlijk of financieel, waar historie op een gedeeld apparaat een echt risico is.
• Agents moeten weten met wie ze praten voordat ze überhaupt kunnen helpen.

Wanneer je het overslaat

Een openbare site waar bezoekers geen account hebben. Authenticatie betekent daar dat je mensen vraagt zich aan te melden voordat ze iets kunnen vragen, en dat verliest meer dan het oplevert.

Zie ook

• Helpcenter-authenticatie aan- en uitzetten
• Zichtbaarheid van transcripties beheren
• Aanmeldmogelijkheden voor eindgebruikers