AI pokalbių botas aptarnavimui po pardavimo: užsakymai, grąžinimai ir garantija
Sukurkite AI pokalbių botą užsakymų būsenos, grąžinimų ir garantijos klausimams neatskleisdami klientų duomenų, nežadėdami neįmanomų rezultatų ir neįkalindami žmonių automatizacijoje.
Klientui spustelėjus „pirkti“, jo klausimai tampa konkretesni ir jautresni. Jie nori žinoti, kur yra užsakymas, ar prekę galima grąžinti, ką apima garantija ir kas išspręs iškilusią problemą. AI pokalbių botas aptarnavimui po pardavimo gali pagreitinti šiuos procesus, tačiau tik tada, kai jis atskiria viešąją informaciją nuo paskyros duomenų, patikrina faktus prieš atsakydamas ir perduoda neaiškius atvejus atsakingam asmeniui.
Šiame vadove paaiškinama, kaip sukurti veikimo modelį trisdešimčiai dažnų naudojimo atvejų: užsakymo būsenai, grąžinimams bei garantiniams ar remonto atvejams. Tikslas nėra pakeisti kiekvieną klientų aptarnavimo pokalbį. Tikslas – automatizuoti pasikartojančias dalis, užtikrinant aiškią tapatybę, taisykles, įrodymus, išimtis ir žmogaus atsakomybę.
Pradėkite nuo trijų skirtingų eigos scenarijų, o ne nuo vieno bendro pagalbos boto
„Kur yra mano siunta?“, „Ar galiu tai grąžinti?“ ir „Kodėl šis produktas sugedo?“ gali patekti per tą patį pokalbio langą, tačiau jiems reikalingi skirtingi duomenys ir sprendimai. Žiūrėkite į juos kaip į atskirus scenarijus su jų pačių įvesties duomenimis, patikimais šaltiniais, klaidų būsenomis ir perdavimo taisyklėmis.
- Užsakymo būsena paprastai reikalauja autentifikuotos prieigos prie konkretaus užsakymo ir siuntos įvykių.
- Grąžinimai sujungia bendrą taisyklių informaciją su datomis, produktų išimtimis, užsakymo būsena ir valdomu prašymo procesu.
- Garantija arba remontas gali reikalauti pirkimo įrodymo, produkto identifikavimo, gedimo detalių, trikčių šalinimo ribų ir specialisto peržiūros.
Bendra pokalbio sąsaja gali atpažinti ketinimą ir surinkti minimalią reikalingą informaciją. Už jos kiekvienas scenarijus turėtų kviesti tikslinę paslaugą su apibrėžtomis teisėmis. Tai saugiau ir lengviau išbandyti nei suteikti vienai užklausai plačią prieigą prie prekybos, logistikos ir aptarnavimo sistemų.
Brėžkite griežtą ribą tarp viešų ir autentifikuotų atsakymų
Lankytojas, kuris neprisijungė, gali gauti viešą informaciją: pristatymo regionus, įprastus proceso žingsnius, paskelbtą grąžinimo politiką, kontaktinius kanalus arba kokie dokumentai paprastai reikalingi remonto paraiškai. Jis neturėtų gauti tikros užsakymo būsenos tik pagal užsakymo numerį, vardą, pašto kodą ar kitą lengvai sužinomą detalę.
Norėdami pateikti konkretaus užsakymo atsakymus, nukreipkite klientą į autentifikuotą aplinką ir užtikrinkite autorizaciją serveryje. Modelis niekada neturi spręsti, ar vartotojas gali matyti užsakymą. Jūsų programa turėtų atpažinti prisijungusį klientą, pateikti užklausas tik apie tuos išteklius, prie kurių tas klientas turi prieigą, ir grąžinti nedidelį, tikslinį rezultatą. Mūsų vadove apie autentifikuotą AI pokalbių boto prieigą prie klientų portalo duomenų ši riba aprašyta išsamiau.
Naudokite neutralų perėjimo tekstą, kai reikalaujama autentifikavimo: paaiškinkite, kodėl reikalingas kitas žingsnis, išsaugokite tik saugų pokalbio kontekstą ir venkite prašyti kliento įvesti slaptažodžius, visus mokėjimo kortelių numerius ar tapatybės dokumentus į laisvą tekstą.
Užsakymo būsena: paaiškinkite įvykius neišgalvodami netikro užtikrintumo
Logistikos sistemos dažnai pateikia trumpus įvykių kodus. Pokalbių boto užduotis – paprasta kalba paaiškinti patvirtintą įvykį, o ne spėlioti be įrodymų. Sukurkite tikslų atitikmenų žemėlapį iš kurjerių ar įvykdymo būsenų į klientui suprantamus paaiškinimus. Įtraukite įvykio datą ir laiką bei, kai įmanoma gauti iš patikimo šaltinio, kitą numatomą žingsnį.
Pasiruoškite pasenusiems, prieštaringiems ir nepilniems sekimo duomenims
Patikimas srautas skiria būsenas „etiketė sukurta“, „perduota kurjeriui“, „pakeliui“, „pristatoma“, „pristatyta“, „vėluoja“ ir „išimtis“. Jis taip pat atpažįsta, kai duomenys yra pasenę. Jei vidinė sistema rodo, kad išsiųsta, bet kurjeris dar neturi nuskaitymo įrašo, parodykite patvirtintus faktus ir paaiškinkite, kad sekimo informacija gali atsinaujinti ne iš karto. Neišgalvokite pristatymo datos vien tam, kad atsakymas skambėtų išsamiau.
Perduokite klausimą žmogui, kai pristatymo įvykis yra ginčijamas, dėl išimties reikia pakeisti adresą, dingo didelės vertės siunta arba duomenų šaltiniai prieštarauja vienas kitam ilgiau nei nustatytas laikas. Perdavimas turėtų apimti autorizuotą užsakymo kodą, naujausius patvirtintus įvykius ir kliento įvardytą problemą, o ne visą neapdorotą pokalbį.
Grąžinimai: atskirkite tinka-netinka konsultacijas nuo galutinio sprendimo
Pokalbių botas gali paaiškinti paskelbtą grąžinimo procesą, surinkti priežastį, parodyti galimus būdus ir sukurti prašymą po to, kai serverio sistema patikrina užsakymą. Jis neturėtų improvizuoti teisinių išvadų ar žadėti pinigų grąžinimo, kol nepatikrintos reikiamos sąlygos.
Pavyzdžiui, ES vartotojams oficialiose „Your Europe“ gairėse aprašomas bendras 14 dienų atsisakymo laikotarpis daugeliui nuotolinių pirkimų ir išvardijamos svarbios išimtys. Ta pati svetainė atskiria šią atsisakymo teisę nuo teisių gynimo priemonių dėl nekokybiškų prekių. Tikslios teisės ir procedūros priklauso nuo sandorio, produkto, pardavėjo, šalies ir galiojančių įstatymų, todėl pateikite oficialų taisyklių tekstą ir nukreipkite neaiškius atvejus peržiūrai, užuot pavertę bendrą taisyklę automatiniu sprendimu.
Užtikrinkite, kad kiekvienas atsakymas apie grąžinimą būtų atsekamas
Išsaugokite versijuotą taisyklių identifikatorių kartu su rezultatu. Užklausų paslauga – o ne kalbos modelis – turėtų įvertinti pirkimo datą, pristatymo datą, produkto klasę, grąžinimų istoriją ir taikomus išimčių kodus. Tuomet atsakyme galima paaiškinti rezultatą naudojant patvirtintas formuluotes. Jei produktas gali būti netaikomas dėl higienos, individualizavimo, greito gedimo, skaitmeninio pristatymo ar kitos priežasties, užduokite tik tuos klausimus, kurių reikia keliui nustatyti, ir venkite skelbti rezultatą pagal neaiškų aprašymą.
Parodykite klientui, kas vyks toliau: ar bus sukurta etiketė, kur turi keliauti siunta, kurios prekės turi būti viduje, kaip galima sekti grąžinimą ir kada gali prireikti patikrinimo. Venkite žadėti konkrečių dienų skaičiaus, kol pirminė sistema nepateikia patikimos, konkrečiam atvejui skirtos datos.
Garantija ir remontas: rinkite įrodymus neatlikdami diagnostikos už ribų
Pokalbiuose dėl garantijos dažnai maišomos kelios sąvokos: komercinė garantija, įstatymų numatytos teisės dėl nekokybiškų prekių, mokama remonto paslauga ir bendras trikčių šalinimas. Laikykite šiuos kelius atskirtai žinių bazėje ir atvejo tipe, siunčiamame aptarnavimo komandai.
Oficialiose ES vartotojų gairėse teigiama, kad vartotojai paprastai turi mažiausiai dviejų metų teisinę garantiją nekokybiškoms prekėms, pirktoms iš pardavėjo, o nacionalinės taisyklės gali suteikti papildomą apsaugą. Komercinė garantija gali suteikti papildomų pažadų, tačiau ji neturėtų būti pateikiama kaip pakeičianti galiojančias įstatymų numatytas teises. Tai yra bendro pobūdžio informacija, o ne teisinė konsultacija; pokalbių botas turėtų pateikti nuorodą į dabartines pardavėjo sąlygas ir nukreipti ginčus ar neaiškius atvejus specialistams.
Rinkite struktūrizuotus įrodymus: gaminio modelį iš valdomo katalogo, pirkimo kodą po autentifikavimo, simptomų kategoriją, kada atsirado gedimas ir kokių patvirtintų trikčių šalinimo veiksmų buvo imtasi. Leiskite kelti nuotraukas tik tada, kai jūsų saugojimo, saugojimo trukmės, prieigos kontrolės ir ištrynimo procesas yra tam pritaikytas. Niekada neprašykite kliento atidaryti elektrinių prietaisų, apeiti saugos mechanizmų ar atlikti rizikingu diagnostikos veiksmų.
Taikykite duomenų kiekio mažinimą visam procesui
Duomenų apsauga neišsprendžiama tiesiog pridedant sakinį prie pokalbio sveikinimo žinutės. Europos Komisijos BDAR (GDPR) principai pabrėžia tikslo apribojimą, duomenų kiekio mažinimą, saugojimo trukmės apribojimą, tikslumą ir atitinkamą saugumą. Taikykite šiuos principus pokalbių tekstui, užsakymų paieškai, įrankių rezultatams, agentų santraukoms, priedams, analitikai ir atsarginėms kopijoms.
- Rinkite tik tuos laukus, kurių reikia pasirinktam scenarijui.
- Nelaikykite slaptažodžių ir pilnų mokėjimo duomenų pokalbyje.
- Prieš apdorodami modelį, pašalinkite arba praleiskite nereikalingas asmens detales.
- Apribokite įrankių teises pagal scenarijų ir autentifikuotą klientą.
- Atskiriu apibrėžkite pokalbių išrašų, atvejų ir priedų saugojimo trukmę.
- Registruokite prieigą ir būsenos pokyčius nekopijuodami jautrių duomenų į žurnalus.
Vieši DUK gali naudoti privatumą užtikrinančią svetainės pokalbių boto sąranką. Su užsakymais susijusiam palaikymui reikalingos griežtesnės tapatybės ir autorizacijos kontrolės priemonės, aprašytos aukščiau.
Kurkite įrankius, kurie grąžina faktus, o ne duomenų bazės triukšmą
Kiekvienas pokalbių boto įrankis turėtų turėti aiškią, siaurą paskirtį. Užsakymo būsenos įrankis gali grąžinti autorizuotą užsakymo kodą, įvykdymo būseną, naujausią kurjerio įvykį, laiko žymą, saugų kitą žingsnį ir perdavimo žymą. Grąžinimo įrankis gali grąžinti tinkamumo būseną, taisyklių versiją, galimus būdus, reikalingus veiksmus ir peržiūros priežastį. Remonto įrankis gali grąžinti aptarnavimo maršrutą, įrodymų sąrašą, saugos pranešimą ir atvejo ID.
Patikrinkite visas įvestis serverio pusėje. Naudokite idempotentiškumo raktus, kai įrankis sukuria grąžinimo ar remonto atvejį, kad kartotiniai modelio kvietimai nesukurti dubliuotų užklausų. Laikykite laiko limitų viršijimus (timeouts) nežinomais rezultatais: prieš bandydami iš naujo, patikrinkite, ar operacija buvo baigta. Laikykite klientui rodomas formuluotes atskirtas nuo pačios transakcijos, kad formuluotės pakeitimas nepakeistų verslo logikos.
Sukurkite sąžiningą alternatyvų scenarijų ir perdavimą žmogui
Pokalbių botas turėtų sustoti, kai neįmanoma nustatyti tapatybės, taisyklių rezultatas yra dviprasmiškas, klientas ginčija pristatymą ar sprendimą, gali kilti pavojus saugumui, sistemos nesutaria arba klientas paprašo žmogaus pagalbos. Paaiškinkite priežastį tinkamu lygmeniu, neatskleisdami vidinių sukčiavimo ar rizikos taisyklių.
Perduokite kompaktišką konteksto paketą: patvirtintus kliento ir užsakymo kodus, pasirinktą scenarijų, jau gautus patikimus faktus, jau atliktus veiksmus, kliento pageidaujamą rezultatą ir tikslų neišspręstą klausimą. Gerai suprojektuotas pokalbių boto perdavimas žmogui su kontekstu ir nukreipimu užkerta kelią informacijos kartojimuisi ir suteikia priimančiai komandai aiškią atsakomybę.
Testuokite rezultatus, o ne tik sklandžius atsakymus
Sukurkite testų rinkinį įprastiems atvejams, ribinėms datoms, produktų išimtims, trūkstamiems nuskaitymams, prieštaringiems įvykiams, neautorizuotiems užsakymams, pasibaigusioms sesijoms, pasikartojantiems įrankių kvietimams, paslaugų teikėjų laiko limitų viršijimams, nesaugioms remonto užklausoms ir kenkėjiškoms instrukcijoms. Kiekvienam scenarijui patikrinkite atsakymą, įrankio kvietimą, teisių patikrinimą, audito įvykį, sukurtą įrašą, klientui matomą būseną ir perdavimo duomenis.
Matuokite savitarnos rodiklį (containment) tik kartu su teisingumu ir kliento pastangomis. Naudingi veiklos rodikliai apima patvirtintą savitarnos pabaigą, neautorizuotos prieigos blokavimus, atvejų dubliavimąsi, neteisingų taisyklių incidentus, pakartotinius kreipimusis, perdavimo tikslumą ir laiką iki atsakingo asmens paskyrimo. Išsamesnis vadovas apie AI pokalbių boto KPI paaiškina, kodėl vien tik nukreipimo rodiklio nepakanka.
Įgyvendinimo kontrolinis sąrašas
- Pasirinkite vieną scenarijų ir apibrėžkite jo tiesos šaltinį.
- Atskirkite viešas gaires nuo autentifikuotų kliento duomenų.
- Perkelkite tinkamumo ir autorizavimo sprendimus į serverio paslaugas.
- Versijuokite taisykles ir susiekite sistemos būsenas su patvirtintais paaiškinimais.
- Sumažinkite pokalbio išrašų, įrankių, priedų ir perdavimo duomenų kiekį.
- Pridėkite idempotentiškumą, atsistatymą po laiko limito viršijimo ir audito įvykius.
- Apibrėžkite perdavimo trigerius, eilių atsakomybę ir veikimą neprisijungus.
- Išbandykite įprastus, ribinius, klaidų, privatumo ir saugumo scenarijus.
- Įdiekite palaipsniui ir peržiūrėkite tikrus pataisymus prieš plėsdami.
Aptarnavimo po pardavimo automatizacija veikia geriausiai, kai ji daro mažiau, bet patikimai. Pradėkite nuo vieno dažniausio scenarijaus, sujunkite jį su patikrintais faktais, padarykite kiekvieną verslo sprendimą tikslų ir nustatytą, bei išlaikykite aiškų kelią iki žmogaus. Tai suteikia klientams greitesnius atsakymus nepaverčiant naudingo pokalbio nekontroliuojama užsakymų valdymo sąsaja.
Šaltiniai
Paverskite svetainės lankytojus geresniais pokalbiais
Sumažinkite pagalbos apkrovą išlaikydami nuoseklius atsakymus
Suteikite lankytojams akimirksnius svetainės palaikymą, nukreipkite išimtinius atvejus savo komandai ir užtikrinkite, kad kiekvienas atsakymas atitiktų jūsų patvirtintą žinių bazę.
Susiję straipsniai
Tęsti skaitymą

Viešas DI pokalbių botas ir klientų portalas: kaip saugiai atskirti tapatybę ir prieigą prie duomenų
Viešas svetainės pokalbių botas ir autentifikuotas DI pokalbių botas klientų portale reikalauja skirtingų duomenų, įrankių ir saugumo ribų. Šiame vadove pateikiama praktiška architektūra ir testavimo matrica.
AI pokalbių robotai ir BDAR: ką svetainių savininkai privalo patikrinti
Praktinis kontrolinis sąrašas komandoms, kurios nori naudoti AI pokalbių robotą savo svetainėje, neignoruojant privatumo, duomenų minimizavimo ir operacinės rizikos.

DI pokalbių botų perdavimo žmogui kūrimas: konteksto paketai, nukreipimas ir eilės patirtis
Patikimas pokalbių boto perdavimas klientų aptarnavimo specialistui yra daugiau nei tiesiog perdavimo mygtukas. Sužinokite, kaip supakuoti kontekstą, nukreipti užklausą, valdyti eilės lūkesčius, apsaugoti duomenis ir išbandyti visą perėjimo procesą.