Amazon Quick: klientų išlaikymo darbas trumpėja nuo dienų iki minučių
·
Amazon Quick yra viena iš tų DI temų, kur lengva pasiklysti techniniuose žodžiuose. Aš žiūriu paprasčiau: ką žmogus rytoj darbe darys kitaip?
AWS liepos 29 d. pateikė labai žemišką Amazon Quick pavyzdį: klientų išlaikymo procesas, kuris vietoj penkių dienų gali užtrukti minutes. Ir čia nereikia didelio filosofavimo. Jei klientas pyksta šiandien, laiškas po savaitės jau būna kaip gėlės po skyrybų.
Atvirai? Man tokiose naujienose visada įdomiausia ne gražiausias pavadinimas. Įdomiausia, kur prasideda realus darbas, reali rizika ir realus sutaupytas laikas.
KAS NUTIKO
Amazon Quick pavyzdyje sistema analizuoja skambučių išrašus ir CSAT duomenis, aptinka rizikos klientus, prioritetizuoja juos per MCP Action ir sugeneruoja personalizuotus išlaikymo laiškus. AWS mini scenarijų, kuriame SaaS įmonė prarado 12% rizikos paskyrų dėl lėtos reakcijos.
Man čia patinka ne technologijos blizgesys, o paprastas ritmas: signalas, prioritetas, veiksmas. Daug komandų pralaimi ne todėl, kad nežino, ką daryti. Jos per vėlai pamato, kur dega.
KODĖL TAI SVARBU
Klientų išlaikymas yra gera DI tema, nes signalų daug: pokalbiai, ticketai, apklausos, produkto naudojimas, vėluojantys mokėjimai. Žmogui tai išmėtyta per penkias vietas. Agentui galima duoti užduotį surinkti ir parodyti pirmą eilę.
DI jau nebe vien langelis, į kurį įmetame tekstą. Jis jungiasi prie įrankių, skaito dokumentus, kviečia servisus, kartais veikia keliais žingsniais ir pradeda liesti tikrus procesus. Čia romantika baigiasi. Prasideda tvarka.
Ir taip, tvarka skamba nuobodžiai. Bet kai kalba pasisuka apie klientų duomenis, pinigus, sveikatą ar prieigas, nuobodumas staiga tampa privalumu.
KĄ TAI REIŠKIA VERSLUI
Verslui čia aiški pamoka: DI neturi tik rašyti laiškų. Jis turi padėti rasti, kam rašyti pirmiausia ir kodėl. Čia atsiranda reali piniginė vertė.
- rinkti signalus iš kelių kanalų
- turėti churn rizikos taisykles
- prioritetizuoti pagal pajamas ir skausmą
- nepalikti jautraus laiško be žmogaus peržiūros
Pirmas testas gali būti labai paprastas: kas savaitę sugeneruoti 20 klientų sąrašą, kuriems sumažėjo naudojimas, padaugėjo skundų arba nukrito pasitenkinimo balas.
Jei skamba per paprastai, vadinasi, judame teisinga kryptimi. Geras DI diegimas dažnai atrodo ne kaip fejerverkai, o kaip tvarkingas darbo stalčius.
KUR GALI SKAUDĖTI
Rizika – išsiųsti gražų, bet netinkamą laišką. Jei klientas pyksta dėl rimtos klaidos, automatinė šypsena tik dar labiau erzina.
Blogiausia DI klaida dažnai neatrodo kaip klaida. Ji ateina gražiai parašytu sakiniu, mandagiu tonu ir labai užtikrintu veidu. Dėl to reikia ribų, logų ir žmogaus sprendimo ten, kur kaina didesnė.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Šią savaitę pasiimk 10 prarastų klientų ir pažiūrėk, kokie signalai buvo likus dviem savaitėms iki išėjimo. Ten dažnai slepiasi pirmas DI projektas.
Mano taisyklė paprasta: jei negali pasakyti, kaip matuosi rezultatą, dar ne automatizuoji. Dar tik žaidi.
Šaltinis: Amazon Web Services.
DUK
Kas yra Amazon Quick?
Tai AWS verslo produktyvumo ir duomenų darbo įrankių kryptis, kurioje atsiranda agentiniai procesai.
Ką automatizuoja pavyzdys?
Rizikos klientų aptikimą, prioritetų skaičiavimą ir išlaikymo laiškų juodraščius.
Ar galima viską siųsti automatiškai?
Geriau ne. Jautrius klientų išlaikymo veiksmus turi peržiūrėti žmogus.
Jei nori DI naudoti praktiškai, pradėk nuo vieno proceso. Vienas pasikartojantis darbas, vienas atsakingas žmogus, vienas matavimas. Daugiau praktinių DI taikymo pavyzdžių rasi MasterSprint.
