Palvelupyyntöjen valvominen uhkaavan viivästymän varalta on tehtävä, jonka AI voi ytimeltään ottaa kokonaan hoitaakseen. Kyse ei ole harmaasta alueesta, jossa tarvitaan ihmisen valvontaa: itse havaitseminen on tehtävä, joka on tänä päivänä jo automatisoitavissa olemassa olevalla teknologialla (rpa), kunhan muutamat reunaehdot ovat kunnossa.
Kolme akselia ovat tässä ratkaisevia: rakenteisuus, volyymi ja harkintavalta. Kaikki kolme osoittavat samaan suuntaan.
Rakenteisuus (5/5). Tehtävä koostuu päivämäärän vertaamisesta sääntöön: kuinka pitkään pyyntö on ollut avoinna, ja milloin sovittu käsittelyaika umpeutuu? Tämä ei ole tulkintaa, tämä on laskemista. Pyyntöjärjestelmä tallentaa avaamisajan, SLA-aika on ennalta määritetty, ja tarvitaan vain kahden luvun vertailu. Kun kyseiset SLA-ajat on määritelty yksiselitteisesti, ei ole tilaa epäilylle siitä, mitä "uhkaava" tarkoittaa.
Volyymi (5/5). Asiakaspalvelutiimi käsittelee tavallisesti kymmenistä satoihin pyyntöjä päivässä, joista jokaisella on omat umpeutuvat kellonsa. Tiimivetäjä, joka seuraa tätä manuaalisesti, joutuu jatkuvasti käymään läpi listaa ja laskemaan. Tämä on juuri sellaista toistuvaa, suurivolyymista työtä, josta ohjelmisto ei väsy ja jossa se ei jätä pyyntöjä huomaamatta.
Harkintavalta (4/5). Itse havaitseminen vaatii tuskin lainkaan harkintaa: aika on aika. Pieni marginaali on olemassa, koska joillakin organisaatioilla on vivahteita (esimerkiksi: lasketaanko asiakkaan odotusaika mukaan SLA-kelloon vai ei), mutta kun näistä säännöistä on sovittu, itse havaitsemisessa ei ole enää tilaa tulkinnalle.
Muut akselit ovat tässä pääkysymyksen kannalta käytännössä merkityksettömiä. Asiakaskontakti ja fyysiset toimenpiteet eivät koske tätä tehtävää: kyse on taustaprosessista, ei asiakaskeskustelusta. Luovuus ei ole kyseessä: uutta ratkaisua ei tarvitse keksiä, ainoastaan valvoa määräaikaa. Virhekustannukset ja vaatimustenmukaisuus saavat keskimääräisen pisteytyksen (3), ei siksi että itse havaitseminen olisi riskialtista, vaan siksi että unohtunut tai virheellinen ilmoitus voi vaikuttaa asiakastyytyväisyyteen tai sopimusvelvoitteisiin. Tämä ei puhu automatisointia vastaan, mutta puoltaa oikeaa etukäteisjärjestelyä.
Soveltuva teknologia on tässä suhteellisen vaatimaton: robottiprosessiautomaatio (rpa). Tässä ei tarvita kielimallia tai monimutkaista AI:ta päivämäärän vertaamiseen sääntöön. Skripti, joka lukee pyyntöjärjestelmää säännöllisesti, laskee jäljellä olevan ajan SLA-määräaikaan ja lähettää ennalta asetetun kynnysarvon ylittyessä ilmoituksen tiimivetäjälle, tekee työn. Tämä voi tapahtua sähköpostitse, hallintapaneelin widgetin kautta tai ilmoituksena itse pyyntöjärjestelmässä.
Reunaehdot ovat yksinkertaisia mutta olennaisia: SLA-ajat on määritettävä selkeästi ja yksiselitteisesti, ja havaitseminen on rakennettava teknisesti näiden aikojen pohjalta. Jos toinen näistä puuttuu, automatisointi ei toimi hyvin — ei siksi, että tehtävä olisi soveltumaton, vaan siksi, että perusta ei ole kunnossa.
Tämä lopputulos koskee havaitsemista. Se ei koske automaattisesti sitä, mitä tapahtuu ilmoituksen jälkeen. Organisaatiossa, jossa uhkaavan viivästymän eskaloituminen laukaisee välittömästi vakiintuneen, ennustettavan toiminnon (esimerkiksi: pyyntö ohjautuu automaattisesti asiantuntijalle), voidaan myös se seuraava vaihe suurelta osin automatisoida. Organisaatiossa, jossa eskalointi riippuu asiakassuhteesta, sopimusmuodosta tai poliittisesta herkkyydestä, tämä seuraava vaihe pysyy ihmistyönä — siinä ihmisen valvonta AI:ssa, käytännössä on relevantti lähtökohta.
Myös "SLA-ajan" määritelmä vaihtelee organisaatioittain. Yrityksellä, jolla on yksi yksinkertainen, yhtenäinen käsittelyaika, on yksinkertaisempi automatisointikysymys kuin yrityksellä, jolla on kymmeniä sopimusvariantteja, prioriteettitasoja ja poikkeussääntöjä. Mitä monimutkaisempi tämä sääntökokonaisuus on, sitä enemmän valmistelutyötä tarvitaan ennen kuin havaitseminen voi toimia luotettavasti automaattisesti. Juuri tästä syystä tarvitaan skannaus tehtävätasolla, ei toimenkuvatasolla: sama toimenkuva "asiakaspalvelun tiimivetäjä" voi yhdessä yrityksessä sisältää suurelta osin automatisoitavan havaitsemistehtävän, ja toisessa tehtävän, joka vaatii edelleen suurelta osin käsityötä.
Tämä sivu kuvaa tehtävän, ei henkilöstöpäätöstä. Se, vapautuuko tiimin kapasiteettia ja jaetaanko se uudelleen, ja miten, on organisaation oma valinta, jota koskevat sen omat lakisääteiset vaatimukset, varsinkin jos sillä on vaikutuksia toimenkuviin tai henkilöstörakenteeseen. Huolellisuus tässä, mukaan lukien yhteistoimintaelimen informoiminen, on erillinen prosessi — katso esimerkiksi yhteistoimintaelimen informoiminen AI:sta ja huolellisuus toimenkuvien poistamisessa. Tämä sivu ei anna siihen perusteluja, vain tosiasioita itse tehtävästä.
Uhkaavan SLA-viivästymän havaitseminen ei ole yksinäinen tapaus. Vastaavaa valvontaa ja havaitsemista esiintyy myös taloudellisissa prosesseissa, kuten toistuvassa tilauslaskutuksessa tai digitaalisten laskujen vaihtamisessa e-laskutuksen avulla. Myös näissä tapauksissa pätee: mitä rakenteellisemmat säännöt ja mitä suurempi volyymi, sitä soveltuvampi tehtävä on automatisointiin.
Haluatteko tietää, miten tilanne on omassa tiimissänne, mukaan lukien tarkka SLA-rakenne ja pyyntövolyymi, jonka kanssa työskentelette? Ftetoai:n ilmainen pikaskannaus koostuu kahdestatoista kysymyksestä, sen voi tehdä ilman tiliä, ja se antaa arvion siitä, kuinka suuri osa profiilinne tunneista on tänä päivänä siirrettävissä AI:lle. Täydellinen työskannaus, joka porautuu tehtävätasolle omissa prosesseissanne, on vielä rakenteilla — tätä lupausta emme tässä tarkoituksella tee suuremmaksi kuin se on.
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.