DI klientų patirties ir aptarnavimo srityje parduodama kaip paprasta pergalė: atsijoti lengvus prašymus, atlaisvinti agentų laiką, sutrumpinti atsakymo laiką. Praktikoje dauguma diegimų neatitinka lūkesčių, ir retai dėl to kaltas pats modelis. Dauguma nesėkmių yra ne technologinės, o strateginės ir organizacinės. Sėkmingos įmonės DI vertina kaip gyvą sistemą, integruotą į žmonių darbo eigas ir nuolat stebimą, o ne kaip pokalbių robotą, kurį galima įjungti ir palikti savieigai.
Toliau pateikiame klaidas, su kuriomis dažniausiai susiduriame konkrečiai klientų patirties ir aptarnavimo diegimuose, ir ką dėl kiekvienos jų daryti.
1 klaida: pernelyg didelis pasitikėjimas DI, nepaliekant vietos žmogaus priežiūrai
DI iš tikrųjų puikiai atlieka pasikartojančias, aiškiai apibrėžtas užklausas ir struktūrizuotas darbo eigas: užsakymo statuso patikrinimą, slaptažodžių atnaujinimą, grąžinimo taisykles. Tačiau jis susiduria su sunkumais, kai klientas yra emocionalus, problema neaiški arba situacija reikalauja empatijos, o ne scenarijaus. Kai DI vertinamas kaip visiškas žmogaus aptarnavimo pakaitalas - ne sluoksnis, apdorojantis numatomą apimtį ir paliekantis žmonėms tai, kam iš tikrųjų reikia žmogaus - aptarnavimo kokybė pradeda blogėti.
2 klaida: logikos kilpos
Kiekvienas, kam teko kelis kartus pakartoti tą pačią frazę pokalbių robotui, tai patyrė savo kailiu. Kai patikimumo slenksčiai nėra tinkamai sukalibruoti (dažniausiai tai apie 70–80 % tikslumo ribą), robotas arba kartoja tą patį klausimą, arba siūlo klientui skirtingus meniu punktus, vietoje to, kad perduotų jį žmogui. Sprendimas nėra didesnė kliento kantrybė, o tinkamai sureguliuotas perdavimo žmogui procesas, kuris perduoda pokalbį žmogui iš karto, kai patikimumo rodiklis nukrenta žemiau tinkamo slenksčio, nekartojant tų pačių pasiūlymų be galo.
3 klaida: pasenusios arba prastai prižiūrimos žinių bazės
DI aptarnavimo įrankis yra tik tiek geras, kiek gera už jo stovinti žinių bazė. Kai turinys pasensta (pasikeičia kainos, atnaujinamos taisyklės, produktų tiekimas nutraukiamas), DI paprastai nepasako „nežinau”. Jis generuoja DI haliucinacijas: įtikinamai skambančius, bet neteisingus atsakymus. Lygiai tai nutiko su „Air Canada” pokalbių robotu, kuris klientui pateikė neteisingą informaciją apie grąžinimą, kurios oro linija vėliau turėjo laikytis. Žinių bazei reikia savininko ir peržiūros grafiko, o ne vienkartinio įkėlimo.
4 klaida: prasta duomenų parengtis ir paslėptas šališkumas
DI aptarnavimo sistemos apmokomos naudojant istorinius aptarnavimo duomenis, o šie duomenys retai būna švarūs. Neišsamūs įrašai, per didelis kai kurių klientų segmentų atstovavimas ir nenuoseklus ženklinimas tyliai iškreipia rezultatus, kuriuos sistema vėliau generuoja. Viena logistikos įmonė to išmoko sunkiuoju būdu, kai jos pokalbių robotas klientui skirtame pokalbyje sugeneravo įžeidžiančią kalbą, kuri paskui atsidūrė socialiniuose tinkluose. Duomenų parengimas nėra techninė smulkmena, tai vieta, kur į sistemą įtraukiama arba iš jos pašalinama tikroji rizika.
5 klaida: realaus pasaulio testavimo praleidimas
Laboratorinis testavimas retai atspindi tai, kaip tikri klientai iš tikrųjų kalba. Žargonas, sarkazmas, rašybos klaidos ir nebaigti sakiniai yra norma tikruose pokalbiuose, o sistema, kuri gerai veikia su švariais testiniais scenarijais, gali sugriūti susidūrusi su tikrąja netvarkingo teksto realybe. Prieš paleidimą testuokite su tikrais klientų pokalbiais, o ne su parinktais pavyzdžiais, kurie sudaro įspūdį, kad sistema veikia geriau nei ji veikia iš tikrųjų.
6 klaida: neteisingo įrankio pasirinkimas
Ne kiekvienas DI aptarnavimo įrankis tinka tam pačiam darbui. Įrankis, sukurtas paprastiems DUK klausimams atsijoti, nepasiteisins sudėtingam, kelių žingsnių reikalaujančiam problemų sprendimui, o galinga platforma, skirta įmonės mastu paskirstyti užklausas, yra per sudėtinga mažai aptarnavimo komandai, sprendžiančiai nesudėtingus prašymus. Rinkitės įrankį, atitinkantį realų jūsų klientų klausimų sudėtingumą, o ne tą produktą, kurio demonstracija atrodo įspūdingiausiai.
Paprastas kontrolinis sąrašas prieš įgyvendinimą
Prieš diegdami bet kokį DI įrankį klientų patirties ar aptarnavimo srityje, gaukite aiškius atsakymus į šiuos klausimus:
Kokią konkrečią problemą sprendžiame ir kokio tipo užklausoms?
Kaip vertinsime sėkmę ir per kiek laiko?
Ar mūsų žinių bazė yra tiksli ir aktuali dabar, o ne prieš šešis mėnesius?
Koks yra perdavimo žmogui protokolas, kai DI patikimumas krenta?
Ar testavome su tikra klientų kalba, o ne su scenarijų pavyzdžiais?
Kas atsakingas už šią sistemą po paleidimo?
Galutinė mintis
DI klientų aptarnavimo technologija yra pakankamai išvystyta daugumai naudojimo atvejų. Diegimus sužlugdo planavimas: praleistas testavimas, pasenęs turinys, neaiški atsakomybė ir įrankis, neatitinkantis realaus darbo sudėtingumo. Sutvarkę organizacinę pusę, DI tampa tikru jūsų aptarnavimo komandos jėgos daugintuvu, o ne skundų šaltiniu.
Jei norite pagalbos tinkamai apibrėžti apimtį ir testuoti DI aptarnavimo diegimą prieš jį paleidžiant, susisiekite su mūsų komanda ir kartu tai peržiūrėsime.