Daugiau metrikų nebūtinai padeda geriau suprasti situaciją. Daugelyje ataskaitų sričių pateikiami keli to paties esminio elgesio rodikliai. Metrikos tampa naudingesnės diagnostikai, kai sujungiamos į viena kitą ribojančias poras: sąnaudos ir kokybė, savitarnos sėkmė ir klientų nuotaikos arba tikslumas ir delsa.
Tinkamos poros keičiasi, kai DI produktas pereina nuo bandomojo etapo prie realaus naudojimo. Kiekviename etape vertinimas turėtų būti grindžiamas sprendimais, kuriuos turi priimti komanda.
Veiklos stebėsena ir strateginis vertinimas skirti skirtingiems tikslams. Komandos gali stebėti šimtus sistemos signalų, tačiau produktų sprendimams priimti naudoti vos kelias poras.
Pagrindinės metrikos gali įtikinamai atspindėti padėtį, tačiau nepadėti priimti svarbaus produkto sprendimo.
„Klarna“ DI asistentas viešai sietas su didesniu pralaidumu, mažesnėmis sąnaudomis ir klientų pasitenkinimo įverčiais, panašiais į žmonių agentų rezultatus. Kitais metais bendrovė nusprendė didinti žmonių teikiamos pagalbos prieinamumą, o jos vadovas pripažino, kad sąnaudų mažinimui buvo skirta per daug dėmesio.
Tai nebuvo DI asistento ar jo pagrindu veikiančios technologijos atsisakymas. Tai buvo automatizavimo ir žmonių teikiamo aptarnavimo pusiausvyros koregavimas įmonei mokantis iš šio produkto naudojimo patirties. Automatizuotoms sistemoms perėmus vis daugiau masinių, paprastesnių užklausų, „Klarna“ reikėjo klientų aptarnavimo specialistų, pasirengusių spręsti sudėtingas ir jautrias problemas.
Iš anksto apibrėžusios, ką produktas turi pasiekti, dauguma DI produktus kuriančių organizacijų galiausiai susiduria su tuo pačiu klausimu: ar jis iš tiesų veikia?
Kai atsakymas neaiškus, dažnai norisi pridėti daugiau metrikų. Trys tampa 10, o 10 – 30. Ataskaitų sritis tampa išsamesnė, tačiau komanda nebūtinai geriau supranta padėtį.
Problema ne visada yra atskirų rodiklių kokybė – kartais ją lemia jų tarpusavio ryšys. Klientų pasitenkinimas, rekomendavimo indeksas (NPS), atsiliepimai ir teigiamų įvertinimų dalis teikia naudingų signalų, tačiau gali atspindėti panašius bendrų nuotaikų pokyčius. Kai jie kinta kartu, patvirtina, kad kažkas įvyko, tačiau nebūtinai paaiškina kodėl.
Todėl DI komandos turėtų žvelgti ne tik į viena kitą patvirtinančias metrikas, bet ir nustatyti rodiklius, atskleidžiančius konkuruojančius rezultatus. Šios viena kitą ribojančios poros atskleidžia kompromisų poveikį produkto rezultatams, padeda jį stebėti ir priimti geresnius sprendimus.
Diegiant vieną dar nepristatytą produktą, bendra komanda kūrė tikralaikį DI balso agentą įeinantiems klientų aptarnavimo skambučiams. Vienas sunkiausių klausimų buvo susijęs ne su modelio pasirinkimu ar koordinavimu. Reikėjo suprasti, kaip organizacija nustatys, ar produktas veikia, kai jį plačiai pradės naudoti klientai.
Pradinėje sistemoje naudoti trys rodikliai:
Savitarnos sėkmės rodiklis: kaip dažnai DI išsprendžia skambučio klausimą neperduodamas jo žmogui.
Perdavimo rodiklis: kaip dažnai skambutis perduodamas agentui žmogui.
Išsprendimo rodiklis: kaip dažnai kliento problema galiausiai išsprendžiama.
Kiekvienas rodiklis buvo pagrįstas. Tačiau kartu jie negalėjo atsakyti į akivaizdų klausimą: jei perdavimų daugėja, ką tai mums sako?
Komanda suskirstė perdavimus į aštuonis potipius. Tada ji pridėjo pokalbio nutraukimo, kliento kelionės ir laiko rodiklius, kalbos supratimo įverčius bei išsprendimą pagal užklausos tipą. Galiausiai sistemą sudarė 31 metrika šešiose kategorijose.
Ji galėjo išsamiai apibūdinti perdavimus, tačiau vis dar negalėjo patikimai nustatyti jų priežasties. Dauguma metrikų buvo to paties elgesio variacijos, todėl kito kartu, užuot tikrinusios konkuruojančius paaiškinimus.
Ataskaitų sritis tapo skirta stebėti, o ne diagnozuoti.
Komandai reikėjo ne dar vieno išskaidymo lygmens. Jai reikėjo viena kitą ribojančių metrikų.
Jas vadiname viena kitą ribojančiomis poromis: tai du rodikliai, kai vieną gerinant atskirai galima pakenkti kito atspindimam rezultatui. Pavadinimas nusako nesėkmę, kurią sukelia vienpusis optimizavimas, o ne siekiamą būseną.
Kai abi pusės išlieka tinkamos, produktas gali veikti tvariai. Kai jos ima skirtis, skirtumo kryptis padeda komandai nuspręsti, ką tirti.
Ką turėjome | Viena kitą ribojanti pora | Ką pora gali atskleisti |
|---|---|---|
Į aštuonis potipius suskirstytas perdavimo rodiklis | Perdavimo rodiklis ↔ laikas iki perdavimo | Skubus perdavimas gali rodyti pasitikėjimo ar pristatymo problemą, o vėlesnis – kad sistema negali atlikti užduoties. |
Atskirai pateikiami savitarnos sėkmės ir išsprendimo rodikliai | Savitarnos sėkmės rodiklis ↔ klientų nuotaikos | Ar savitarna reiškia, kad klausimas išspręstas patenkinamai, ar kad klientas liovėsi bandęs. |
Išsprendimo rodiklis pagal ketinimo tipą | Išsprendimo rodiklis ↔ pokalbio gylis | Ar klausimas sėkmingai išsprendžiamas efektyviai, ar tik po varginančio bendravimo. |
Kad geriau suprastume, kaip tai atskleidžiama ir kaip šiomis įžvalgomis pasinaudoti, panagrinėkime perdavimo rodiklį ir laiką iki perdavimo. Komanda nežinos, kaip klientai elgsis, kol neprasidės tikri skambučiai, tačiau gali apibrėžti tikrintinas hipotezes.
Jei perduodama vis daugiau skambučių, o klientai per pirmąsias 30 sekundžių nutraukia bendravimą su DI, komanda turėtų ištirti pasitikėjimą, informavimą, toną ir pokalbio pradžią. Jei klientai prašo perdavimo kelias minutes mėginę atlikti užduotį, labiau tikėtina, kad problema susijusi su galimybėmis arba nepakankama procesų aprėptimi.
Pagrindinis perdavimų skaičius toks pats. Tačiau produkto sprendimas skiriasi.
Naudinga pora pati savaime neįrodo priežasties. Ji susiaurina tyrimą ir padeda aiškiau priimti kitą sprendimą.
Anksčiau pateiktas „Klarna“ pavyzdys rodo, kaip šis principas taikomas sąnaudoms sąveikaujant su paslaugų kokybe. Jis parodo, kaip DI grindžiamas veiklos modelis gali keistis bendrovei stebint kompromisų poveikį ir mokantis iš įdiegto sprendimo.
2024 m. vasarį bendrovė pranešė, kad jos DI asistentas per pirmąjį mėnesį aptarnavo 2,3 mln. pokalbių, atliko 700 visą darbo dieną dirbančių agentų darbui prilygstančią užduočių apimtį ir pasiekė į žmonių agentų panašius klientų pasitenkinimo įverčius. „Klarna“ apskaičiavo, kad 2024 m. asistentas padidins pelną 40 mln. JAV dolerių. Tai buvo pačios „Klarna“ paskelbti rezultatai, o ne nepriklausomas vertinimas.
2025 m. gegužę „Klarna“ vadovas teigė, kad bendrovė per daug dėmesio skyrė klientų aptarnavimo sąnaudų mažinimui, ir pristatė planus didinti žmonių teikiamos pagalbos prieinamumą. Tai buvo automatizuotų ir žmonių teikiamų paslaugų pusiausvyros korekcija, o ne DI asistento ar jo pagrindinės technologijos atmetimas.
Vieši duomenys rodo, kodėl efektyvumo rodiklius reikia vertinti kartu su skirtingų klientų ir sąveikų poreikiais. DI sistemos vidutiniai rezultatai gali būti geri, tačiau kai kuriais sudėtingais, jautriais ar neįprastais atvejais vis tiek naudinga lengvai prieinama žmogaus pagalba.
Stebėdama abi šio ryšio puses, bendrovė gali nuspręsti, kur automatizavimas kuria vertę, kur tebėra svarbi žmogaus pagalba ir kaip, atsiradus naujų duomenų, keisti pusiausvyrą.
Kitos viena kitą ribojančios DI produktų poros gali būti:
Viena kitą ribojanti pora | Rizika, kurią ji padeda atskleisti |
|---|---|
Atsakymo tikslumas ↔ atsakymo delsa | Sistema yra techniškai tiksli, tačiau per lėta darbo procesui. |
Užduočių atlikimas ↔ naudotojų taisymų rodiklis | DI darbo procesas atlieka užduotis, kurias naudotojai nuolat perdaro. |
Vienos sąveikos sąnaudos ↔ įvertinta rezultato kokybė | Sutaupoma bloginant klientų arba darbuotojų patirtį. |
Naudojimas ↔ laikas iki vertės sukūrimo | Registracijų daugėja, tačiau naudotojams sukuriama vertė nedidėja. |
Tikslas nėra neribotai didinti abu rodiklius. Tikslas – parodyti kompromisą anksčiau, nei vienpusis optimizavimas sukels veiklos problemų.
Su panašiu iššūkiu susidurta diegiant žaidėjų pagalbos sprendimą mobiliųjų žaidimų bendrovėje. Sistema sprendė dažnas problemas, pavyzdžiui, prarastos pažangos, mokėjimų ginčų ir prieigos prie paskyros.
Efektyvumo rodikliai buvo svarbūs, nes sistema veikė dideliu mastu. Tačiau pagalba žaidėjams nėra vien veiklos užklausų eilė. Žaidėjai dažnai kreipiasi nusivylę, nes jų patirtyje jau įvyko kažkas negero.
Ši pradinė padėtis keičia klientų pasitenkinimo duomenų interpretavimą. Žaidėjas, kurio problema tinkamai išspręsta, vis tiek gali nurodyti menką pasitenkinimą, nes iš pradžių prarado pažangą. Vertinant šį įvertį be konteksto, pagalbos sąveika gali būti nepagrįstai kaltinama dėl anksčiau kliento kelionėje kilusio nusivylimo.
Todėl komanda turėjo atskirti pradines kliento nuotaikas nuo pagalbos patirties poveikio. Naudingesnis klausimas buvo ne „Ar žaidėjas buvo patenkintas?“ O „Ar ši sąveika pagerino padėtį, palyginti su pradine žaidėjo situacija?“
Šis palyginimas gali padėti atskirti nepasitenkinimą produktu nuo pagalbos kokybės, jei komanda gali patikimai įvertinti abu aspektus.
DI produktai keičiasi, tačiau jų metrikos dažnai lieka tokios pačios.
Bandomajame etape pagrindinis klausimas gali būti, ar sistema pakankamai patikima tolesnėms investicijoms pagrįsti:
Ar ji patikimai atlieka pagrindinę užduotį?
Ar naudotojai pakankamai ja pasitiki, kad naudotųsi toliau?
Kaip ji veikia rečiau pasitaikančiais atvejais?
Ar galima saugiai nustatyti gedimus ir po jų atkurti veikimą?
Šiems klausimams tinka tokios poros:
pagrindinės užduoties sėkmė ↔ rezultatai išskirtiniais atvejais;
automatizavimo lygis ↔ žmogaus įsikišimo rodiklis; ir
atlikimo greitis ↔ naudotojų pasitikėjimas.
Kai produktas tampa svarbus veiklai, klausimai pasikeičia:
Ar galima jį plėsti neprarandant kokybės?
Ar naudojant jo ekonominis efektyvumas gerėja?
Ar augant naudojimui rezultatai išlieka stabilūs?
Ar žmonės įsikiša tinkamais atvejais?
Atitinkamos poros gali pasikeisti į šias:
vienos sąveikos sąnaudos ↔ įvertinta rezultato kokybė;
naudojimo paplitimas ↔ naudojimo gylis; ir
automatizavimo lygis ↔ veiklos rizikos mastas.
Ankstyvojo etapo metrikos nebūtinai yra klaidingos. Jos atsako į ankstesniame etape svarbius klausimus.
Rizika kyla pereinamuoju laikotarpiu. Bandomojo etapo metrikos dažnai išlieka, nes komandos moka jas pateikti, o niekas nėra atsakingas už sprendimą jų atsisakyti. Kadaise mokytis padėję rodikliai gali pamažu tapti tuštybės metrikomis.
Todėl poros turėtų turėti gyvavimo ciklą. Komandos turėtų jas įvesti konkrečiam sprendimui, tikrinti, ar jos vis dar atskleidžia reikšmingą kompromisą, ir jų atsisakyti pasikeitus produktui ar sprendimui.
DI sistemoms reikia išsamaus stebimumo, įspėjimų, kokybės užtikrinimo ir vertinimo. Pašalinus šiuos signalus, produktą būtų sunkiau saugiai eksploatuoti. Tačiau veiklos stebėsena nėra tas pats, kas vadovybei skirtas vertinimas.
Stebėsena padeda komandoms aptikti incidentus, atsekti gedimus ir suprasti sistemos elgseną. Sprendimų metrikos padeda produktų ir verslo vadovams nuspręsti, ar investuoti, įsikišti, keisti kryptį ar priimti kompromisą.
Organizacija gali stebėti šimtus techninių ir veiklos signalų, tačiau konkrečiam produkto sprendimui išskirti tik dvi ar tris viena kitą ribojančias poras. Nedidelis sprendimų lygmuo palengvina prioritetų nustatymą.
Tinkamas peržiūrų dažnis priklauso nuo produkto. Naujai ar sparčiai kintančiai sistemai sprendimų peržiūrų gali reikėti kas savaitę, o brandžiam produktui – kas mėnesį ar ketvirtį. Principas svarbesnis už intervalą: porą peržiūrėkite pakankamai dažnai, kad galėtumėte imtis veiksmų, kol kompromisas netapo brangus ar nesaugus.
Pora tampa naudinga tik organizacijai susitarus, kas bus daroma, jei jos rodikliai pablogės.
Tam nepakanka nustatyti kritinės rodiklių atotrūkio ribos. Komandos turėtų apsvarstyti tris sąlygas:
Absoliuti nesėkmė: vienas rodiklis peržengia nepriimtiną ribą, nepaisant kito rodiklio.
Išsiskyrimas: vienas rodiklis gerėja, o jį atsveriantis – blogėja.
Bendras blogėjimas: abi pusės prastėja, o tai rodo platesnę produkto ar veiklos problemą.
Kiekviena pora turėtų turėti:
įvardytą atsakingą asmenį;
aiškų sprendimą, kurį ji padeda priimti;
sutartas ribas arba vertinimo kriterijus;
tyrimo eigą; ir
galimų intervencijų rinkinį.
Be šių elementų organizacija produktą tik stebi, o ne valdo.
Prieš įtraukdami dar vieną rodiklį, pasirinkite vieną svarbų produkto sprendimą ir atsakykite į šiuos klausimus. Užrašykite atsakymus, kad peržiūrą užbaigtumėte sutartu kitu žingsniu.
1. Kokį sprendimą šios metrikos turi padėti mums priimti?
Būkite konkretūs: ar sprendžiame, ar plėsti automatizavimą, keisti modelį, ar gerinti perdavimą žmogui? Prieš pasirinkdami rodiklius įvardykite sprendimą.
2. Jei šis skaičius pagerės, kas galėtų pablogėti?
Nustatykite rezultatą, kurį reikia apsaugoti, ir rodiklį, kuris atskleistų žalą. Pavyzdžiui, vienos sąveikos sąnaudas susiekite su įvertinta rezultato kokybe, kad patikrintumėte, ar pigesni atsakymai tebėra naudingi.
3. Ką gali slėpti pagrindiniai skaičiai?
Abu rodiklius vertinkite tų pačių naudotojų, užduočių ir laikotarpio kontekste, tada ieškokite grupių, kurių rezultatai prastesni. Atsižvelkite ir į pradinę padėtį: menką pasitenkinimą gali lemti dar prieš kreipiantis pagalbos kilęs nusivylimas.
4. Kas paskatintų mus veikti ir kas atsakingas už veiksmus?
Nustatykite veiksmų kriterijus, taikomus vienam rodikliui peržengus nepriimtiną ribą, vienam gerėjant ir kitam blogėjant arba prastėjant abiem. Sutarkite, kas tirs problemą, ką pirmiausia patikrins ir kada pateiks išvadas.
5. Ar ši pora vis dar tinka dabartiniam produkto etapui?
Nuspręskite, ar ją palikti, pakeisti, ar jos atsisakyti. Bandomajame etape galima sutelkti dėmesį į užduočių patikimumą ir naudotojų pasitikėjimą, o realiai naudojamoje paslaugoje gali tekti atidžiau vertinti sąnaudas ir kokybę. Nustatykite datą, kada pasirinkimą peržiūrėsite iš naujo.
DI produktų vertinimas neturėtų apsiriboti rezultatų apibūdinimu. Jis turėtų atskleisti organizacijos daromus kompromisus ir padėti aiškiau priimti kitą sprendimą.