Klientų aptarnavimo automatizavimas, atlaikantis reguliuojamą veiklą
Klientų aptarnavimo automatizavimas yra dirbtinio intelekto sistemų panaudojimas užklausoms triažuoti, pagrįstiems atsakymams rengti, eskalacijoms nukreipti su pateiktu argumentavimu ir grąžinimų ar klientų išlaikymo pajamoms susigrąžinti el. pašto, pokalbių ir užklausų sistemose. Impetora kuria tokias sistemas su citavimu kiekviename atsakyme, automatiškai išsprendžiant 78% rutininių užklausų esant 12 sekundžių vidutinei pirmojo atsakymo trukmei.
01.Kas yra klientų aptarnavimo automatizavimas?
Klientų aptarnavimo automatizavimas apibūdina dirbtinio intelekto sistemas, kurios atlieka rašytinį aptarnavimo darbą įvairiais kanalais: el. paštu, pokalbiais, vidiniais produkto langais ir užklausų valdymo sistemomis. Sritis apima užklausų triažavimą ir nukreipimą, atsakymų juodraščių rengimą pagal jūsų žinių bazę, grąžinimų ir kreditų atstatymo procesus, klientų išlaikymo rizikos atpažinimą iš pokalbių signalų bei eskalacijų nukreipimą su struktūruotu apibendrinimu žmogui, kuris perima bylą. Sritis neapima balso ar telefonijos, kurios yra atskira veiklos erdvė.
Gartner prognozuoja, kad pokalbių DI klientų aptarnavime iki 2026 metų pasaulyje sumažins agentų darbo sąnaudas 80 mlrd. JAV dolerių, o rutininių užklausų automatinis sprendimas pasieks 70-80%. Sudėtinga yra ne pasiekti šį skaičių. Sudėtinga yra įdiegti sistemas, kurių atsakymai cituoja jūsų pačių taisykles, o eskalacijos atkeliauja agentui ant stalo su pilna argumentavimo grandine.
03.Kaip Impetora TRACE metodologija sprendžia šią problemą?
Trust (pasitikėjimas)
Readiness (parengtis)
Architecture (architektūra)
Citations (citatos)
Patikimumas. Visa paklausa, paieška ir pokalbių žurnalai veikia ES regionuose. Laikomės ES DI akto 50 straipsnio skaidrumo prievolės: klientai mato, kad bendrauja su DI, ir šis pranešimas yra įtvirtintas kanalo paviršiuje, ne paslėptas tinklalapio apačioje. Pasirengimas. Surenkame 30 dienų istorinių užklausų pavyzdžių, fiksuojame esamą apdorojimo trukmę, pirmojo kontakto sprendimo dažnį ir grąžinimų atstatymo lygį prieš pasirinkdami modelį.
Architektūra. Kiekvienas atsakymas generuojamas pagal versijuojamą jūsų taisyklių žinių bazę, o paieškos citatos matomos agentui, kuris atsakymą peržiūri ir išsiunčia. Pirmiausia šešėlinis režimas, paskui pagalbinis, o autonominis tik tose kategorijose, kurias patvirtina jūsų rodikliai. Citatos ir įrodymai. Kiekvienas juodraštis, kiekvienas nukreipimo sprendimas ir kiekviena grąžinimo rekomendacija susieta su tiksliu taisyklės punktu, įrašyta į užklausomą audito žurnalą. Kokybės ar atitikties komanda gali atsekti bet kokį sprendimą per kelias sekundes.
04.Kaip atrodo sistemos architektūra?
Sistemą sudaro keturios nuosekliai dirbančios dalys. Priėmimas: jungčių sluoksnis prie jūsų užklausų platformos (Zendesk, Intercom, Freshdesk, ServiceNow, individualus el. paštas), kuris žinutes, gijas ir kliento kontekstą paverčia vienu pokalbio objektu. Apdorojimas: ketinimo klasifikavimas, nuotaikos vertinimas, tinkamumo patikra pagal jūsų grąžinimų ir kreditų politiką bei pagrįsto juodraščio generavimas iš jūsų žinių bazės.
Peržiūra: agento pusėje rodoma sąsaja, kurioje DI juodraštis stovi šalia cituojamų taisyklių punktų. Agentas vienu paspaudimu redaguoja, tvirtina arba atmeta, o pataisymo signalas automatiškai patenka į vertinimo rinkinį. Pristatymas: patvirtintas atsakymas grįžta per užklausų platformą, struktūruotas įvykis patenka į audito žurnalą, o bet koks grąžinimas ar kreditas paleidžia atnaujinimą kitose sistemose su pilnu kelio aprašu. Kategorijoms, leidžiamoms autonominiam sprendimui, peržiūros žingsnis yra pati DI sistema, tikrinanti savo juodraštį pagal griežtesnę pasitikėjimo ribą ir aiškų politikos patikrintuvą prieš išsiunčiant.
05.Kokius pamatuojamus rezultatus galima tikėtis?
Realus diegimas siekia keturių rodiklių, kuriuos esame patvirtinę bandomųjų projektų metu. 78% rutininių užklausų išsprendžiama be agento, o tai atitinka Gartner prognozuojamą 70-80% automatinio sprendimo lygį. Pirmojo atsakymo trukmė siekia 12 sekundžių, palyginti su 4 minučių rinkos vidurkiu. McKinsey klientų aptarnavimo tyrimas nurodo 14% sumažėjusią vidutinę apdorojimo trukmę ir 13,8% padidėjusį per valandą išspręstų klausimų skaičių išmatuotuose diegimuose.
Pajamų požiūriu, grąžinimų atstatymo procesai jau pirmuoju atsakymu pasiūlo tinkamas alternatyvas. SaaS įmonė su 2 mln. EUR mėnesiniu grąžinimų rizikai priklausančiu atsiskaitymu pagrįstai gali tikėtis susigrąžinti 200 000 EUR per mėnesį dėl nuoseklesnio taisyklių taikymo pirmuoju kontaktu, o tai atitinka aukščiau pateiktus tyrimų ir mūsų bandomųjų projektų rezultatus. Ketvirtas rodiklis yra audito: 100% klientams skirtų juodraščių turi atsekamą citatą iki taisyklių punkto.
06.Kiek laiko trunka diegimas?
Pirmas bandomasis projektas pasiekia gamybinę kokybę vienoje užklausų kategorijoje per 4 savaites. Pirmas etapas (1-2 sav.) yra pasirengimo sprintas: užklausų atranka, esamų rodiklių fiksavimas, žinių bazės auditas ir apimties patvirtinimas. Antras etapas (3-4 sav.) yra konstravimas ir šešėlinis paleidimas, kai DI rengia juodraščius, bet jų neišsiunčia. Trečias etapas (5-11 sav.) plečia diegimą iki pagalbinio režimo ir atrankinio autonominio sprendimo tose kategorijose, kurias tai pateisina.
07.Kiek tai kainuoja?
Bandomieji projektai prasideda nuo 25 000 EUR vienai užklausų kategorijai ir aiškiai apibrėžtai pradžiai. Pilni gamybiniai diegimai trijose-penkiose kategorijose su grąžinimų atstatymo procesais ir užklausų platformos integracijomis paprastai siekia 60 000-150 000 EUR. Pateikite projektą, kad gautumėte individualų pasiūlymą, ir parengsime sąmatą pagal jūsų užklausų rinkinį, žinių bazę ir integracijų lauką dar prieš pradedant programuoti.
02.Kaip ši sritis tradiciškai veikia?
Be DI, aptarnavimo veikla remiasi pakopinėmis eilėmis, makrokomandų bibliotekomis ir komandos žiniomis. Pirmojo lygio agentai sprendžia rutininius klausimus naudodami parengtas formuluotes. Antras lygis perima sudėtingesnes bylas, didesnius grąžinimus ir tai, ko makrokomandos nepadengia. Trečias lygis valdo eskalacijas ir bet kokias bylas, susijusias su teisės, atitikties ar pajamų pripažinimo rizika. Salesforce 2024 metų aptarnavimo ataskaita nustato, kad pirmojo atsakymo laikas geriausioms komandoms siekia apie 4 minutes, o vidutinėms - 30-60 minučių.
Grąžinimų atstatymas yra didžiausias paslėptas svertas. Tipiškoje SaaS ar elektroninės prekybos veikloje 12-18% grąžinimų yra tinkami daliniam kreditui ar alternatyviam sprendimui, kurio agentas neparodo, nes makrokomandų biblioteka jo neprimena. Forrester pokalbių DI ekonominio poveikio tyrimas nurodo, kad sudėtinė įmonė per trejus metus susigrąžino 2,4 mln. JAV dolerių dėl greitesnio ir nuoseklesnio grąžinimų valdymo. Tradicinė sistema praranda pajamas ne todėl, kad agentai klysta, o todėl, kad reikiama taisyklė nėra po ranka tinkamu metu.
Dažniausi klausimai
Ar tai pakeis mūsų aptarnavimo agentus?
Ne. Gamybinės kokybės diegimai perkelia agentų darbą nuo žemo konteksto rutininio sprendimo prie aukšto konteksto išimčių, grąžinimų sprendimų reikalaujančių bylų ir tų atvejų, kuriems reikia žmogiško balso. Mūsų bandomųjų projektų ir McKinsey klientų aptarnavimo tyrimo duomenimis, tipiškas rezultatas yra išlaikomas ar šiek tiek mažesnis darbuotojų skaičius prie žymiai didesnio kiekvieno agento pralaidumo, kartu pamatuojamai padidėjus klientų pasitenkinimui sudėtingesniais atvejais, nes jie agentui dabar pasiekia su pilnu kontekstu. Pagal numatytąjį nustatymą kuriame pagalbinį režimą, o autonominį sprendimą įjungiame tik tose kategorijose, kuriose jūsų skaičiai rodo, kad tai saugu.
Kaip tvarkomas daugiakalbis aptarnavimas?
Vietinis daugiakalbis palaikymas pagrindinėms Europos kalboms, su atskirais vertinimo rinkiniais kiekvienai kalbai ir kiekvienai užklausų kategorijai. Lietuvių, vokiečių, prancūzų, ispanų ir anglų kalbos yra bazinės. Mes nedirbame vienu modeliu visoms kalboms ir tai vadiname pasiekimu. Kiekviena kalba turi savo paieškos indeksą, vertinimo rinkinį ir pasitikėjimo ribas, nes politikos niuansai bei kultūrinis registras skiriasi. Audito žurnale yra kalbos žyma kiekvienam įrašui, todėl Vilniuje ir Berlyne dirbančios kokybės kontrolės komandos mato vienodą duomenų struktūrą su skirtingais filtrais.
Ar veiks su mūsų esama užklausų platforma?
Taip pagrindinėms platformoms (Zendesk, Intercom, Freshdesk, ServiceNow, Salesforce Service Cloud, HubSpot Service Hub), o vidinei ar paveldėtai sistemai parengiame eilėmis paremtą tiltą. Integracija įrašo juodraščius, nukreipimus ir audito įvykius atgal į užklausų platformą, todėl jūsų ataskaitos ir kokybės kontrolė lieka ten, kur jau yra. Mes nereikalaujame pereiti nuo esamos platformos. Reikalaujame API prieigos užklausoms skaityti ir rašyti, ir pasirengimo sprinte aiškiai pasakysime, jei platformos API yra pernelyg ribota gamybiniam diegimui.
Kaip tvarkomas klientų duomenų privatumas?
Visa paklausa, paieška ir saugojimas vyksta ES regionuose. Pasirašome duomenų tvarkymo sutartį su standartinėmis ES sutarčių sąlygomis ir jūsų reguliatoriaus reikalaujamus duomenų vietos įsipareigojimus, jei dirbate pagal DORA, BaFin, ACPR ar sektoriaus reglamentus. Mes nemokome jokio modelio iš jūsų klientų duomenų. Užklausose pasirodantys asmens duomenys yra užkertami iš žurnalų, esančių už teisinio pagrindo ribų, o užkertimo politika yra dokumentuota ir audituojama. Klientai mato, kad bendrauja su DI, kaip to reikalauja ES DI akto 50 straipsnis.
Kas atsitinka, kai DI suklysta?
Trijų sluoksnių apsauga. Pirma, pasitikėjimo riba: jei modelio pasitikėjimas nesiekia jūsų nustatytos ribos kategorijai, juodraštis savarankiškai neišsiunčiamas, neatsižvelgiant į režimą. Antra, autonominėms kategorijoms taikomas politikos patikrintuvas, kuris dar kartą tikrina juodraštį pagal cituojamą punktą prieš išsiunčiant. Trečia, grįžtamojo ryšio kilpa: kiekvienas agento pataisymas pagalbiniame režime patenka į vertinimo rinkinį, o vertinimo rinkinys blokuoja diegimus, kurių klaidų lygis nepagerėjo prie slenkančios pradinės reikšmės. Kai vis dėlto išsiunčiamas neteisingas atsakymas, audito žurnalas rodo modelio versiją, užklausą, paieškos kontekstą ir pasitikėjimo balą, todėl po įvykio analizė vyksta greitai.
Ar veikia balso skambučiams ar telefonijai?
Ne, ši sistema apima tik rašytinius kanalus: el. paštą, pokalbius, vidinius produkto langus ir užklausų platformas. Balsas ir telefonija sudaro atskirą veiklos erdvę su skirtingais vėlinimo, transkripcijos ir reguliavimo iššūkiais. Jei jūsų aptarnavimo veiklai reikia abiejų, rekomenduojame planuoti juos kaip du lygiagrečius projektus su bendra žinių bazės infrastruktūra, kad citavimo ir taisyklių sluoksnis būtų nuoseklus visais kanalais, o vykdymo sistemos liktų nepriklausomos.