Aptarnavimo užklausų stebėjimas dėl gresiančio vėlavimo yra užduotis, kurią AI iš esmės gali visiškai perimti. Čia nekalbama apie pilkąją zoną su papildomu žmogaus priežiūra: pats signalizavimas yra užduotis, kurią jau šiandien galima automatizuoti su esamomis technologijomis (RPA), jei tik tenkinamos kelios pagrindinės sąlygos.
Čia lemiamą reikšmę turi trys ašys: struktūrizuotumas, apimtis ir sprendimo laisvė. Visos trys rodo tą pačią kryptį.
Struktūrizuotumas (5 iš 5). Užduotis susideda iš datos palyginimo su taisykle: kiek laiko užklausa jau yra atidaryta ir kada baigiasi sutartas sprendimo terminas? Tai nėra interpretacija, tai skaičiavimas. Užklausų sistema registruoja atidarymo laiką, SLA terminas yra nustatytas iš anksto, ir viskas, ko reikia, – dviejų skaičių palyginimas. Kai šie SLA terminai yra vienareikšmiškai apibrėžti, nėra vietos abejonėms, ką reiškia „gresiantis“.
Apimtis (5 iš 5). Klientų aptarnavimo komanda paprastai apdoroja nuo kelių dešimčių iki kelių šimtų užklausų per dieną, kiekviena su savo besibaigiančiu laikrodžiu. Komandos vadovui, kuris tai stebi rankiniu būdu, nuolat reikia peržiūrėti sąrašą ir skaičiuoti. Tai tiksliai tokio pobūdžio kartotinis, didelės apimties darbas, nuo kurio programinė įranga nepavargsta ir nepražiūri užklausų.
Sprendimo laisvė (4 iš 5). Pats signalizavimas vertinimo praktiškai nereikalauja: terminas yra terminas. Yra nedidelė riba, nes kai kurios organizacijos turi niuansų (pavyzdžiui, ar laukimo laikas pas klientą įskaičiuojamas į SLA laikrodį, ar ne), tačiau kai šios taisyklės yra nustatytos, paties signalizavimo procese interpretacijai vietos nebelieka.
Likusios ašys šiuo klausimu iš esmės nėra svarbios pagrindiniam klausimui. Kliento kontaktas ir fiziniai veiksmai šioje užduotyje nedalyvauja: tai fono procesas, o ne pokalbis su klientu. Kūrybiškumas nesvarbus: čia nereikia sugalvoti naujo sprendimo, tik stebėti terminą. Klaidų kaina ir atitiktis vertinamos vidutiniškai (3), ne todėl, kad pats signalizavimas yra rizikingas, o todėl, kad neįvykęs ar klaidingas pranešimas gali turėti poveikį klientų pasitenkinimui ar sutartiniams įsipareigojimams. Tai nėra argumentas prieš automatizavimą, bet yra argumentas už tinkamą parengimą iš anksto.
Tinkama technologija čia yra santykinai kukli: robotizuotas procesų automatizavimas (RPA). Datos palyginimui su taisykle nereikia kalbos modelio ar sudėtingos AI. Skriptas, kuris periodiškai nuskaito užklausų sistemą, apskaičiuoja likusį laiką iki SLA termino ir, pasiekus iš anksto nustatytą ribą, siunčia pranešimą komandos vadovui, atlieka šį darbą. Tai galima daryti el. paštu, informacinio skydelio elementu (widget) arba pranešimu pačioje užklausų sistemoje.
Pagrindinės sąlygos yra paprastos, bet esminės: SLA terminai turi būti aiškiai ir vienareikšmiškai nustatyti, o signalizavimas turi būti techniškai sukonfigūruotas remiantis šiais terminais. Trūkstant vieno iš šių dalykų, automatizavimas veiks netinkamai – ne todėl, kad užduotis nėra tinkama, o todėl, kad pagrindas nėra tvarkingas.
Šis rezultatas taikomas signalizavimui. Jis automatiškai nesitaiko tam, kas vyksta po pranešimo. Organizacijoje, kur gresiančio vėlavimo eskalavimas iš karto sukelia fiksuotą, nuspėjamą veiksmą (pavyzdžiui: užklausa automatiškai perduodama specialistui), šis vėlesnis žingsnis taip pat gali būti didžia dalimi automatizuotas. Organizacijoje, kur eskalavimas priklauso nuo kliento santykių, sutarties formos ar politinio jautrumo, šis vėlesnis žingsnis lieka žmogaus darbu – čia aktualus atspirties taškas yra žmogaus priežiūra AI atžvilgiu, konkrečiai.
Taip pat „SLA termino“ apibrėžimas skiriasi tarp organizacijų. Įmonė su vienu paprastu, vienodu sprendimo terminu susiduria su paprastesniu automatizavimo klausimu nei įmonė su dešimtimis sutarčių variantų, prioritetų lygių ir išimčių taisyklių. Kuo sudėtingesnis šis taisyklių rinkinys, tuo daugiau parengiamojo darbo reikia, kol signalizavimas gali patikimai veikti automatiškai. Tai tiksliai priežastis, kodėl reikalinga analizė pagal užduotį, o ne pagal pareigas: ta pati pareigų pavadinimas „klientų aptarnavimo komandos vadovas“ vienoje įmonėje gali reikšti didžia dalimi automatizuojamą signalizavimo užduotį, o kitoje – užduotį, kuri dar reikalauja daug rankinio darbo.
Šiame puslapyje aprašoma užduotis, ne personalo sprendimas. Ar ir kaip atsilaisvinęs pajėgumas komandoje bus perskirstytas, yra sprendimas, kuris priklauso pačiai organizacijai ir kuriam taikomi savi teisiniai reikalavimai, ypač jei tai turi įtakos pareigoms ar personalo struktūrai. Kruopštumas šiuo atžvilgiu, įskaitant darbuotarybos informavimą, yra atskiras procesas – žr., pavyzdžiui, darbo tarybos informavimą apie AI ir kruopštumą naikinant pareigas. Šis puslapis tam nepateikia pagrindimo, tik faktus apie pačią užduotį.
Gresiančio SLA vėlavimo signalizavimas nėra vienintelė tokio pobūdžio užduotis. Panašios stebėjimo ir signalizavimo užduotys pasitaiko ir finansiniuose procesuose, tokiose kaip periodinis prenumeratos sąskaitų faktūrų išrašymas arba elektroninių sąskaitų faktūrų mainai per e-sąskaitas. Ir čia taikoma taisyklė: kuo struktūrizuotesnės taisyklės ir kuo didesnė apimtis, tuo tinkamesnė užduotis automatizavimui.
Norite sužinoti, kaip tai atrodo jūsų komandoje, įskaitant konkrečią SLA struktūrą ir užklausų apimtį, su kuria dirbate? Nemokamą ftetoai greitąją apklausą sudaro dvylika klausimų, ją galima atlikti be paskyros, ir ji suteikia orientacinę informaciją, kokią dalį jūsų profilio valandų šiandien gali perimti AI. Pilna darbo analizė, kuri gilinasi į jūsų procesus iki užduoties lygio, dar kuriama – šio pažado čia sąmoningai nepadidiname labiau, nei jis yra.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.