Žmogaus pagalba KI čatbote: kada svetainės palaikymo paslaugas turi perimti žmogus

KI čatbotas turi padėti svetainės lankytojams greičiau rasti tinkamą atsakymą. Palaikymo paslaugose tai yra tik pusė užduoties. Kita pusė prasideda būtent ten, kur botas nebesijaučia užtikrintas, nebegalvoja, kad tai jo kompetencija, arba nebegali būti naudingas: žmogaus pagalbos perdavimo metu. Turima taupoma planuota ongoing dialogo perėjimas žmogui, kad lankytojams nereikėtų kartoti savo užklausos, keisti kanalo ar pirmiausia „kaštis“ su botu.

Svetainės komandoms šis punktas yra strategiškai svarbus. Čatbotas, atsakantis į rutininis klausimus, mažina apkrovą palaikymo tarnybai. Čatbotas, kuris blokuoja tikras eskalacijas, didina frustraciją, pakartotinį susisiekimą ir pasitraukimo rodiklius. Todėl geriausias sprendimas yra ne „botas arba žmogus“, o aiškus perdavimo mechanizmas: botas išsprendžia tai, ką gali patikimai išspręsti, ir atveria kelią žmogui, kai tik tas tampa geresniu variantu.

Kodėl žmogaus pagalbos perdavimas nėra čatboto nesėkmė

Naujausi „Nielsen Norman Group“ UX tyrimai „perdavimo norą“ (Handoff willingness) įvardina kaip vieną pagrindinių svetainėms pritaikytų KI čatbotų savybių. Rekomendacija yra vienareikšminga: jei vartotojai aiškiai išreiškia norą kalbėtis su žmogumi, botas neturėtų šios užklausos atstumti. Taip pat pasikartojusios performulavimai, pastebima frustracija ar nepakankama atsakymų kokybė yra signalai, kad reikėtų pasiūlyti perdavimą.

Tai atitinka techninius projektavimo modelius. „Microsoft“ aprašo žmogaus pagalbą kaip tinkamiausią kelią, kai botas nesupranta užklausos arba kai procesas negali būti automatizuotas. „Google“ aprašo perdavimą „Dialogflow“ sistemoje kaip galutinio vartotojo pokalbio perdavimą žmogui agentui. Abi perspektyvos rodo: perdavimas nėra marginalus išimtinis atvejis, o pagrindinė rimto palaikymo srauvo dalis.

Kūrėdami tvarkingą perėjimo planą, galima netgi sustiprinti čatbotą. Lankytojai labiau pasitiki botu, kai jis žino savo ribas. Palaikymo komandos naudos gano, kai perdavimas pasiekia juos kartu su pokalbio santrauka, kalba, tema, prioritetu ir iki šiol suteiktais boto atsakymais. Tuomet žmogus nepradeda visko nuo nulio.

Svarbiausi perdavimo triggeriai

1. Lankytojas tiesiogiai prašo žmogaus

Aiškiausias triggeris yra tiesioginė formulacija, tokia kaip „žmogus“, „palaikymas“, „agentas“, „paskambinkite man“, „darbininkas“ arba „gyvas čatas“. Ši užklausa neturėtų būti paslėpta už kitų üçsių botų klausimų. Trumpas paaiškinimas gali būti naudingas, jei jis reikalingas maršrutizacijai, pavyzdžiui: „Ar tai susiję su sąskaita, technika ar pardavimais?“. Tačiau pats perdavimas turi būti pasiūlytas matomai ir įsipareigojamai.

2. Botas yra nepasitikrėjęs arba kartojasi

Botas neturėtų daryti tokio vaizdo, kad kiekvienas atsakymas būtų vienodai pagrįstas. Žema atsakymų tikrovebė, neatrasti atsakymų žinių bazėje, prieštaravimai šaltiniuose arba daukartiniai klausimai be pažangos yra geri vidiniai triggeriai. Praktiška taisyklė būtų tokia: po dviejų nesėkmingų paaiškinimo bandymų botas aktyviai pasiūlo perdavimą. Tai užkerta kelią begaliniams ciklams ir saugo suvokiamą atsakymų kokybę.

3. Užklausa reikalauja veiksmo, sprendimo arba atsakomybės

Dauguma svetainės klausimų yra informacinio pobūdžio: darbo valandys, kainų pradžia, dokumentacija, produktų palyginimas. Kiti reikalauja žmogaus: sutarties pakeitimai, nuoleidžimo sprendimai, skundai, sutarties nutraukimas, saugumo incidentai, medicininiai ar teisiniai individualūs atvejai, individualūs pasiūlymai ar asmeninės paskyros duomenys. Tokiais atvejais botas gali rinkti ir paruošti duomenis, tačiau jis neturėtų savarankiškai žadėti sprendimų, kurių įmonė nenori priimti automatizuotai.

4. Keičiasi kalba, tonas arba skubumas

Pasikartojančios didžiosios raidės, sakiniai kaip „tai nepadaža“, skundų terminai, pristatymo problemos, pranešimai apie sutrikimus ar mokėjimo terminai gali būti eskalacijos signalai. Svarbu čia nesudramatizuoti dirbtinai. Botas turi ramiai pripažinti situaciją ir pasiūlyti kitą žingsnį: „Perduodu tai mūsų palaikymo komandai ir pridedu ankstesnę pokalbio eigą“.

Ką reikėtų pridėti perduodant pokalbį

Žmogaus pagalbos perdavimas yra naudingas tik tada, jei žmogus mato kontekstą. „Microsoft“ perdavimo protokole numatyta, tarp kitų, konteksto duomenys ir transkriptas. Svetainės komandoms išto galima išsivystyti kompaktišką perdavimo sąrašą:

• trumpa vartotojo tikslo santrauka vienu sakiniu,
• paskutinės aktualios žinutės arba transkriptas,
• dabartinis puslapis, produktas, forma ar straipsnis, nuo kurio buvo pradėtas čatas,
• lankytojo kalba ir pageidaujamas kanalas,
• atpažinta kategorija, pavyzdžiui, palaikymas, pardavimai, sąskaitos ar technika,
• skubumas ir eskalacijos priežastis,
• šaltiniai ar žinių bazės straipsniai, kuriuos botas jau panaudojo,
• tik tie asmeniniai duomenys, kurie yra tikrai būtini apdorojimui.

Ypač paskutinis punktas yra lemiamas. Perdavimas nereiškia perduoti maksimaliai daug duomenų. Tai reiškia tvarkingai perduoti aktualius duomenis. Jei reikia jautrios informacijos, svetainės komandos turi aiškiai nustatyti, kokius duomenis botas išvis užklauso ir kada reikalingas saugus kanalas.

Praktiškai pritaikomas perdavimo srauvas

Kambinas srauvas prasidedanči ne tik klaidos metu. Jau pasveikinimas turėtų nustatyti rėmą: botas padeda atsakyti į tipinius svetainės klausimus ir esant poreikiui gali perduoti pokalbį komandai. Dialogo metu jis tiesiogiai atsako į paprastus klausimus, tiksliai teiriasi neaiškių užklausų ir nuorodai į aktualų turinį. Kai įveikiamas triggeris, jis trumpai paaiškina perėjimo priežastį.

Geras modelis yra: pirmiausia pripažinti, tada apibendrinti, tada pasiūlyti kitą veiksmą. Pavyzdys: „Aš negaliu patikimai ir galutinai tai išspręsti. Apibendrinu pateiktą informaciją ir perduodu ją mūsų palaikymo komandai“. Po to lankytojas turi matyti, kas vyksta: gyvas čatas, paskambučio grąžinimas, el. pašto bilietas, nuoroda į susitikimą arba kontakto forma. Jei žmogus nedelsiant nepriejengiamas, botas turi tai nuoširdžiai pasakyti ir pasiūlyti realią alternatyvą.

Komandoms su keliais filialais, kalbomis ar produktų linijomis papildomai rekomenduojamas maršrutizacijos žingsnis. Jis turėtų būti trumpas ir užklausti tik tęsiančią informaciją, kuri tikrai tarnauja paskirimui. Ilgas priešfiltravimas atrodo kaip barjeras ir priešauna perdavimo tikslui.

Geri perdavimo teksty yra trumpi ir įsipareigojami

Mikrokopija lemia, ar perėjimas atrodo patikimai. Vengkite sakinių kaip „Aš esu tik botas“ arba „To, deja, negaliu“. Geriau naudoti aiškias, veiksmą orientuotas formulacijas:

• „Perduodu šį čatą mūsų palaikymo komandai ir pridedu ankstesnę pokalbio eigą“.
• „Šiam klausimui žmogus yra geresnis kontakto asmuo. Ar sukurti bilietą su jūsų apibendrinimu?“
• „Radau dvi galimas priežastis, tačiau negaliu tiksliai nuspręsti. Perkeliau šį atvejį tolyiau“.
• „Šiuo metu gyvas agentas nepriejengamas. Galiu paruošti jūsų užklausą kaip bilietą arba parodyti tinkamiausią kontakto būdą“.

Šie tekstai neduoda pernelyg didelių pažadų. Jie paaiškina priežastį, mažina pasikartojimus ir suteikia lankytojui kontrolę kitam žingsniui.

KPI: ką komandos turėtų matuoti po starto

Perdavimo koncepcija tampa patikima tik tada, kai ji yra matuojama. Vienos automatizavimo lygios nepakanka, nes jos gali sukurti klaidingus paskatintus. Kas optimizuoja tik „mažesnį perdavimų kiekį“, rizikuoja, kad botas perilgai laikys sudėtingus atvejus. Tikslingiau naudoti kokybės ir efektyvumo metrikų kombinaciją:

• perdavimo rodiklis pagal temą ir puslapį,
• sėkmingai priimtų perdavimų dalis,
• laukimas iki žmogaus atsakymo,
• pasikartojimo rodiklis po perdavimo,
• išsprendimo rodiklis ir pakartotinis susisiekimas nustatytu laiku,
• boto pasitikėjimas prieš eskalaciją,
• nutraukimo rodiklis perdavimo srauvose,
• boto sugeneruotos santraukos kokybė.

Skaičiai turi būti reguliariai lyginami su tikrais čato eigomis. Aukštas perdavimo rodiklis gali būti blogas, jei paprasti klausimai nereikalingai eskaluojami. Tačiau jis gali būti geras, jei botas anksti atpažįsta sudėtingus atvejus ir juos tvarkingai paruošia. Kontekstas yra svarbesnis už vieną tikslinį skaičių.

Kontrolinis sąrašas svetainės valdytojams

• Apskrīkite, į kokius klausimus botas gali atsakyti savarankiškai.
• Surašykite aiškius perdavimo triggerius norint kalbėtis su žmogumi, nesavisiškumui, frustracijai ir neautomatizuojamiems procesams.
• Apribokite paaiškinimo bandymų skaičių prieš siūlant perdavimą.
• Išsaugokite trumpą, patikrinamą pokalbio santrauką agentams.
• Perduokite kalbą, puslapį, kategoriją ir aktualius šaltinius.
• Venkite nereikalingų asmeninių duomenų boto dialoge.
• Suplanuokite offline scenarijus, kad botas neparduotų pokalbio į niekur.
• Testuokite desktop ir mobile versijas, nes perdavimo mygtukai mažuose ekranuose dažnai mažiau pastebimi.
• Kiekvieną savaitę peržiūrėkite tikrus perdavimus ir koreguokite triggerius.

Dažniausios klaidos

Dažniausia klaida yra „gatekeeping“: lankytojas prašo žmogaus, tačiau botas užduoda kitus privalomus klausimus. Be beveik tiek pat kenkiančia yra perdavimas be konteksto, kai žmogus turi visko klausti iš naujo. Trečia klaida yra netinkamas sėkmės matavimas. Jei žemas perdavimo rodiklis laikomas sėkme, nors skundai ir pakartotiniai susisiekimai auga, komanda optimizuoja procesą ne vartotojo tikslu.

Geras KI čatbotas nėra tas, kuris kiekvieną dialogą pabaigtų vienas. Geras botas yra tas, kuris patikimai sprendžia paprastas užduotis, transparentuojančias ribas ir įtraukia žmogų būtent tada, kai tai geriausia lankytojui ir komandai. Kas sąmoningai sukuria šį perėjimą, jungia automatizaciją su paslaugų kokybe.

Skaitykite daugiau ir šaltiniai

Kurdamas perdavimą, verta pažvalgyti palyginimą KI čatbotas vs. gyvas čatas vs. kontakto forma, palaikymo pagrindus straipsnyje Kaip KI čatbotas pagerina svetainės klientų aptarnavimą ir matavimo logiką KI čatboto KPI. Specializuoti šio įrašo šaltiniai yra „Nielsen Norman Group“ straipsniai The 5 Qualities of Site-Specific AI Chatbots ir The User Experience of Chatbots, „Microsoft Learn“ apie Bot-to-Human Handoff bei „Google Cloud“ dokumentacija apie Dialogflow ES Handoff.