Načrtovanje predaje AI klepetalnika: Paketi konteksta, usmerjanje in UX čakalnih vrst

AI klepetalnik lahko prepozna, da pogovor potrebuje človeka, in vseeno ponudi slabo podporno izkušnjo. Do napake običajno pride pri prehodu: stranka ponavlja svojo zgodbo, primer pristane v napačni čakalni vrsti, občutljive podrobnosti se pojavijo v povzetku ali pa nihče ne razloži, kaj sledi. Dobro načrtovanje predaje AI klepetalnika obravnava eskalacijo kot majhen operativni sistem, ne pa kot končno obsodbo bota.

Ta vodnik se osredotoča na plast po odločitvi o eskalaciji: paket konteksta, pogodbo o usmerjanju, izkušnjo v čakalni vrsti, mejo zasebnosti, delovni prostor operaterja in preverjanje kakovosti. Če morate najprej določiti, kdaj naj se avtomatizacija ustavi, preberite naš ločeni vodnik o sprožilcih predaje človeku za podporo na spletnem mestu.

Določite predajo kot pogodbo med tremi udeleženci

Prehod vključuje stranko, avtomatizirani sistem in prevzemno ekipo. Vsak udeleženec potrebuje jasno pogodbo. Stranka mora vedeti, da se je avtomatizacija ustavila, katere informacije se bodo prenesle naprej, kateri kanal sledi in ali je potrebno čakanje. Bot potrebuje deterministično pravilo za sestavljanje in pošiljanje konteksta. Prevzemna ekipa potrebuje predvidljiv paket podatkov, pravilo lastništva in rezervno možnost, ko primarna čakalna vrsta ni na voljo.

Zapišite to pogodbo, preden povežete orodja. Uporabna specifikacija na eni strani odgovarja na šest vprašanj:

• Kateri dogodek sproži predajo?
• Katera polja so obvezna, izbirna ali prepovedana v paketu podatkov?
• Katera čakalna vrsta je lastnik posamezne vrste težave?
• Kaj stranka vidi pred prenosom, med njim in po njem?
• Kaj se zgodi zunaj delovnega časa ali ob prekinitvi povezave?
• Kateri dogodki in izidi se beležijo za nadzor kakovosti (QA)?

S tem se izognete pogosti arhitekturni napaki: obravnavanju ponudnikovega signala za prenos kot celotnega poteka dela. Dokumentacija za Dialogflow CX podjetja Google Cloud na primer pojasnjuje, da je odziv za predajo operaterju v živo le signal za integracijo, ki ga kliče; okoljski sistem še vedno odloča o tem, katero operativno dejanje bo izvedeno. Enaka razlika velja za večino ogrodij klepetalnikov.

Zgradite strnjen paket konteksta, ne pa nefiltriranega izpisa prepisa

Oseba, ki prevzame primer, mora razumeti zadevo, ne da bi stranko prisilila v ponovno razlaganje. To ne pomeni posredovanja vsakega razpoložljivega polja. Uporaben paket združuje jedrnat povzetek z majhnim naborom strukturiranih dejstev in povezavo do prepisa pogovora, kadar je dostop primeren.

Uporabite štiri plasti konteksta

1. Razlog za prenos: ekspliciten sprožilec, kot je zahteva stranke, ponavljajoča se napaka, dejanje na računu ali izjemni primer pravil.
2. Cilj stranke: en nevtralen stavek, ki opisuje, kaj stranka poskuša doseči.
3. Preverjena strukturirana polja: jezik, tema, referenca primera ali naročila, stanje avtentikacije, nujnost in po potrebi želeni kanal.
4. Dokaz pogovora: omejen prepis ali povezava, ki svetovalcu omogoča pregled izvirnega besedila.

Označite predvidene vrednosti kot predvidene. Povzetek, ki ga ustvari model, ne sme nikoli potihem spremeniti ugibanja v dejstvo. Na primer: »stranka deluje frustrirana« je interpretacija; »stranka je dvakrat zahtevala človeka« pa je opazljiv dogodek. Strukturirana dejstva morajo izhajati iz preverjenih vnosov ali zaupanja vrednih sistemov.

Microsoft navaja, da lahko predaje v Copilot Studio delijo zgodovino pogovora in ustrezne spremenljivke, medtem ko navodila za Dynamics 365 prikazujejo, kako spremenljivke konteksta podpirajo usmerjanje in produktivnost svetovalcev. Te zmožnosti so uporabni vzorci, vendar zasnova polj še vedno ostaja v domeni organizacije, ki sistem izvaja.

Ločite podatke o usmerjanju od vsebine pogovora

Usmerjanje bi se moralo zanašati na stabilna, preverljiva polja in ne le na prostoobliki povzetek. Motor čakalne vrste lahko uporabi kategorijo težave, jezikovno okolje, stanje avtentikacije, področje izdelka, raven storitve ali kodu nujnosti. Opisni povzetek pomaga svetovalcu razumeti primer; ne bi pa smel biti edina podlaga za nadzor dostopa ali določanje visoke prioritete.

Ustvarite tabelo usmerjanja z lastnikom in rezervno možnostjo za vsako podprto kombinacijo. Prva različica naj bo majhna. Deset natančnih poti je običajno lažje upravljati kot več deset prekrivajočih se pravil. Za vsako pot določite:

• primarno čakalno vrsto in delovni čas;
• rezervno čakalno vrsto ali asinhroni kanal;
• zahtevana znanja in pokritost jezikov;
• največje sprejemljivo stanje čakanja;
• kaj stranka vidi, če nihče od svetovalcev ni na voljo.

Če so vključeni prilagojeni podatki, mora usmerjanje spoštovati mejo identitete. Javno klepetanje na spletni strani ne bi smelo dobiti dostopa na ravni računa le zato, ker se prenaša. Naš vodnik o javnih v primerjavi z avtenticiranimi klepetalniki na uporabniških portalih ponuja praktičen model za ločevanje teh poti.

Oblikujte izkušnjo v čakalni vrsti kot del pogovora

Z vidika stranke se predaja začne, preden se pridruži svetovalec. Prehodno sporočilo mora navesti, kaj se dogaja, kaj je bilo že posredovano in kaj lahko stranka stori naprej. Izogibajte se obljubam, ki jih čakalna vrsta ne more zanesljivo izpolniti.

Uporaben vzorec sporočila je: »Ta pogovor prenašam naši ekipi za vračila. Posredoval bom vašo številko naročila in zgornji povzetek, tako da vam jih ne bo treba ponavljati. Lahko ostanete tukaj ali izberete e-pošto, če želite asinhroni odgovor.« Besedilo prilagodite dejanskim zmožnostim in ravnem storitev.

Ko storitev v živo ni na voljo, ponudite pravo rezervno možnost namesto slepe ulice. To je lahko strukturiran kontaktni obrazec, ustvarjanje zahtevka, zahteva za povratni klic ali jasno naveden delovni čas. Primerjajte prednosti teh kanalov v članku AI klepetalnik vs. klepet v živo vs. kontaktni obrazec.

Zaščitite prepis in povzetek že pri zasnovi

Predaja lahko razširi dostop do podatkov pogovora. Določite, kdo lahko vidi prepise, kako dolgo se hranijo, katera polja se lahko pojavijo v povzetkih in ali je treba občutljive vrednosti pred prenosom prikriti. V paket ne vključujte gesel, plačilnih podatkov, kodo za preverjanje pristnosti ali nepotrebnih podatkov posebnih kategorij.

Dostop do prepisa je vprašanje dovoljenj in ne zgolj priročna funkcija. Microsoftova navodila za nadzor prepisov ponazarjajo potrebo po ločenem upravljanju hrambe in vlog gledalcev. Enako načelo uporabite pri katerem koli sistemu: svetovalci morajo prejeti minimalni kontekst, potreben za primer, dostop pa mora biti revidiran v skladu z vašimi varnostnimi in zasebnostnimi zahtevami.

Preizkusite tudi odpornost na vbrizgavanje navodil (prompt injection). Besedilo stranke mora ostati nezaupanja vredna vsebina, ko se pojavi v ustvarjenem povzetku ali delovnem prostoru svetovalca. Ne sme imeti možnosti spreminjanja pravil usmerjanja, dovoljenj ali notranjih navodil.

Omogočite prevzemnemu svetovalcu praktično uporaben delovni prostor

Idealni delovni prostor se začne s ciljem stranke, razlogom za prenos, preverjenimi polji in predlaganim naslednjim dejanjem. Celoten prepis ostane na voljo, vendar ne obvladuje zaslona. Svetovalci morajo imeti možnost popravka netočnih kategorij ali povzetkov, ne da bi morali vse napisati znova.

Zajemite te popravke kot signale za preverjanje kakovosti (QA). Ponavljajoče se spremembe iste kategorije lahko nakazujejo na težavo s pravili usmerjanja. Ponavljajoči se popravki povzetka pa lahko opozarjajo na šibke pozive, manjkajoči izvorni kontekst ali neustrezen korak povzemanja. Ne dovolite, da svetovalec tiho prevzema napake avtomatizacije.

Preizkusite prehod od začetka do konca

Gumb za preusmeritev lahko deluje, čeprav celotna pot storitve še vedno odpove. Zgradite testno matriko predaje, ki zajema besedišče strank, stanje kanalov, razpoložljivost čakalnih vrst, stanje identitete, jezik, občutljivost podatkov in okrevanje po napakah.

Minimalni kontrolni seznam za prevzem

• Neposredna zahteva po človeku se upošteva brez zank prepričevanja.
• Stranka vidi natančno sporočilo o prehodu in čakanju.
• Pravilna čakalna vrsta prejme primer in zahtevani jezik.
• Preverjena dejstva ostajajo ločena od predvidevanj modela.
• Svetovalec enkrat prejme obljubljeni kontekst, brez dvojnikov.
• Nerazpoložljive čakalne vrste ustvarijo uporabno rezervno možnost.
• Omejeni podatki so odstranjeni ali zaščiteni z nadzorom dostopa.
• Ponovni poskusi ne ustvarjajo podvojenih zahtevkov ali vzporednega lastništva.
• Stranka lahko nadaljuje po začasni napaki pri prenosu.
• Analitika beleži sprožilec, pot, stanje čakanja in izid.

Merite več kot le obseg prenosov. Uporabni kazalniki vključujejo stopnjo ponavljanja informacij, stopnjo napačnih čakalnih vrst, čas od prenosa do prvega odziva človeka, opuščene prenose, zaključek rezervnih možnosti, popravke svetovalcev in rešitev po predaji. Povežite jih s širšimi ključnimi kazalniki uspešnosti (KPI) za AI klepetalnike, da ekipa ne bo optimizirala zadrževanja v boti na račun izidov za stranke.

Praktično zaporedje izvedbe

1. Izberite eno visoko vredno pot eskalacije z jasnim lastnikom.
2. Določite shemo konteksta in prepovedana polja.
3. Ustvarite besedila prehoda za stanja v živo, brez povezave in ob napakah.
4. Izvedite idempotentno ustvarjanje primerov in rezervno možnost čakalne vrste.
5. Izvedite scenarijske teste, nato pa spremljajte majhna nadzorovana uvajanja.
6. Tedensko preglejte popravke svetovalcev in ponavljanja strank.
7. Razširite šele, ko je prva pot stabilna.

ChatReact lahko podpira pogovorno plast uporabniške poti na spletnem mestu, vendar je zanesljiva predaja odvisna tudi od vaše integracije kanalov, modela identitete, lastništva čakalnih vrst, nadzora zasebnosti in delovnega časa. Obravnavajte te dele kot enoten načrtovan sistem. Rezultat ni zgolj bot, ki ve, kdaj se mora ustaviti; je prehod, ki mu stranke in ekipe za podporo lahko zaupajo.

Viri

• Microsoft Learn: Predaja agentu v živo
• Microsoft Learn: Upravljanje spremenljivk konteksta
• Google Cloud: Dialogflow CX izpolnjevanje in predaja agentu v živo
• Microsoft Learn: Nadzor dostopa do prepisov in hrambe