Asiakkaan tunnistaminen puhelun aikana tekoälyllä

Puhelussa tunnistaminen on hankala laji. Asiakas haluaa hoitaa asiansa nopeasti, mutta yrityksen pitää silti varmistaa että tietoja ei anneta väärälle henkilölle eikä järjestelmään tehdä muutoksia liian kevyellä varmistuksella.

Monessa yrityksessä tämä näkyy kömpelönä kompromissina. Kysytään nimi, syntymäaika, postinumero ja ehkä vielä asiakasnumero, vaikka puolet tiedoista löytyisi jo valmiiksi. Lopputulos on hidas, ärsyttävä ja silti yllättävän hauras.

AI ei muuta tunnistamista turvalliseksi yksinään, mutta se tekee siitä paljon sujuvampaa. Kun järjestelmä osaa yhdistää puhelinnumeron, aiemmat kontaktit, CRM-taustatiedot ja oikeat varmennuskysymykset samaan virtaan, asiakas pääsee nopeammin asiaan ja riski pienenee.

Mitä puhelussa voidaan tunnistaa?

Ensimmäinen kerros on puhelinnumero. Jos numero löytyy CRM:stä tai asiakasrekisteristä, järjestelmä voi päätellä todennäköisen soittajan jo ennen ensimmäistä lausetta. Tämä ei vielä riitä vahvaksi tunnistukseksi, mutta se antaa hyvän lähtöpisteen.

Toinen kerros on konteksti. Soittaako asiakas numerosta, jota on käytetty aiemmin? Onko hänellä avoin tilaus, tiketti, ajanvaraus tai lasku? Tällainen taustatieto auttaa valitsemaan oikeat varmennuskysymykset.

Kolmas kerros on aktiivinen varmennus. AI voi pyytää asiakkaalta esimerkiksi asiakasnumeroa, tilausnumeroa, postinumeroa, syntymäaikaa tai kertakäyttökoodia. Oleellista on, että kysymykset valitaan riskitason mukaan, ei summamutikassa.

Neljäs kerros on puheeseen perustuva tunnistus. Puhebiometria voi olla hyödyllinen lisä, mutta sitä ei kannata myydä hopealuotina. Se toimii parhaiten osana laajempaa tunnistusmallia, ei ainoana totuutena.

Miltä hyvä tunnistusvirta näyttää käytännössä?

Toimiva malli etenee yleensä näin.

Ensin järjestelmä ottaa puhelun vastaan ja tarkistaa soittajan numeron. Jos numero löytyy tunnetulta asiakkaalta, AI hakee siihen liittyvän kontekstin: avoimet tapaukset, tilaukset, sopimukset tai ajanvaraukset.

Sitten AI kysyy yhden tai kaksi varmennuskysymystä, jotka sopivat juuri kyseiseen tilanteeseen. Jos asiakas soittaa ajanvarauksesta, oikea kysymys voi olla varattu päivämäärä tai toimipiste. Jos hän soittaa laskusta, oikea kysymys voi olla laskun summa tai viitenumero. Tunnistus muuttuu heti sujuvammaksi, kun kysymys liittyy käsillä olevaan asiaan.

Sen jälkeen järjestelmä päättää riskitason.

• matala riski: voidaan antaa yleistä tietoa ja ohjata oikeaan paikkaan
• keskitaso: voidaan näyttää asiakastiedot agentille ja jatkaa palvelua
• korkea riski: tarvitaan lisävahvistus tai siirto ihmiselle

Tämä on tärkeää, koska kaikki puhelut eivät ole samanarvoisia. Aukioloajan kertominen ei vaadi samaa varmistusta kuin osoitteen muuttaminen, pankkitiedon tarkistaminen tai reseptin uusinta.

Missä AI auttaa eniten?

Suurin hyöty tulee siitä, että AI valitsee oikean varmennuspolun automaattisesti.

Ilman AI:ta puhelut käsitellään usein yhdellä jäykällä skriptillä. Jokaiselta kysytään samat asiat riippumatta siitä, onko asiakas uusi, tunnettu, matalan riskin tapauksessa vai kriittisen muutoksen äärellä.

AI:n kanssa prosessi voi olla fiksumpi:

• tunnettu numero saa lyhyemmän varmennuspolun
• toistuva asiakas voidaan ohjata samaan asiakkuuskontekstiin heti
• korkean riskin toimenpide laukaisee vahvemman varmistuksen
• epäselvä tai ristiriitainen tieto ohjataan suoraan ihmiselle

Tämä vähentää kitkaa kaikilta muilta paitsi niiltä tilanteilta, joissa lisävarmistus on oikeasti tarpeen. Juuri näin sen pitääkin mennä.

Tietoturva, GDPR ja riskirajat

Puhelussa tehtävä tunnistus koskee lähes aina henkilötietoja, joten pelkkä käytettävyys ei riitä suunnitteluperusteeksi.

Yrityksen pitää päättää ainakin nämä asiat selvästi:

• mitä tietoja voidaan kertoa ennen tunnistusta
• mitä tietoja voidaan käyttää tunnistukseen
• mitä toimenpiteitä AI saa tehdä itsenäisesti
• milloin vaaditaan lisävahvistus tai ihmiskäsittely
• miten puhelu, tunnistuspolku ja tehdyt toimenpiteet lokitetaan

Esimerkiksi tilauksen tilan voi usein kertoa kevyemmällä varmennuksella kuin osoitteen muutoksen. Pankki- ja vakuutusasioissa raja on vielä tiukempi. Terveydenhuollossa sama pätee käytännössä kaikkeen, mikä liittyy potilastietoon.

Tämä on myös syy siihen, miksi tunnistus kannattaa rakentaa yhteistyössä liiketoiminnan, tietoturvan ja asiakaspalvelun kanssa. Pelkkä tekninen toteutus ei riitä, jos riskiluokat ovat epäselvät.

Esimerkki riskipohjaisesta tunnistuspolusta

Kuvitellaan kolme erilaista puhelua.

Ensimmäisessä asiakas kysyy toimituksen arvioitua saapumisaikaa. Numero löytyy CRM:stä ja asiakas osaa vahvistaa tilausnumeron. Tässä riittää usein kevyt tunnistus, jonka jälkeen AI tai agentti voi kertoa tilannepäivityksen.

Toisessa asiakas haluaa vaihtaa laskutusosoitteen. Sama puhelinnumero löytyy, mutta kyse on jo tietomuutoksesta. Tällöin kevyt tunnistus ei riitä, vaan tarvitaan esimerkiksi lisäkysymys, kertakäyttökoodi tai siirto ihmiselle.

Kolmannessa puhelussa asiakas yrittää tehdä korkean riskin muutoksen eikä puhelinnumero täsmää järjestelmään. Tällöin oikea ratkaisu ei ole auttaa kohteliaasti eteenpäin väkisin, vaan pysäyttää prosessi, rajata näkyvät tiedot ja siirtää tapaus vahvempaan varmennukseen.

Tämä on käytännössä koko mallin ydin: sama järjestelmä voi olla nopea matalan riskin asioissa ja tiukka silloin kun pitää olla.

Missä käyttökohteissa malli toimii erityisen hyvin?

Puhelussa tehtävä AI-avusteinen tunnistus toimii hyvin esimerkiksi näissä tilanteissa:

• ajanvaraus ja ajan siirto terveydenhuollossa tai palveluissa
• toimitus- ja tilaustiedustelut verkkokaupassa
• laskukopiot ja maksutilanne taloushallinnossa
• vikailmoitukset kiinteistöhuollossa
• sopimus- ja asiakkuustiedon tarkistus B2B-palveluissa

Näissä kaikissa asiakkaan asia voidaan ottaa haltuun nopeasti, mutta tietojen käsittely vaatii silti hallittua varmennusta.

Jos puheluvirtoja halutaan tunnistaa ja ohjata samalla kertaa, kannattaa katsoa myös puheluiden ohjausta tekoälyllä ja AI-puhelinvaihteen käyttöönottoa.

Miten tunnistus nopeutuu ilman että turvallisuus löystyy?

Hyvä nyrkkisääntö on tämä: poista turhat kysymykset, älä tärkeitä kysymyksiä. Jos puhelinnumero, CRM-konteksti ja aiempi asiointihistoria antavat jo vahvan lähtöpisteen, asiakkaalta ei kannata kysyä jokaista perustietoa uudelleen. Sen sijaan lisävahvistus kannattaa säästää niihin hetkiin, joissa oikeasti avataan arkaluonteisia tietoja tai tehdään muutoksia.

Tämä tekee prosessista sekä nopeamman että turvallisemman, koska huomio kohdistuu oikeisiin riskikohtiin. Yhtä jäykkä skripti kaikille tuntuu tasapuoliselta, mutta käytännössä se on usein sekä hidas että huonosti kohdistettu.

Käyttöönoton tarkistuslista

Ennen tuotantoon vientiä käy ainakin nämä läpi:

• mitä tunnistustapoja on käytössä nyt ja mitä niistä kannattaa säilyttää
• mihin toimenpiteisiin riittää kevyt tunnistus ja mihin ei
• mitä lisävahvistusta käytetään korkean riskin tilanteissa
• miten poikkeamat, ristiriidat ja epäonnistuneet tunnistukset käsitellään
• miten lokitus ja audit trail toteutetaan
• miten asiakkaalle kerrotaan tunnistusvaiheesta ymmärrettävästi

Kun nämä on päätetty, AI-avusteinen tunnistus ei jää irralliseksi ominaisuudeksi vaan muuttuu osaksi hallittua puheluprosessia.

Yleisimmät virheet

Ensimmäinen moka on luottaa pelkkään puhelinnumeroon. Numero kertoo paljon, mutta ei tarpeeksi. Puhelin voi olla yhteinen, vanha tai väärissä käsissä.

Toinen moka on kysyä kaikilta kaikki. Tämä tuntuu turvalliselta, mutta käytännössä heikentää kokemusta ja pidentää puhelua turhaan.

Kolmas moka on antaa AI:lle liian paljon päätösvaltaa ilman riskirajoja. Kaikkia muutoksia ei pidä sallia automaattisesti, vaikka tunnistus näyttäisi todennäköiseltä.

Neljäs moka on lokituksen unohtaminen. Jos et näe jälkikäteen mitä tietoja käytettiin, mitä kysyttiin ja miksi asiakas hyväksyttiin tai eskaloitiin, auditointi muuttuu arvailuksi.

Tunnistusprosessi kannattaa testata myös epäonnistumisen kautta. Mitä tapahtuu jos puhelinnumero ei täsmää, asiakas ei muista tietojaan tai taustajärjestelmä ei vastaa? Juuri nämä hetket ratkaisevat, tuntuuko palvelu turvalliselta ja johdonmukaiselta vai siltä, että koko malli romahtaa ensimmäiseen poikkeamaan.

Samalla kannattaa testata myös agentin näkymä. Jos ihmiselle eskaloitu puhelu saapuu ilman tietoa siitä, mitä jo kysyttiin ja mikä meni pieleen, asiakas joutuu aloittamaan alusta. Se syö luottamusta nopeasti, vaikka varsinainen tunnistuslogiikka olisi teknisesti kunnossa.

Usein kysyttyä AI-avusteisesta tunnistamisesta

Riittääkö puhelinnumero koskaan yksin tunnistukseen?

Harvoin. Se voi riittää matalan riskin tilanteeseen lähtötiedoksi, mutta yksinään se on liian heikko perusta merkittäville muutoksille tai arkaluonteisten tietojen näyttämiselle. Siksi numero kannattaa nähdä vihjeenä, ei lopullisena totuutena.

Kannattaako puhebiometria ottaa heti mukaan?

Ei automaattisesti. Jos liiketoimintaympäristö on tiukasti säännelty tai puheluvolyymi suuri, puhebiometria voi olla hyödyllinen lisä. Monessa ympäristössä päästään kuitenkin pitkälle yhdistämällä puhelinnumero, konteksti, kertakäyttökoodi ja riskipohjainen päätöspuu.

Mitä tapahtuu jos tunnistus epäonnistuu?

Hyvä prosessi ei romahda. Se siirtyy vahvempaan varmennukseen, rajaa näkyvät tiedot minimiin ja tarvittaessa ohjaa ihmiselle. Tunnistuksen epäonnistuminen on normaali poikkeama, ei katastrofi, jos polku on suunniteltu valmiiksi.

Voiko AI tehdä tunnistuksen myös chatissa tai sähköpostissa?

Voi, mutta logiikka on hieman erilainen. Chatissa voidaan käyttää kirjautumista, asiakastunnuksia ja kertakäyttökoodeja. Sähköpostissa tunnistus on yleensä heikompi, joten korkean riskin toimenpiteet kannattaa ohjata vahvempaan kanavaan. Sama riskipohjainen ajattelu toimii silti kaikkialla.

Pitääkö asiakkaalle kertoa, että puhelu analysoidaan tunnistustarkoituksessa?

Kyllä, ainakin siinä laajuudessa kuin oma toimiala, tietosuojakäytäntö ja käytetty teknologia edellyttävät. Käytännössä tämä tarkoittaa selkeää informointia siitä, mitä tietoja käsitellään, mihin tarkoitukseen ja milloin puhelu siirtyy ihmiselle. Epämääräinen viittaus analytiikkaan ei riitä, jos prosessissa tehdään tunnistukseen vaikuttavia päätöksiä.

Kuinka paljon integraatioita tunnistusmalli yleensä tarvitsee?

Useimmiten vähintään CRM:n, asiakasrekisterin tai toiminnanohjausjärjestelmän. Monessa ympäristössä mukaan tulee myös ajanvaraus, tilausjärjestelmä, tikettialusta tai vahvan tunnistuksen palvelu. Mitä paremmin nämä keskustelevat keskenään, sitä vähemmän asiakkaalta tarvitsee kysyä samoja tietoja uudelleen.

Kuka omistaa tunnistusmallin käytännössä?

Paras omistaja on yleensä yhteinen kolmikko: liiketoiminta määrittää riskit, tietoturva rajat ja operatiivinen asiakaspalvelu arjen toimivuuden. Jos malli jää vain IT-projektiksi, se voi olla teknisesti siisti mutta käytännössä kömpelö.

Miten mallia kannattaa ylläpitää käyttöönoton jälkeen?

Seuraa poikkeamia, väärin tunnistettuja puheluita, lisävahvistukseen päätyneiden tapausten määrää ja agenttien palautetta. Tunnistus ei ole kertarakennelma. Se tarvitsee samanlaista jatkuvaa hienosäätöä kuin mikä tahansa kriittinen asiakaspalveluprosessi. Kun riskit, poikkeamat ja käyttäjäkokemus tarkistetaan säännöllisesti, malli pysyy sekä turvallisena että siedettävänä asiakkaalle. Tämä työ ei lopu julkaisuhetkeen, vaan jatkuu jokaisessa auditissa, palautekierroksessa ja prosessipäivityksessä. Mitä kriittisemmästä toimialasta on kyse, sitä tärkeämpää tämä jatkuva ylläpito on tuotannossa, auditoinneissa ja arjen poikkeamissa joka viikko. Se on käytännön turvallisuustyötä joka päivä tuotannossa, asiakkaan arjessa ja operatiivisessa seurannassa.

Yhteenveto

Asiakkaan tunnistaminen puhelun aikana tekoälyllä kannattaa rakentaa riskipohjaisesti. Kevyet asiat saavat kevyen varmennuksen. Korkean riskin toimenpiteet saavat vahvemman polun tai siirtyvät ihmiselle. Näin sekä turvallisuus että käyttökokemus pysyvät järkevinä.

AI tuo tähän eniten arvoa silloin, kun se osaa yhdistää puhelinnumeron, CRM-kontekstin, oikeat varmennuskysymykset ja selkeän päätöspuun yhdeksi palveluvirraksi. Silloin puhelu ei jää kiinni joko liialliseen varovaisuuteen tai vaaralliseen mutuiluun.

Jos haluat suunnitella tunnistuspolun, joka toimii käytännössä eikä vain tietoturvakansiossa, kysy lisää — ota yhteyttä.