AI-puhelinpalvelun testaus — laadunvarmistuksen parhaat käytännöt

AI-puhelinpalvelun testaus alkaa siitä ikävästä totuudesta, että demo valehtelee helposti. Viiden minuutin esittelypuhelu voi kuulostaa hyvältä, vaikka tuotannossa botti kompastuu heti ensimmäiseen poikkeustilanteeseen.

Hyvä testaus ei kysy, kuulostaako ääni mukavalta. Se kysyy: ymmärtääkö botti asiakkaan asian, hakeeko se oikean tiedon, pysyykö se luvatussa roolissa ja osaako se pyytää ihmisen apuun ajoissa.

Jos nämä asiat jätetään testaamatta, ensimmäinen laadunvarmistaja on maksava asiakas. Se on kallis tapa oppia.

Määrittele hyväksymiskriteerit ennen testipuheluita

Testaus menee hukkaan, jos onnistumista ei ole määritelty. AI-puhelinpalvelulle kannattaa kirjoittaa samat hyväksymiskriteerit kuin mille tahansa tuotantoon menevälle järjestelmälle.

Käytännössä kriteerit voivat olla esimerkiksi:

• botti tunnistaa vähintään 90 prosenttia sovituista intentioista testiaineistossa
• botti ei anna hinta-, sopimus- tai saatavuuslupauksia, joita ei löydy lähdejärjestelmästä
• botti siirtää puhelun ihmiselle, jos asiakas pyytää sitä kahdesti tai käyttää sovittuja riskisanoja
• varaukset, tiketit ja yhteydenottopyynnöt kirjautuvat oikein taustajärjestelmään
• puhelun lopputulos näkyy raportoinnissa ilman käsityötä

Numerot eivät ole pyhiä. Olennaista on, että rima on näkyvissä. Muuten jokainen testipalaveri päättyy samaan: "ihan hyvältä se kuulosti".

Rakenna testiskenaariot oikeista puheluista

Paras testiaineisto löytyy vanhoista puheluista, tiketeistä, chat-lokeista ja asiakaspalvelijoiden muistista. Niistä näkee, miten asiakkaat oikeasti puhuvat. Harva sanoo "haluan tehdä palvelupyynnön". Moni sanoo "tää hajos taas".

Testiskenaarioita kannattaa tehdä vähintään neljästä ryhmästä.

Ensimmäinen ryhmä on perusasiat: aukioloajat, ajanvaraus, tilauksen tila, hinnan kysyminen, yhteydenottopyyntö. Näiden pitää mennä tylsän varmasti.

Toinen ryhmä on reunatapaukset. Asiakas antaa puutteelliset tiedot, käyttää murretta, puhuu taustamelussa tai vaihtaa asiaa kesken puhelun. Tässä kohtaa nähdään, onko botti oikeasti keskusteleva vai vain nätti IVR.

Kolmas ryhmä on riskitilanteet. Reklamaatio, sopimusriita, laskuvirhe, henkilötieto, terveys- tai turvallisuushuoli. Näissä botin ei tarvitse ratkaista kaikkea. Sen pitää tunnistaa raja.

Neljäs ryhmä on väärinkäyttö: asiakas yrittää saada botin ohittamaan sääntöjä, paljastamaan sisäisiä ohjeita tai lupaamaan alennuksia. Tämä kuulostaa teoreettiselta, kunnes joku tekee sen oikeasti.

Testaa myös hiljaiset virheet

Huono vastaus on helppo huomata. Hiljainen virhe on pahempi. Se näyttää onnistuneelta, mutta kirjaa väärän ajan, väärän sähköpostin tai väärän palveluluokan CRM:ään.

Siksi jokaisessa testissä pitää tarkistaa sekä puhelun sisältö että järjestelmäjälki. Jos botti sanoo luoneensa tiketin, tiketin pitää löytyä oikeasta paikasta. Jos se lupaa takaisinsoiton, tehtävän pitää näkyä oikealla ihmisellä. Jos se siirtää puhelun, kontekstin pitää kulkea mukana.

Tässä kannattaa tehdä yksinkertainen tarkistuslista:

• mitä asiakas pyysi
• mitä botti vastasi
• mitä botti teki järjestelmässä
• mitä dataa tallentui
• mitä ihmisen pitää tehdä seuraavaksi

Jos yksikin rivi jää epäselväksi, tuotannossa se muuttuu käsityöksi.

Kuuntele puhelut, älä pelkkää transkriptiota

Transkriptio on hyödyllinen, mutta se kadottaa sävyn. Puhelussa merkitystä on tauoilla, päälle puhumisella, turhautumisella ja sillä, kuulostaako botti varmalta vai arvaavalta.

Testijakson aikana kannattaa kuunnella otos puheluista joka päivä. Ei kaikkia, se ei skaalaudu. Mutta tarpeeksi monta, jotta kuulee toistuvat ongelmat. Jos sama kohta tökkii kolmessa puhelussa, kyse ei ole yksittäisestä asiakkaasta vaan ohjeistuksesta.

Mittaa laatua ennen käyttöönottoa ja sen jälkeen

Ennen tuotantoa mitataan testiaineisto. Tuotannossa mitataan oikeaa käyttöä. Molempia tarvitaan.

Hyödyllisiä mittareita ovat intentin tunnistuksen osuvuus, onnistunut ratkaisu ilman ihmistä, eskalointien määrä, keskeytetyt puhelut, virheelliset kirjaukset, asiakkaan odotusaika ja jälkikäsittelyyn kulunut aika. Jos puheluita nauhoitetaan, myös satunnaisotos kannattaa auditoida käsin.

Mittareista ei pidä tehdä koristeita dashboardiin. Niiden pitää ohjata muutoksia. Jos eskalointeja tulee paljon samasta aiheesta, botti tarvitsee paremman ohjeen tai aiheen pitää siirtyä ihmiselle. Jos virheellisiä kirjauksia tulee tietystä integraatiosta, ongelma on todennäköisesti datamallissa eikä puheentunnistuksessa.

Hyväksy tuotanto vaiheittain

AI-puhelinpalvelu kannattaa julkaista ensin rajattuun käyttöön. Yksi numero, yksi toimipiste, yksi palvelupolku tai tietty kellonaika. Näin virheet näkyvät pieninä, eivät koko yrityksen asiakaspalvelun etusivulla.

Ensimmäisen viikon tavoite ei ole täydellinen automaatio. Tavoite on löytää ne kohdat, joissa asiakkaat käyttäytyvät eri tavalla kuin suunnittelupöydällä oletettiin. Niitä tulee aina. Se ei ole epäonnistuminen, vaan syy tehdä käyttöönotto hallitusti.

Yhteenveto

AI-puhelinpalvelun laadunvarmistus ei ole viimeinen muodollinen rasti ennen julkaisua. Se on se työ, joka erottaa käyttökelpoisen palvelun näyttävästä demosta.

Aloita hyväksymiskriteereistä. Testaa oikeilla puhelutyypeillä. Tarkista järjestelmäjälki. Kuuntele puheluita. Julkaise pienesti ja paranna havaintojen perusteella.

Jos nämä tehdään kunnolla, tuotantoon ei mene musta laatikko. Sinne menee palvelu, jonka rajat tunnetaan.