Yhteystietojen, mieltymysten ja tilojen päivittäminen CRM:ssä vuorovaikutuksen tai muutoksen jälkeen on yksi niistä tehtävistä, joissa tekoäly voi jo tänään hoitaa suuren osan työstä. Ei siksi, että tekoäly olisi tarpeeksi "älykäs" ymmärtääkseen asiakkaita, vaan koska itse tehtävä vaatii vain vähän tulkintaa. Osoitteenmuutos, uusi puhelinnumero, tilan vaihtuminen liidistä asiakkaaksi: nämä ovat kenttiä, jotka täytetään, ei arvioida.
Kolme akselia ratkaisevat tässä: rakenteisuus, volyymi ja virhekustannukset.
Rakenteisuus saa korkeat pisteet, koska CRM toimii määritelmällisesti kiinteillä kentillä. Nimi, sähköpostiosoite, mieltymyskategoria: ne ovat tietoja, joilla on kiinteä paikka ja kiinteä muoto. Ei ole vapaata tekstiä, joka pitäisi tulkita, ei kontekstia, joka pitäisi punnita. Se tekee tehtävästä sopivan sääntöpohjaiseen käsittelyyn: jos kenttä X muuttuu lähteessä Y, päivitä kenttä X järjestelmässä Z.
Myös volyymi on korkea. Yrityksessä, jolla on laaja asiakaskanta, kyse on kymmenistä satoihin muutoksiin päivässä, jakautuneina yksittäisiin, pieniin toimenpiteisiin. Juuri sellaista työtä, jossa toistuva, ennustettava kaava painaa enemmän kuin satunnaiset poikkeukset. Korkea volyymi yhdistettynä korkeaan rakenteisuuteen on yhdistelmä, jossa automatisointi maksaa itsensä nopeimmin takaisin.
Virhekustannukset asettuvat keskitasolle. Väärin päivitetty puhelinnumero on harmillinen, mutta yleensä korjattavissa seuraavan yhteydenoton yhteydessä. Herkemmissä kentissä, kuten maksumieltymyksissä tai markkinointiviestinnän suostumuksessa, virheet painavat enemmän. Siksi validointi ei ole ylimääräinen vaihe vaan edellytys.
Harkintavara ja asiakaskontakti saavat keskitasoiset tai korkeat pisteet, ja juuri siinä piilee vivahde. Osa tilamuutoksista on yksiselitteisiä: asiakas muuttaa, osoite vaihtuu, valmista. Mutta kaikki muutokset eivät ole niin yksinkertaisia. Kun asiakaspalvelun työntekijän täytyy puhelun jälkeen arvioida, oikeuttaako valitus tilanmuutoksen "irtisanomisriski"-tilaan, kyse ei ole enää kentän täyttämisestä vaan arvioinnista. Se osuus pysyy ihmistyönä, tai se ainakin esitetään työntekijälle, joka hyväksyy tai hylkää perustellen.
Yrityksessä, jolla on yksinkertainen asiakasprofiili ja vähän poikkeuksia, tekoälyn omaksuttava osuus on siis suurempi kuin yrityksessä, jolla on monimutkaisia asiakassuhteita, paljon räätälöityjä sopimuksia tai arkaluonteisia henkilötietoja. Compliance vaikuttaa tässä myös: mitä enemmän kenttä liittyy GDPR-herkkään tietoon tai sopimusvelvoitteisiin, sitä aiheellisempaa on inhimillinen tarkistuskierros ennen kuin muutos vahvistetaan lopulliseksi.
Tekniikka, jota jo nyt käytetään, on pääasiassa rpa: ohjelmisto, joka siirtää tietoja kiinteiden sääntöjen mukaan lähteestä toiseen, tunnistaa kaksoiskappaleet ja täyttää kentät kiinteän kartoituksen perusteella. Se ei ole tekoälyä, joka "ymmärtää" kuka asiakas on, vaan automatisoitua rakenteisen syötteen käsittelyä.
Kolme reunaehtoa määrittää, toimiiko se:
Jos jokin näistä kolmesta puuttuu, tehtävä siirtyy takaisin toiseen kategoriaan: tekoäly tekee ehdotuksen, työntekijä hyväksyy tai hylkää.
Se, mikä nyt muuttuu, ei ole se, että työntekijät käyvät tarpeettomiksi, vaan se, että heidän aikansa siirtyy syöttötyöstä tarkistustyöhön. Siinä missä työntekijä ennen kirjoitti osoitteenmuutoksen käsin, hän nyt arvioi listan ehdotetuista muutoksista ja klikkaa hyväksy tai hylkää. Se on eri tehtävä, eri ajankäytöllä, ei välttämättä vähemmän työtä mutta erilaista työtä.
Tämä muutos kulkee rinnakkain sen kanssa, mitä tapahtuu tilausten syöttämisessä järjestelmään ja tilaustilan tarkistamisessa ja siitä viestimisessä: niissäkin kaava on rakenteinen syöte, suuri volyymi, rajalliset virhekustannukset, poikkeuksineen, jotka jäävät ihmisen hoidettaviksi. Sille, joka pohtii, miten tämä suhteutuu muihin asiakaslähtöisiin tehtäviin, löytyy vastaava punninta kohdasta varasto- ja toimitusaikatietojen antaminen, jossa vallitsee sama jännite nopeuden ja hieman enemmän selitystä vaativien tapausten välillä. Ja sille, joka näkee CRM-työn ennen kaikkea osana laajempaa prosessia, talousosaston työn yleiskatsaus on hyvä lähtökohta, sillä asiakas- ja laskutustiedot jakavat usein samat lähdejärjestelmät.
Otetaanko tämä käyttöön organisaatiossa ja kuinka nopeasti, ei ole pelkästään tekninen kysymys. Tästä mahdollisesti seuraavat henkilöstövaikutukset kuuluvat työnantajan omien lakisääteisten velvoitteiden piiriin; tämä sivu ei ota siihen kantaa.
Tämä sivu kuvaa yhden tehtävän erillään muista. Todellinen kokonaiskuva syntyy vasta, kun tätä tehtävää tarkastellaan rinnakkain yrityksen muiden tehtävien kanssa: joillakin on samankaltainen profiili, toiset ovat täysin erilaisia. Ensivaikutelman saamiseksi tarjolla on ilmainen pikatesti: kaksitoista kysymystä, ilman tiliä, tuloksena arvio siitä, kuinka suuren osan kyseisen profiilin tunneista tekoäly voisi tänään ottaa hoitaakseen. Täydellinen työanalyysi, joka jakaa yrityksen työn tehtäviin ja laskee jokaisen tehtävän vaikutuksen henkilötyövuosikapasiteettiin, on vielä rakenteilla.
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.