Daugiakalvė leadų kvalifikacija su DI čatbotu: klausimai, duomenų apsauga ir perdavimas

Daugiaugalbis DI pokalbių botas gali atpažinti susidomėjimą, atsakyti į klausimus ir pasiruošti kitam prasmingam žingsniui. Tačiau potencialių klientų kvalifikavimas neveikia tiesiog išveržus vokiečių kalbos formą žodžiais į 23 kitas kalbas. Kokybiškas kvalifikavimas jungia aiškią pokalbių logiką su lokaliais suprantamais klausimais, taupoma duomenų rinkimu ir suprantamu perleidimu į tinkamą komandą.

Šis vadovas parodo, kaip svetainių operatoriai gali suplanuoti tokį procesą: kokios informacija yra tikrai būtina? Kada užtenka anonyminio preliminario kvalifikavimo? Kaip išlaikyti aiškų skirtumą tarp sutikimo, duomenų apsaugos informacijos ir rinkodaros? Ir kaip patikrinti, ar logika kiekvienoje kalboje iš tikrųjų veikia?

Daugiaugalbios potencialių klientų kvalifikavimas yra daugiau nei išversta forma

Statinė forma dažniausiai užklausia tų pačių laukų ta mesma tvarka. Tuo tarpu pokalbių botas gali pirmiausia suprasti poreikį ir tik tada užduoti klausimus, kurie yra aktualūs šiam konkrečiam atvejui. Kas turi klausimą apie produktą, turi naudoti kitą kelią nei tas, kuris nori gauti pasiūlymą, paskambučio grįžtamumą arba techninę pagalbą.

Daugiaugalbumas didina kokybės reikalavimus. Tokie terminai kaip „konsultacija“, „pasiūlymas“ arba „demo“ skirtinguose rinkose sukelia skirtingus lūkesčius. Telefonų numeriai, kreipimosi formos, datų formatai ir pageidaujami kontakto kanalai taip pat skiriasi. Todėl kiekvienai lokalizacijai reikia ne tik išversto teksto, bet ir redakciškai patikrintos pokalbių versijos su tokia pačia specializuota prasme.

Pagrindu išlieka bendras, nuo lokalizacijos nepriklausomas logika: atpažinti užklausą, patikrinti tinkamumą, kontaktinių duomenų klausti tik esant poreikiui, paaiškinti tikslą ir vėliau perduoti į tinkamiausią procesą. Straipsnis „Daugiakalviai KI pokalbių robotai tarptautinėms svetainėms“ aprašo platesnę už tai slystantčią architektūrą.

Tikslinis vaizdas: nuo susidomėjimo iki tinkamiausio kitos žingsnio

„Lead“ kvalifikavimas neturėtų rinkti kiek įmanoma daugiau duomenų. Jis turėtų enable-ti priimti sprendimą. Po trumpo dialogo turi būti aišku, koks kitas žingsnis būtų prasmingas asmeniui ir įmonei. Tipiniai rezultatai yra:

• tiesioginis atsakymas be duomenų rinkimo, jei žinių bazė visiškai išspris užklausą;
• kvalifikuotą kontakto užklausą su minimalia informacija, kurios atsakingai komandai reikia atsakymui;
• tiesioginį perdavimą, jei prieinamas darbininkas gali padėti nedelsdamžiai;
• at paskambučio arba susitikimo pageidavimą su aiškiu lūkesčiu dėl tolimesnio proceso;
• saugų atsisakyma arba neutralų nukreipimą, jei pasiūlymas, regionas ar kompetencija neatitinka.

Taip kvalifikavimas tampa nukreipimo sistema, o ne duomenų rinkimo etapu. Tai sumažina nereikalingus klausimus, trumpina dialogą ir neleidžia smalsiems lankytojams per greitai būti laikomiems pardavimų potencialiais klientais.

Kuriu klausimais yra tikrai būtina?

Pradėkite nuo sprendimo, kuris turi būti priimtas po dialogo. Tik tadaseka klausimai. Daugeliai svetainių užtenka trijų lygių.

1. Paaiškinti poreikį ir tikslą

Atviras įvadinis klausimas, pavyzdžiui, „Kuo galime jums padėti?“, dažnai suteikia daugiau konteksto nei ilgas pasirinkimų katalogas. Jei atsakymas išlieka neaiškus, pokalbių robotas gali pasiūlyti kelis suprantamus variantus, pavyzdžiui, produktų konsultaciją, pasiūlymą, palaikymą arba partnerystę. Variantai kiekvienoje kalboje turi turėti tokią pačią reikšmę ir apimti.

2. Patikrinti tinkamumą ir kompetenciją

Po toseka tik kriterijai, kurie keičia maršrutavimą: pageidaujama paslauga, regionas, įmonės dydis, projekto fazė arba realus laikotarpis. Biudžeto klausimai yra prasmingi tik tada, jei skirtingi biudžetai iš tikrųjų veda prie skirtingų pasiūlymų ar komandų. Laisvas tekstas turėtų išlikti ten, kur griežtos kategorijos iškraipytų užklausą.

3. Pasiūlyti kontaktinį būdą, atitinkantį rezultatą

Vardas, el. pašto adresas arba telefono numeris bus reikalingi tikCtuomet, kai atsakymas turi būti pateiktas ne einamo pokalbio metu. Neužklauskite automatiškai visų kontaktinių duomenų laukų. Raštingam atsakymui gali būti pakakano el. pašto adreso; išaiškiai pageidaujamam paskambinimui papildomai reikia telefono numero ir, jei reikia, laiką.

Ši eiliui laikykasi duomenų minimizavimo principo: Europos Komisija tai apibūdina taip, kad turi būti tvarkomi tik tie asmens duomenys, kurie yra būtini nustatytam tikslui. Tai yra gera produkto taisyklė, nepriklausomai nuo to, kokia teisinis pagrindas konkrečiame atvejui bus naudojamas po teisinio įvertinimo.

Kalba, etiketės ir klaidų pranešimai priklauso funkcijai

Vertimas tampa naudojamas tik tada, kai žmonės be spėliojimų supranta tikimą įvestį. W3C įvesties laukams reikalauja suprantamų etikečių arba nurodymų, o automatiškai aptiktų klaidų – tekstinio problemos aprašymo. Pokalbiui (chatbot) tai reiškia: turi būti lokalizuoti ne tik klausimai, bet ir privalomų laukų nurodymai, pavyzdžiai, patvirtinimai ir klaidų tekstai.

• Naudokite matomus, vienareikšmius pavadinimus, o ne tik užpildymo teksto pavyzdžius.
• Paaiškinkite tikimus formatus, pavyzdžiui, telefono numerių ar datų rašymo taisykles.
• Konkrečiai nurodykite, kokio įvesties duomenų trūksta arba kurie yra neatitinkami, vietoj to, kad tiesiog rodytumėte „Klaida“.
• Koreguojant išsaugokite jau teisingus atsakymus, kad niekam nereikėtų visko vesti iš naujo.
• Teisingai pažymėkite puslapio kalbą ir kitų kalbų teksto dalis tinkamaiskalba-atributų.

Tai kartu yra prieinamumo tema. ĮrašasPrieinamas DI pokalbinis botas: WCAG kontrolinis sąrašas svetainėms tam tikslui teikia išsamesnį kontrolinį sąrašą.

Duomenų apsauga: tikslo, informacijos ir sutikimo atskyrimas

Dažna klaida yra kontaktinį užklausą, grįžtamąjį ryšį ir naujienlaškį sumaišyti į vieną sutikimą. Tai sunaudina informuotą sprendimą. Vietoj to planuokite kiekvieną tikslą atskirai: užklausos apdorojimas, pageidaujamas ryšys ir pasirinktinė reklama yra skirtingi procesai.

Tinkamas teisinis pagrindas priklauso nuo konkretaus proceso ir turi būti patikrintas eksperto; sutikimas nėra automatiškai tinkamas arba vienintelis pagrindas kiekvienam kontaktiniam užklausai. Jei naudojamas sutikimas, pagal Europos Komisijos ir Europos duomenų apsaugos valdybos nurodymus jis turi būti savanoriškas, informuotas, specifinis ir aiškus. Reikalingas aktyvus veiksmas, o atšaukimas turi būti įmanomas.

Praktiškai tai pokalbiui reiškia:

• Prieš siųsdami paaišinkite, kas duomenis tvarko ir kokiu tikslu.
• Nuorodaukite atitinkamąsios duomenys apsaugos informacijos nuorodą dialogo kalba.
• Nenaudokite išankstai pažymėto sutikimo rinklaravimui.
• Ne priklausykitės užklausos apdorbojimą nuo nereikšmingų papildomų duomenų.
• Sąsaja su tikslu nustatykite saugojimo terminus ir prieigos teises.

Taigi, duomenų apsauga projektuojant ir duomenų apsaugai palankūs numatytingieji nustatymai prasideda nuo dialogo planavimo, o ne tik nuo duomenų apsaugos deklaracijos. Daugiau pagrindų rasite straipsnyjeKI-pokalbis ir BDAR. Šis vadovas nepakeičia individualios teisinės konsultacijos.

Maršrutavimo matrica užkerta atsitiktiniams sprendimams

Prieš kuriant dialogą, rekomenduojama sudaryti nedidėlį maršrutavimo matricą. Kiekviena eilutė aprašo nustatytą užklausą, jai reikalingą informaciją, tikslinę komandą ir leistumą kitą žingsnį. Galima struktūra atrodo taip:

• Bendras produkto klausimas: tiesiogiai atsakyti remiantis patikrintais šaltimiais; kontaktinių duomenų nereikia.
• Konkreti perkimo intencija: patikslinti paslaugą, regioną ir laikarpimį; po to pasiūlyti kontakto būdą.
• Esamas klientas su problema: nevertinti kaip naujo lead'o, o nukreipti į palaikymo procesą.
• sėkmės noras susisiekti su žmogumi: patikrinti prieinamumą ir skaidriai perduoti į gyvą pokalbį, el. paštą arba paskambučį.
• Nepalaikomas užklausa: atvirai nurodykite kompetencijos ribas ir siūlykite tik vieną patikrintą alternatyvą.

Perdavimo kelias neturėtų baigtis aklame takelyje. Jei šiuo metu gyvame pokalbyje niekas nepasiekiamas, asmuits turi gauti realistinę alternatyvą. Kaip galima organizuoti tokį perdavimą, paaiškinta Žmogaus pagalba DI pokalbyje.

Praktiškas dialogas septyniais žingsniais

1. Atpažinti arba leisti pasirinkti kalbą: aumti sprendimą ir suteikti galimybę pakeisti.
2. Suprasti poreikį: Pirmiausia atsakyti arba patikslinti, prieš pateikiant formą.
3. Patvirtinti potencialaus kliento signalą: Pereiti į kvalifikavimą tik esant tikram veiksmų ketinimui.
4. Užduoti maršrutavimo klausimus: Kiekvienoje žinutėje pateikti po vieną kiek įmanoma suprantamą klausimą su aiškiai nurodytu tikslu.
5. Pasiūlyti kontakto būdą:Rinkti tik những kontaktinius duomenis, kurie yra reikalingi pasirinktam kitam žingsniui.
6. Rodyti informaciją ir nebūtiną sutikimą:Tikslus pateikti atskirai ir aiškia kalba.
7. Apibendruoti ir perduoti:Patvirtinti įvestus duomenis, atsakingą komandą ir tikimąasi kitą žingsnį.

Tokia Sequence yra trumpesnė už daugelį formuliarių, nors suteikia daugiau konteksto. Svarbu, kad pokalbių botas bet kuriu metu gali grįžti prie įprastos konsultacijos ir nepralaiko asmens „lead“ sekloje.

Locale-QA: Kas turi būti patikrinta kiekvienu kalba

Automatinių vertimų galima naudoti pirmams brūdžiams, tačiau jie nepakeičia galutinės kontrolės. Testuokite kiekvieną siūlomą kalbą naudojantsiiaisiais specialiais scenarijais ir papildomai su konkrečiam regionui (locale) būdingais įvestiniais duomenimis.

• Ar variantai, kriterijai ir rezultatai turinio prasme sutampa?
• Ar klausimai skamba natūraliai, mandagiai ir tinkamai rinkai?
• Ar veikia specialieji simboliai, ilgesni žodžiai ir mobilūs eilutės perkeliavimai?
• Ar telefono numeriai, vardai ir datos formatai validuojami teisingai?
• Ar nuoroda į duomenų apsaugą, tekstas apie paskirtį, patvirtinimai ir klaidų pranešimai išversti visiškai?
• Ar produktų pavadinimai, URL adresai, skaičiai ir nukreipimo taisyklės lieka nepakitinti?
• Ar veikia klaviatūros valdymas, fokusas, ekrano skaitytuvo išvestis ir kalbos žyma?

Tam naudokite „Golden Set“, susidedantį iš tipiškų, neaiškių, neigiamų ir ribinių užklausų. Ypač atvejai „tik vienas klausimas“, „esamas klientas“, „nėra domėjimosi“ ir „kalbėtis su darbuotoju“ parodo, ar sistema patikimai skiria nuorodų surinkimą, palaikymą ir perdavimą žmogui.

Tinklamiausi rodikliai matuoja kokybę, o ne tik kiekį

Didelis surinktų kontaktų skaičius nėra kokybės įrodymas. Vietoj to stebėkite visą kelią: prasidėjusių prasmingų kvalifikavimų dalį, nutraukimus prie kiekvieno klausimo, visiškai perduotas užklausas, klaidingą nukreipimą, laiką iki pirmos žmogaus reakcijos ir vėlesnį priėmimą pardavimų ar palaikymo skyriaus.

Lygininkite reikšmes pagal lokalizaciją, tačiau skirtumus interpretuokite atsargiai. Žemesnė konversijų rodiklis gali būti susijęs su neaiškiais vertimais, netinkamais kontakto kanalais, techninėmis klaidomis arba tiesiog kita lankytojų struktūra. Todėl skaičius derinkite su atsitiktiniais pokalbių peržiūrėjimais ir dokumentuotais korekcijomis.

Užkardinimas su ChatReact

ChatReact jungia daugybą kalbų chatbotų atsakymus su nuorodų surinkimu ir perdavimu žmogui. Norint užtikrinti patikimą naudojimą, vis tiek turėtumėte pritaikyti laukus ir atpažinimo ribis savo konkrečiam procesui: kurie signalai reiškia tikrą pirkimo interesą? Kurių klausimų keičiasi nukreipimas? Kada tiesioginis atsakymas yra geresnis už kontakto formą?

Pradėkite nuo vieno aiškaus naudojimo scenarijaus ir dviejų ar trijų nukrypimo klausimų. Pirmiausia išbandykite šią seką originalia kalba, tada kiekvienoje tikslinės kalbos vietovėje ir tik po to su realiu srautu. Apžvalga Kaip DI pokalbių robotas padidins pirkėjų generavimą svetainėje padeda įtraukti į bendrą svetainės strategiją.

Sąrašas pradžiai

• Kiekvienam keliui apibrėžti konkretų tikslą ir atsakingą komandą.
• Rinkti tik klausimus, aktualius sprendimams, ir reikiamus duomenis.
• Techniškai atskirti palaikymą, pardavimo galimybes ir perdavimą.
• Duomenų apsaugos informaciją ir pasirinktinį sutikimą rinkodarai pateikti atskirai.
• Visas etiketes, pastabas, klaidas ir patvirtinimus redakciškai peržiūrėti kiekvienai vietoviui.
• Į QA įtraukti stalinį kompiuterį, mobilųjį įrenginį, klaviatūrą ir ekrano skaityklę.
• Reguliariai analizuoti klaidingą nukreipimą ir nutraukimus bei plėsti „Golden Set“ rinkinį.

Taip išvengi maksimaliaiilgo duomenų dialogo ir sukuriamas trumpas, suprantamas tiltas tarp tikro susidomėjimo ir tinkamo žmogaus arba automatizuoto atsakymo.

Šaltiniai

• Europos Komisija: Asmeninių duomenų tvarkymo principai pagal BDAR
• Europos Komisija: Duomenų apsauga projektuojant ir numatytais nustatymais
• Europos Komisija: Kada sutikimas yra galiojantis?
• Europos duomenų apsaugos valdyba: 05/2020 gairės dėl sutikimo
• W3C: Tinklo turinio prieinamumo gairės (WCAG) 2.2
• W3C WAI: klaidų identifikavimas
• W3C tarptautinė kalba: kalbos deklaravimas HTML