DI pokalbių botų perdavimo žmogui kūrimas: konteksto paketai, nukreipimas ir eilės patirtis

Dirbtinio intelekto (DI) pokalbių botas gali atpažinti, kad pokalbiui reikalingas žmogus, tačiau vis tiek suteikti prastą aptarnavimo patirtį. Klientai dažniausiai nusivilia paties perėjimo metu: klientas turi kartoti savo istoriją, užklausa patenka į netinkamą eilę, santraukoje pasirodo jautri informacija arba niekas nepaaiškina, kas vyks toliau. Kokybiškas DI pokalbių botų perdavimo kūrimas vertina eskalavimą kaip mažą operacinę sistemą, o ne kaip paskutinį boto sakinį.

Šiame vadove dėmesys skiriamas etapui po sprendimo eskaluoti: konteksto paketui, nukreipimo sutarčiai, patirčiai eilėje, privatumo riboms, konsultanto darbo vietai ir kokybės patikrai. Jei pirmiausia turite nuspręsti, kada automatizavimas turėtų sustoti, perskaitykite mūsų atskirą vadovą apie DI pokalbių botų perdavimo žmogui trigerius svetainės aptarnavime.

Apibrėžkite perdavimą kaip sutartį tarp trijų dalyvių

Perdavimo procese dalyvauja klientas, automatizuota sistema ir užklausą gaunanti komanda. Kiekvienam dalyviui reikia aiškios sutarties. Klientui reikia žinoti, kad automatizavimas sustabdytas, kokia informacija bus perduota toliau, koks kanalas bus naudojamas ir ar reikės palaukti. Botui reikia aiškios taisyklės kontekstui surinkti ir išsiųsti. Užklausą gaunančiai komandai reikia numatomo duomenų paketo, atsakomybės taisyklių ir atsarginio plano, kai pageidaujama eilė nepasiekiama.

Prieš jungdami įrankius, aprašykite šią sutartį. Naudinga vieno puslapio specifikacija atsako į šešis klausimus:

• Koks įvykis inicijuoja perdavimą?
• Kokie laukai duomenų pakete yra privalomi, pasirenkami arba draudžiami?
• Kuri eilė yra atsakinga už kiekvieną problemos tipą?
• Ką klientas mato prieš perdavimą, jo metu ir po jo?
• Kas vyksta ne darbo valandomis arba nutrūkus ryšiui?
• Kokie įvykiai ir rezultatai fiksuojami kokybės kontrolei (QA)?

Tai padeda išvengti dažnos architektūrinės klaidos: vertinti tiekėjo perdavimo signalą kaip visą darbo eigą. Pavyzdžiui, „Google Cloud“ „Dialogflow CX“ dokumentacijoje paaiškinama, kad perdavimo gyvam konsultantui atsakas yra signalas jį kviečiančiai integracijai; pati sistema vis tiek priima sprendimą dėl tolesnių veiksmų. Ta pati taisyklė galioja daugumai pokalbių botų sistemų.

Sukurkite glaustą konteksto paketą, o ne nefiltruotą pokalbio išrašą

Užklausą gavęs darbuotojas turėtų suprasti situaciją nereikalaudamas, kad klientas kartotų viską iš naujo. Tai nereiškia, kad reikia persiųsti kiekvieną įmanomą lauką. Naudingas paketas apjungia trumpą santrauką, kelis struktūrizuotus faktus ir nuorodą į pokalbio išrašą, kai prieiga prie jo yra tinkama.

Naudokite keturis konteksto sluoksnius

1. Perdavimo priežastis: aiškus trigeris, pavyzdžiui, kliento prašymas, pasikartojanti klaida, paskyros veiksmas arba taisyklės išimtis.
2. Kliento tikslas: vienas neutralus sakinys, apibūdinantis, ką klientas bando pasiekti.
3. Patikrinti struktūrizuoti laukai: kalba, tema, užklausos ar užsakymo numeris, autentifikavimo būsena, skuba ir pageidaujamas kanalas (jei taikoma).
4. Pokalbio įrodymai: apribotas pokalbio išrašas arba nuoroda, leidžianti konsultantui peržiūrėti originalią formuluotę.

Pažymėkite spėjamas reikšmes kaip spėjamas. Modelio sugeneruota santrauka niekada neturėtų tyliai paversti spėjimo faktu. Pavyzdžiui, „klientas atrodo nusivylęs“ yra interpretacija; „klientas dukart paprašė žmogaus“ yra stebimas įvykis. Struktūrizuoti faktai turėtų būti gaunami iš patikrintų įvesčių arba patikimų sistemų.

„Microsoft“ dokumentacijoje nurodoma, kad „Copilot Studio“ perdavimo metu gali dalintis pokalbių istorija bei susijusiais kintamaisiais, o „Dynamics 365“ gairėse rodoma, kaip konteksto kintamieji padeda nukreipti užklausas ir didina konsultantų produktyvumą. Šios galimybės yra naudingi pavyzdžiai, tačiau pačių laukų struktūros kūrimas išlieka organizacijos atsakomybe.

Atskirkite nukreipimo duomenis nuo pokalbio turinio

Nukreipimas turėtų remtis stabiliais, patikrinamais laukais, o ne vien laisvos formos santrauka. Eilės valdymo sistema gali naudoti problemos kategoriją, kalbą, autentifikavimo būseną, produkto sritį, aptarnavimo lygį ar skubos kodą. Naratyvinė santrauka padeda žmogui suprasti situaciją, tačiau ji neturėtų būti vienintelis pagrindas prieigos valdymui ar prioritetų nustatymui.

Sukurkite nukreipimo lentelę su atsakingu asmeniu ir atsarginiu variantu kiekvienam palaikomam deriniui. Pirmoji versija turėtų būti nedidelė. Dešimt tikslių maršrutų paprastai yra lengviau valdomi nei dešimtys persidengiančių taisyklių. Kiekvienam maršrutui apibrėžkite:

• pagrindinę eilę ir darbo valandas;
• atsarginę eilę arba asinchroninį kanalą;
• reikalingus įgūdžius ir kalbų palaikymą;
• didžiausią priimtiną laukimo trukmę;
• ką mato klientas, jei nėra laisvo konsultanto.

Jei naudojami asmeniniai duomenys, nukreipimas privalo atsižvelgti į tapatybės ribas. Viešas svetainės pokalbis neturėtų gauti paskyros lygio prieigos vien todėl, kad yra perduodamas konsultantui. Mūsų vadove apie viešus ir autentifikuotus klientų portalo pokalbių botus pateikiamas praktiškas šių kelių atskyrimo modelis.

Sukurkite eilės patirtį kaip pokalbio dalį

Kliento požiūriu, perdavimas prasideda dar prieš prisijungiant konsultantui. Perdavimo žinutėje turėtų būti nurodyta, kas vyksta, kokia informacija jau perduota ir ką klientas gali daryti toliau. Venkite pažadų, kurių eilė negali užtikrintai įvykdyti.

Naudingas žinutės pavyzdys: „Perduodu šį pokalbį mūsų grąžinimų komandai. Perduosiu jūsų užsakymo numerį ir aukščiau pateiktą santrauką, todėl jums nereikės jų kartoti. Galite likti čia arba pasirinkti el. paštą, jei pageidaujate atsakymo el. paštu.“ Pritaikykite formuluotę pagal faktines galimybes ir aptarnavimo lygį.

Kai aptarnavimas gyvai nepasiekiamas, pasiūlykite realią alternatyvą, o ne aklavietę. Tai gali būti struktūrizuota kontaktų forma, užklausos sukūrimas, skambučio užsakymas arba aiškiai nurodytas darbo laikas. Palyginkite šių kanalų pranašumus straipsnyje DI pokalbių botas vs. gyvas pokalbis vs. kontaktinė forma.

Apsaugokite pokalbio išrašą ir santrauką jau kūrimo etape

Perdavimas gali išplėsti prieigą prie pokalbio duomenų. Apibrėžkite, kas gali peržiūrėti išrašus, kiek laiko jie saugomi, kokie laukai gali būti rodomi santraukose ir ar jautrios reikšmės turėtų būti pašalintos prieš perdavimą. Į paketą nedėkite slaptažodžių, mokėjimo duomenų, autentifikavimo kodų ar nereikalingų specialiųjų kategorijų duomenų.

Prieiga prie išrašų yra leidimų, o ne tik patogumo klausimas. „Microsoft“ išrašų valdymo gairės iliustruoja poreikį atskirai valdyti saugojimo terminus ir vartotojų roles. Taikykite šį principą bet kuriai sistemai: konsultantai turėtų gauti tik minimalų užklausai reikalingą kontekstą, o prieiga turi būti audituojama pagal jūsų saugumo bei privatumo reikalavimus.

Taip pat patikrinkite atsparumą komandų įterpimo atakoms („prompt injection“). Kliento įvestas tekstas generuojamoje santraukoje ar konsultanto darbo vietoje turi išlikti nepatikrintu turiniu. Jam neturi būti leidžiama keisti nukreipimo taisyklių, leidimų ar vidinių instrukcijų.

Suteikite užklausą gaunančiam konsultantui funkcionalią darbo vietą

Ideali darbo vieta prasideda nuo kliento tikslo, perdavimo priežasties, patikrintų laukų ir rekomenduojamo kito veiksmo. Visas pokalbio išrašas išlieka pasiekiamas, tačiau neužima viso ekrano. Konsultantai turėtų turėti galimybę pataisyti netikslią kategoriją ar santrauką neperrašinėdami visko iš naujo.

Fiksuokite šiuos pataisymus kaip kokybės kontrolės (QA) signalus. Pasikartojantys tos pačios kategorijos pakeitimai gali rodyti nukreipimo taisyklės problemą. Pasikartojantys santraukos pataisymai gali rodyti silpnus nurodymus (promptus), trūkstamą šaltinio kontekstą arba netinkamą apibendrinimo žingsnį. Neleiskite konsultantams tyliai taisyti automatizavimo klaidų.

Išbandykite perėjimo procesą nuo pradžios iki galo

Perdavimo mygtukas gali veikti, tačiau klientas vis tiek patirs nesklandumų. Sukurkite perdavimo testavimo matricą, apimančią kliento formuluotes, kanalo būseną, eilės pasiekiamumą, tapatybės būseną, kalbą, duomenų jautrumą ir atsistatymą po klaidų.

Minimalus patikros sąrašas (Checklist)

• Tiesioginis prašymas sujungti su žmogumi įvykdomas be įtikinėjimo ciklų.
• Klientas mato tikslią perėjimo ir laukimo žinutę.
• Tinkama eilė gauna užklausą reikiama kalba.
• Patikrinti faktai išlieka atskirti nuo modelio spėjimų.
• Konsultantas gauna žadėtą kontekstą vieną kartą, be dublikatų.
• Nepasiekiamos eilės pateikia tinkamą atsarginį variantą.
• Apsaugoti duomenys pašalinami arba jiems apribojama prieiga.
• Atkartoti bandymai nesukuria dubliuotų bilietų ar dvigubos atsakomybės.
• Klientas gali tęsti pokalbį po laikinos perdavimo klaidos.
• Analitika fiksuoja trigerį, maršrutą, laukimo būseną ir rezultatą.

Matuokite ne tik perdavimų skaičių. Naudingi rodikliai apima informacijos kartojimo dažnumą, patekimą į netinkamą eilę, laiką nuo perdavimo iki pirmo konsultanto atsako, nutrūkusius perdavimus, atsarginių variantų užpildymą, konsultantų pataisymus ir sprendimo rodiklį po perdavimo. Derinkite juos su platesniais DI pokalbių botų KPI, kad komanda neoptimizuotų užklausų sulaikymo kliento patirties sąskaita.

Praktiškas diegimo žingsnių sekos pavyzdys

1. Pasirinkite vieną didelės vertės eskalavimo maršrutą su aiškiu atsakingu asmeniu.
2. Apibrėžkite konteksto schemą ir draudžiamus laukus.
3. Sukurkite perėjimo žinutes aktyviai, neaktyviai (offline) ir klaidos būsenoms.
4. Įdiekite idempotentinį užklausų kūrimą ir atsarginę eilę.
5. Atlikite testus pagal scenarijus, tada stebėkite nedidelį kontroliuojamą paleidimą.
6. Kas savaitę peržiūrėkite konsultantų pataisymus ir kliento informacijos kartojimus.
7. Išplėskite tik tada, kai pirmasis maršrutas taps stabilus.

ChatReact gali palaikyti svetainės aptarnavimo pokalbių sluoksnį, tačiau patikimas perdavimas taip pat priklauso nuo jūsų kanalų integracijos, tapatybės modelio, eilių valdymo, privatumo kontrolės ir darbo valandų. Vertinkite šiuos elementus kaip vientisą suprojektuotą sistemą. Rezultatas yra ne tiesiog botas, žinantis, kada sustoti, o perėjimas, kuriuo gali pasitikėti tiek klientai, tiek aptarnavimo komanda.

Šaltiniai

• Microsoft Learn: Hand off to a live agent
• Microsoft Learn: Manage context variables
• Google Cloud: Dialogflow CX fulfillments and live-agent handoff
• Microsoft Learn: Control transcript access and retention