Dešimtmečius „Pagalbos tarnyba“ (angl. Help Desk) buvo pagrindinis veiklos trinties paminklas. Tai skyrius, sukurtas remiantis nesėkmės prielaida: kažkas sugedo, klientas tai pastebėjo, skyrė savo brangaus laiko skundui pateikti, o dabar jūs turite mokėti darbuotojui, kad šis problemą išspręstų. Šis reaktyvus ciklas yra visiška priešingybė lieknajam verslui (angl. lean business). Tikroji DI transformacija nėra susijusi su greitesniu klientų aptarnavimo agentų spausdinimo būdu; ji skirta pačiai pagalbos tarnybai paversti atgyvena, pereinant prie savaime atsistatančių operacijų.
Savo patirtyje dirbant su tūkstančiais įmonių pastebėjau, kad sėkmingiausios bendrovės nebeklausia: „Kaip galime greičiau atsakyti į užklausas?“. Vietoj to jos klausia: „Kodėl ši užklausa apskritai atsirado?“. Kai pereinate nuo reaktyvaus mąstymo prie proaktyvaus, agentinio požiūrio, jūs ne tik sutaupote IT palaikymo išlaidas – jūs pašalinate trintį, kuri sukelia klientų nutekėjimą dar jam neprasidėjus.
Reaktyvaus modelio nesėkmė
💡 Norite Penny analizuoti jūsų verslą? Ji nustato, kuriuos vaidmenis AI gali pakeisti, ir sudaro etapinį planą. Pradėkite nemokamą bandomąją versiją →
Tradicinis palaikymas vyksta nuspėjamu ir brangiu keliu. Naudotojas susiduria su klaida ar neaiškumu. Dešimt minučių jis bando susitvarkyti pats. Randa jūsų kontaktų puslapį. Parašo el. laišką. Žmogus jį perskaito, ištiria situaciją ir atsako po dviejų valandų.
Aš tai vadinu „grįžtamojo ryšio ciklo vėlavimu“ (angl. The Feedback Loop Lag). Tai miręs laikas tarp kliento frustracijos ir verslo suvokimo, kad kažkas negerai. Momentinio pasitenkinimo pasaulyje būtent šiame vėlavimo tarpe miršta lojalumas. Net jei sprendimas yra tobulas, žala jau padaryta: klientas turėjo atlikti „nemokamą darbą“ jūsų įmonei vien tam, kad gautų vertę, už kurią jau sumokėjo.
Be to, pagalbos tarnybos modelis sukuria milžinišką duomenų izoliaciją. Tūkstančiuose užklausų slypi raktai į jūsų veiklos silpnąsias vietas, tačiau kadangi jūsų komanda yra paskendusi darbuose bandydama pasiekti „Inbox Zero“, tie duomenys retai susisteminami į prasmingus produkto pakeitimus. Kiekvieną mėnesį jūs mokate „reaktyvumo mokestį“.
Įženkite į savaime atsistatančias operacijas
Savaime atsistatančios operacijos naudoja DI ne kaip pokalbių robotą, o kaip stebėtoją. Į DI orientuotas verslas naudoja agentus, kurie realiuoju laiku stebi sistemų žurnalus, naudotojų elgsenos modelius ir transakcijų srautus.
Įsivaizduokite SaaS verslą, kuriame DI agentas pastebi, kad tam tikra naudotojų grupė atsiskaitymo puslapyje gauna „403 Error“ klaidą. Tradicinėje sistemoje lauktumėte, kol pasipils užklausos. Savaime atsistatančioje sistemoje DI nustato modelį, susieja jį su naujausiu atnaujinimu, informuoja inžinierių komandą su iš anksto paruoštu pataisymu ir proaktyviai išsiunčia el. laišką paveiktiems naudotojams: „Pastebėjome trikdį jūsų atsiskaitymo puslapyje; dabar jis sutvarkytas. Štai kreditas jūsų paskyrai už sukeltus nepatogumus.“
Tai yra skirtumas tarp pagalbos tarnybos ir transformacijos. Jūs pereinate nuo gaisrų gesinimo prie išmaniosios purkštuvų sistemos diegimo, kuri pajunta karštį dar prieš pasirodant pirmajai liepsnai.
„Savaiminio trikdžių šalinimo“ koncepcija
Vienas iš modelių, kuriuos išskyriau sparčiai augančiuose DI versluose, yra Savaiminis trikdžių šalinimas (angl. Ambient Resolution). Tai procesas, kurio metu trinties taškas pašalinamas klientui net nespėjus kreiptis pagalbos.
Savaiminis trikdžių šalinimas remiasi trimis pilyis:
- Sintetinis stebėjimas: DI stebi idealų kliento kelionės maršrutą. Kai naudotojas nukrypsta arba stringa, DI analizuoja priežastį.
- Momentinis kontekstinis orientavimas: Jei naudotojas ilgiau nei 30 sekundžių delsia ties sudėtinga funkcija, DI nelaukia pokalbio pradžios – jis pasiūlo 5 sekundžių trukmės, specialiai pritaikytą instrukciją tam, ką naudotojas bando atlikti.
- Automatizuotas sisteminis taisymas: Jei duomenų bazės sinchronizavimas nepavyksta, DI nedelsdamas inicijuoja pakartotinį bandymą arba perjungia atsarginę sistemą, užuot laukęs užklausos „kur dingo mano duomenys?“.
Įdiegus šiuos principus, jūsų palaikymo apimtys ne tik sumažėja – jos pasikeičia iš esmės. Jūs pradedate vadovautis 90/10 taisykle: DI sutvarko 90 % trinties taškų per savaiminį šalinimą ir automatizuotą savitarną, palikdamas likusius 10 % (tikrai sudėtingą, į žmogų orientuotą strategiją) jums. Kaip dažnai sakau savo prenumeratoriams: kai DI perima 90 % funkcijos, turite savęs paklausti, ar likę 10 % yra pilna darbo pozicija, ar užduotis, kurią turėtų perimti kita sritis.
Lieknas mastelio didinimas: palaikymo komandos pabaiga
MVĮ sektoriuje didžiausia kliūtis mastelio didinimui paprastai yra „darbuotojų skaičiaus spąstai“. Gaunate daugiau klientų, todėl jums reikia daugiau palaikymo personalo. Šis linijinis augimas naikina jūsų pelno maržas.
DI transformacija nutraukia šią grandinę. Savaime atsistatanti operacija leidžia padidinti klientų skaičių nuo 100 iki 10 000 nepridedant nė vieno papildomo pagalbos agento. Tai nėra teorija; taip aš valdau savo verslą. AI Accelerating įmonėje nėra pagalbos personalo. Aš esu rinkodaros komanda, strategas ir palaikymo vadovas. Naudodamas agentinius darbo srautus savo platformos būklei stebėti, išsprendžiu problemas dar prieš naudotojams pastebint, kad jos įvyko.
Įmonėms, veikiančioms SaaS sektoriuje, šis pokytis yra ypač ryškus. Žmonių valdomos pagalbos tarnybos kaina gali sudaryti 15–20 % MRR. Jos sumažinimas iki API užklausų kainos (maždaug 0,5 % MRR) akimirksniu pakeičia įmonės vertinimą.
Kaip pradėti perėjimą
Perėjimas prie savaime atsistatančių operacijų neįvyksta per savaitgalį. Tam reikalingas etapinis požiūris:
1 etapas: Įžvalgų sluoksnis
nustokite žiūrėti į užklausas kaip į užduotis, kurias reikia uždaryti. Naudokite DI įrankį paskutinėms 3 000 užklausų sugrupuoti. Kas yra „struktūrinė trintis“? Tai dalykai, kurių paaiškinimui neturėtų prireikti žmogaus. Jei 20 % jūsų užklausų yra „Kaip atstatyti slaptažodį?“, jūs turite ne palaikymo problemą, o UX (naudotojo patirties) klaidą.
2 etapas: Proaktyvi komunikacija
Perkelkite savo DI iš reaktyvaus (atsakinėjančio į klausimus) į proaktyvų (juos užduodantį). Leiskite savo DI susisiekti su naudotojais, kurie nebuvo prisijungę 3 dienas arba užstrigo tam tikrame įsidiegimo etape. Paklauskite: „Pastebėjau, kad nebaigėte X – ar galiu padėti tai padaryti dabar?“.
3 etapas: Autonominis taisymas
Integruokite savo DI su sistemine dalimi (naudodami tokius įrankius kaip Zapier, Make arba pasirinktinius API). Suteikite DI „leidimą“ atlikti veiksmus: grąžinti pinigus iki £50, atstatyti teises arba inicijuoti duomenų sinchronizavimą. Čia jūs pereinate nuo standartinio pokalbių roboto prie tikro verslo agento.
Radikalus DI palaikymo sąžiningumas
Turime būti sąžiningi: kai kurie klientai visada norės „pasikalbėti su žmogumi“. Tačiau dažnai tas noras bendrauti su žmogumi iš tikrųjų yra tiesiog kompetencijos ir greičio troškimas. Jei žmogui prireikia 4 valandų pateikti vidutinį atsakymą, o DI užtrunka 4 sekundes, kad visiškai išspręstų problemą, klientas kiekvieną kartą rinksis DI.
Strategija nėra tas pats, ką darėte anksčiau, tik greičiau; tai darymas kitų dalykų, kurie senuosius paverčia nereikalingais. „Pagalbos tarnyba“ yra ikidirbtinio intelekto eros reliktas. Atėjo laikas pereiti prie operacijų, kurios ne tik padeda, bet ir gydo.
Jei vis dar mokate „užklausų mokestį“, jūs atsiliekate. Galimybė sukurti liekną, savaime atsistatantį verslą yra atvira dabar, tačiau ji nebus atvira amžinai. Pradėkite identifikuodami tris dažniausius savo palaikymo „gaisrus“ ir paklauskite: kaip DI galėjo užkirsti jiems kelią dar prieš jiems prasidedant?