Chatbot-beszélgetések folytatása: munkamenetek, eszközváltás és biztonságos átadás

Egy látogató három kérdést tesz fel a weboldali chatbotnak, átlép a termékoldalra, majd később visszatér. Egy ügyfél az okostelefonján kezdi el a beszélgetést, de a laptopján szeretné folytatni. A támogatási folyamat végén pedig egy ember veszi át a szót. Mindhárom esetben ugyanaz az elvárás: a beszélgetésnek zökkenőmentesen kell folytatódnia. Technikai és szervezési szempontból azonban ez három teljesen eltérő feladat. Ha ezeket összemossuk, az elveszett kontextushoz, nem kívánt adategyeztetésekhez vagy a szükségesnél tovább aktív maradni engedett munkamenetekhez vezethet.

A „folytatás” nem ugyanaz, mint a „felismerés”

A tervezés során segít, ha egyértelműen elkülönítjük a folytonosság három szintjét:

1. Egyetlen látogatáson belül: A beszélgetés megmarad, miközben a felhasználó az oldalak között navigál, vagy bezárja, majd újra kinyitja a chatablakot.
2. Későbbi visszatéréskor: Ugyanaz a böngésző egy korlátozott időkereten belül megtalálja a korábbi beszélgetést.
3. Eszközök között: A felhasználó egy másik böngészőben vagy eszközön folytatja a beszélgetést. Ehhez általában megbízható fiókösszekapcsolásra vagy egy tudatosan kezdeményezett, rövid életű átviteli folyamatra van szükség.

A meglévő beszélgetési előzmények még nem bizonyítják a személyazonosságot. Aki rendelkezik egy beszélgetés-azonosítóval (ID) vagy egy hivatkozással, az még nem férhet hozzá automatikusan a rendelésekhez, szerződéses adatokhoz vagy személyes adatokhoz. Ez ugyanaz az alapvető határvonal, mint a nyilvános chatbot és az hitelesített ügyfélportál szétválasztásánál: a kontextus növelheti a kényelmet, de nem helyettesíti a bejelentkezést és a jogosultságellenőrzést.

A technikai alap: hivatkozás a böngészőben, állapot a szerveren

Egy robusztus architektúra a böngészőben lehetőleg csak egy véletlenszerű, információt nem tartalmazó hivatkozást (referenciát) tárol. A hozzá tartozó beszélgetési állapot a szerveroldalon található, és minden kérésnél ellenőrzésre kerül az érvényesség, a bérlő (tenant), a jogosultság és a lejárati dátum alapján. A Session Managementre vonatkozó OWASP-ajánlások jelentés nélküli, nehezen kitalálható munkamenet-azonosítókat és szerveroldalon ellenőrzött időkorlátokat javasolnak. A munkamenet-azonosítók emellett nem valók az URL-ekbe: az előzményeken, naplókon, hivatkozó oldalakon (referrer) vagy megosztott linkeken keresztül kiszivároghatnak.

A böngésző tárhelye eltérő eléréssel rendelkezik. Az MDN Web Storage API szerint a sessionStorage a böngészőfülhöz és az eredethez (origin) van kötve, és általában a fül bezárásával megszűnik. A localStorage ezzel szemben megmarad a böngészési munkamenetek között is, de továbbra is csak ugyanabban a böngészőprofilban. Egyik sem hoz létre eszközökön átívelő identitást. Az érzékeny átiratok vagy a tartós hozzáférési tokenek közvetlenül ott történő tárolása ráadásul növeli a szkript- vagy eszközhozzáférésből eredő kockázatokat.

Milyen adatokat tartalmazzon az állapot?

A hasznos folytatáshoz a rendszernek gyakran kevesebbre van szüksége, mint a teljes átiratra. Egy kompakt, verziózott állapot-adatkészlet is elegendő lehet:

• a jelenlegi kérés és a megerősített cél,
• a már tisztázott, nem érzékeny tények,
• a nyitott kérdések és a következő logikus lépés,
• a felhasznált tudásforrások vagy azok verziói,
• a hozzájárulási, hitelesítési és átadási (handoff) állapot,
• az utolsó aktivitás időpontja és a meghatározott lejárati dátum.

Így a beszélgetés összefüggően folytatható anélkül, meglévő korábbi üzeneteket korlátlanul másolnánk az aktív promptba. A teljes előzmény külön, rövidebb ideig vagy egyáltalán nem őrizhető meg – a céltól, a felhasználói elvárásoktól és a meghatározott szabályoktól függően. A személyes adatok esetében különösen a GDPR 5. cikkéből származó célhoz kötöttség, az adattakarékosság és a korlátozott tárolhatóság fontos tervezési elvek. Ez nem helyettesíti az egyéni jogi tanácsadást, de egyértelmű termékkövetelményt ad: csak azt tárolja, amire a megnevezett célhoz valóban szükség van.

Kezelje eltérően az anonim és a bejelentkezett beszélgetéseket

Anonim visszatérés ugyanabban a böngészőben

Az anonim látogatók esetében a „beszélgetés folytatása” funkciónak korlátozott kényelmi funkciónak kell maradnia. Célszerű a rövid megőrzési idő, egy jól látható törlési parancs, valamint annak elmagyarázása, hogy az előzményeket csak ebben a böngészőben lehet megtalálni. A chatbot a visszatérésből nem feltételezheti, hogy ugyanaz a természetes személy ül előtte. A lejárati idő letelte után vagy a helyi referencia elvesztésekor új munkamenet kezdődik.

Gyakorlati szempontból a chatbot a visszatéréskor megkérdezheti: „Szeretné folytatni a termékválasztásról szóló beszélgetést, vagy újat kezdene?” Ez jobb, mint a régi kontextus csendes aktiválása. Közösen használt eszközökön ez a megerősítés megakadályozza, hogy a következő személy azonnal olyan tartalmat lásson, ami nem tartozik rá.

Eszközváltás bejelentkezéssel

Az eszközökön átívelő folytonosságot egy ellenőrzött fiókhoz és annak aktuális jogosultságaihoz kell kötni. Bejelentkezés után a szerver csak azokat a beszélgetéseket tölti be, amelyek ehhez a fiókhoz és a megfelelő bérlőhöz vannak rendelve. Érzékeny műveletek esetén – például címváltoztatás, szerződéses információk vagy megrendelés – célszerű az újbóli hitelesítés, még akkor is, ha az általános chat még aktív.

A munkamenet-kezelésre vonatkozó aktuális NIST SP 800-63B útmutató a munkameneteket a hitelesített személy és a szolgáltatás közötti kapcsolatként írja le egy munkamenet-titok (session secret) segítségével. Mind az inaktivitási, mind a teljes időkorlátot, valamint a szerveroldali megszüntetést megköveteli. A termékfejlesztő csapatok számára ebből az következik: a „bejelentkezve” állapot nem lehet korlátlan, és a lejárt fiók- vagy munkamenet-token nem éleszthető újjá egy még meglévő chat-előzménnyel.

Átviteli kód csak szigorúan korlátozott hídként

Egyes szolgáltatások szeretnék lehetővé tenni az anonim váltást egyszeri kód vagy QR-kód segítségével. Ebben az esetben a kódnak rövid életűnek, egyszer használatosnak és visszavonhatónak kell lennie. Nem tartalmaz sem átiratot, sem ügyféladatokat, csak egy véletlenszerű hivatkozást egy engedélyezett, minimális beszélgetési állapotra. A sikeres átvétel után a régi referencia érvénytelenné válik. A kód egy híd a kontextus számára, nem pedig a személyazonosság igazolása vagy az érzékeny fiókadatok kiadása.

A lejárati szabályoknak érthetőnek kell lenniük a felületen

A technikai időkorlátok csak a feladat felét oldják meg. A felhasználóknak tudniuk kell, hogy megmarad-e a beszélgetésük, és ha igen, meddig. A NIST Customer Experience útmutatója hangsúlyozza a munkamenet végét jelző egyértelmű információk fontosságát, hogy ne vesszen kárba a munka, és az emberek ne folyamodjanak nem biztonságos megkerülő megoldásokhoz.

Egy jó lejárati koncepció ezért közvetlenül a chaten válaszolja meg a következőket:

• Megmarad a beszélgetés a bezárás után?
• Ez csak erre a böngészőre vonatkozik, vagy más eszközökön történő bejelentkezés után is elérhető?
• Mikor ér véget a munkamenet inaktivitás miatt, és mikor törlődnek a tárolt előzmények?
• Mely részeket távolíthat el vagy exportálhat maga a felhasználó?
• Mi történik egy nyitott támogatási esettel a lejárat után?

A munkamenet várható vége előtt egy diszkrét figyelmeztetés felajánlhatja a nyitott információk mentését vagy a támogatáshoz történő átadását. A lejárat után a felületnek egyértelműen különbséget kell tennie a „Munkamenet befejeződött” és a „Gépelt előzmények törölve” állapotok között. Az egyik a hozzáférésre, a másik a megőrzésre vonatkozik.

Human Handoff: kontextus átadása, a felelősség láthatóvá tétele

Amikor az ügyfél átvált egy emberi munkatársra, egy rövid, strukturált összefoglaló gyakran értékesebb, mint egy kommentár nélküli hosszú előzmény. Megnevezi a kérést, a megerősített adatokat, a már javasolt lépéseket, a nyitott kérdést és a felhasznált forrásokat. Érzékeny tartalmakat csak akkor ad át a rendszer, ha azok szükségesek a támogatási esethez és engedélyezve vannak arra.

A felhasználónak látnia kell, hogy most egy ember veszi át az irányítást, milyen információkat továbbít a rendszer, és hogy keletkezik-e új várakozási idő. Ugyanakkor az MI-nek az átadás után tudnia kell, hogy hallgasson-e, csak szervezési segítséget nyújtson-e, vagy később újra átveheti-e a szót. A konkrét kiváltó okokat és eszkalációs szabályokat a weboldali chatbotok Human Handoff funkciójáról szóló cikk írja le.

Megvalósítás hat lépésben

1. Használati forgatókönyvek meghatározása: Külön spesifikálja az oldalon belüli navigációt, a későbbi visszatérést, az eszközváltást és az emberi átadást.
2. Bizalmi szintek meghatározása: Rögzítse, hogy mely tartalmak érhetők el névtelenül, fiókösszekapcsolás után vagy csak újbóli hitelesítést követően.
3. Az állapot minimalizálása: Tervezzen meg egy strukturált folytatási állapotot (resume-state) a céllal, megerősített tényekkel, nyitott pontokkal és lejárati idővel.
4. Az életciklus kikényszerítése: Tesztelje szerveroldalon az inaktivitási korlátot, az abszolút korlátot, a törlést, a visszavonást és a kijelentkezést.
5. Az átadási folyamat megtervezése: Tegye láthatóvá a felhasználói megerősítést, a támogatási összefoglalót, a várakozási állapotot és a felelősségi kört.
6. Siker mérése teljes szöveg nélkül: Rögzítsen olyan eseményeket, mint a „folytatás felajánlva”, „elfogadva”, „lejárt”, „eszközváltás befejeződött” és „átadás sikeres”. Azt, hogy ez hogyan érhető el adatmegtakarítási szempontok figyelembevételével, az MI-chatbot analitikáról szóló útmutató mutatja be.

Tesztmátrix asztali gépre, mobilra és valós szélsőséges esetekre

A bevezetés előtt nem csak a normál működési útvonalnak kell működnie. Egy kis tesztmátrix lefedheti a tipikus hibákat:

• Navigáció ugyanazon a weboldalon belül nyitott és zárt chatablakkal,
• Visszatérés ugyanabban a böngészőben az inaktivitási korlát előtt és után,
• Visszatérés privát ablakban vagy a helyi böngészőadatok törlése után,
• Eszközváltás bejelentkezés előtt és után, valamint kijelentkezés után,
• Fiókváltás egy közösen használt eszközön,
• Lejárt, már felhasznált vagy visszavont átviteli kód,
• Törölt beszélgetés, zárolt fiók és megváltozott bérlői jogosultság,
• Folytatás a tudásbázis frissítése után,
• Átadási folyamat kifejezetten engedélyezett összefoglalóval és anélkül,
• Hosszú címek, eltérő szöveghosszúságú nyelvek és mobil szélességek vízszintes túlcsordult szöveg nélkül.

Minden esetben a látható válasz mellett a hálózati hozzáférések, a munkamenet-érvénytelenítés, a hibanaplók és az analitikai események is a teszt részét képezik. A chatbot udvariasan elmagyarázhatja, ha egy kontextus már nem érhető el. De soha nem szabad azt hasonló felhasználói adatokból rekonstruálnia, vagy egy új személyhez rendelnie.

Összegzés: a folytonosság egy ellenőrzött átadás

A jó folytatási élmény nem azt jelenti, hogy mindent örökre elmentünk. Azt jelenti, hogy a megfelelő, minimális kontextust viszzük magunkkal egy világosan korlátozott szakaszon. Ugyanannak a böngészőnek, egy bejelentkezett második eszköznek és egy emberi támogatási csatornának eltérő bizalmi és lejárati szabályokra van szüksége ehhez. Ha a beszélgetési állapot, az identitás és a jogosultság elkülönül egymástól, akkor kényelem jön létre csendes adategyeztetés nélkül.

Aki ezeket a szabályokat korán beépíti a Conversational UX-be, az csökkentheti a munkamenetek megszakadását, és érthetőbbé teheti a támogatási átadásokat. A ChatReact funkciói áttekintést nyújtanak a weboldali chatbotok lehetséges építőelemeiről; a konkrét munkamenet- és adatvédelmi konfigurációt ezután a saját használati esetnek megfelelően kell megtervezni és tesztelni.

Források

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Általános adatvédelmi rendelet, 5. cikk