Case: pk-yrityksen AI-puhelinpalvelu 2 viikossa – suunnitteluesimerkki

Pk-yrityksen AI-puhelinpalvelu kannattaa aloittaa yhdestä tehtävästä, jonka onnistumisen voi tarkistaa. Tässä kuvitteellisessa esimerkissä pieni huoltopalveluyritys ottaa kahden viikon aikana käyttöön puhebotin, joka vastaa yleisiin palvelukysymyksiin ja kirjaa takaisinsoittopyynnöt. Se ei vielä varaa huoltoja eikä anna sitovia hintoja. Näin ensimmäisen version toimivuus voidaan arvioida ilman, että samalla uudistetaan koko yrityksen toiminnanohjaus.

Tämä on suunnitteluesimerkki, ei Aisterin toteutunut asiakastarina. Yritys, työmäärät ja testitapaukset ovat kuvitteellisia. Kahden viikon aikataulu on rajatun pilotin tavoite, ei toimituslupaus. Sen edellytyksiä ovat käytettävissä oleva puhelinratkaisu, hyväksytyt palvelutiedot sekä yrityksen vastuuhenkilö, joka ehtii tehdä päätökset.

Esimerkin yrityksessä on 12 työntekijää. Yrittäjä ja työnjohtaja vastaavat puheluihin muun työn ohessa. Asiakas saattaa kysyä toiminta-aluetta, tiedustella korjausta tai pyytää tarjousta. Kun puheluun ei ehditä vastata, seuraava ongelma on selvittää, kenelle pitäisi soittaa takaisin. Pilotti kohdistuu tähän katkokseen. Varsinainen huoltotyön arviointi jää edelleen ihmiselle.

Pk-yrityksen AI-puhelinpalvelu alkaa rajatusta tavoitteesta

Ensimmäisessä palaverissa yrittäjä haluaa botin hoitavan kaikki puhelut. Työnjohtaja nostaa esiin poikkeukset: joskus työn kiireellisyys selviää vasta lisäkysymyksillä, varaosaa ei ole saatavilla tai asiakas viittaa aiempaan sopimukseen. Näihin ei ole yhtä valmista vastausta. Kahden viikon pilotti rajataan siksi palveluinfoon ja yhteydenottopyyntöihin.

Tavoite kirjoitetaan yhdeksi tarkistettavaksi lauseeksi: jos yritys ei vastaa, soittaja saa hyväksytyn perustiedon tai hänen yhteydenottopyyntönsä päätyy nimetyn työntekijän käsittelyyn. Pelkkä puhelimeen vastaaminen ei riitä. Onnistuminen edellyttää, että myös seuraava työvaihe toimii.

Mitä ensimmäinen versio saa tehdä?

Puhebotti saa kertoa toiminta-alueen ja palveluajat yrityksen hyväksymästä ohjeesta. Se voi pyytää asiakkaan nimen, takaisinsoittonumeron ja lyhyen kuvauksen asiasta. Lopuksi se lukee numeron takaisin ja kertoo, että pyyntö on välitetty käsiteltäväksi, mutta vasta saatuaan järjestelmältä vahvistuksen tallennuksesta.

Botti ei päätä työn hintaa, lupaa asentajan saapumisaikaa eikä muuta asiakkaan sopimusta. Jos kysymys koskee kesken olevaa työtä, se ohjaa asian ihmiselle. Myös asiakkaan suora pyyntö puhua työntekijän kanssa riittää siirtoon. Asiakkaan ei tarvitse perustella, miksi hän ei halua jatkaa botin kanssa.

Tämä rajaus vaikuttaa myös tarvittaviin tietoihin. Pilotti ei tarvitse pääsyä laskutukseen tai koko asiakasrekisteriin. Sille riittää hyväksytty palveluohje ja rajattu tapa luoda yhteydenottopyyntö. Jos myöhemmin halutaan muuttaa varauksia, kyse on uudesta käyttötapauksesta, joka arvioidaan erikseen.

Kuka omistaa takaisinsoittopyynnön?

Yritys nimeää yhden käsittelijän ja hänelle varahenkilön. Pyynnöt tulevat samaan työjonoon, jota he käyttävät muutenkin. Näin aamuvuoron ei tarvitse muistaa tarkistaa erillistä AI-näkymää. Käsittelijä kuittaa pyynnön vastaanotetuksi ja merkitsee, milloin asiakasta on tavoiteltu.

Aikarajasta sovitaan yrityksen todellisen työrytmin mukaan. Jos työnjohtaja pystyy käsittelemään pyynnöt vasta seuraavana työpäivänä, botti ei lupaa soittoa tunnin sisällä. Palvelulupauksen pitää mahtua kalenteriin myös kiireisenä päivänä. Tässä vaiheessa voi paljastua, että hyödyllisin muutos onkin takaisinsoittojen vastuun selkeyttäminen.

Päivät 1–5: pk-yrityksen AI-puhelinpalvelun pohjatyö

Ensimmäiset päivät käytetään nykyisten puheluiden ymmärtämiseen. Työnjohtaja käy läpi esimerkkiviikon yhteydenottoja ja kirjaa aiheita ilman tarpeettomia asiakastietoja. Tarkoitus on selvittää, kuinka moni kysymys ratkeaa palveluohjeella ja kuinka moni vaatii ammattilaisen harkintaa. Pelkkä puheluiden kokonaismäärä ei vastaa tähän.

Päivät 1–2: aineisto ja hyväksytyt vastaukset

Yritys kokoaa lyhyen palveluohjeen. Siihen tulevat palvelut, toiminta-alue, aukioloajat, yhteydenottotavat ja tilanteet, joissa vastaus kuuluu työntekijälle. Ohjeen omistaja tarkistaa jokaisen tiedon. Verkkosivulta löytyvä vanha hinnasto tai työntekijän muistinvarainen poikkeus ei siirry automaattisesti botin vastaukseksi.

Ohjeeseen kirjoitetaan myös, miten puuttuvaan tietoon vastataan. Jos asiakas kysyy korjauksen kestoa eikä sitä voida arvioida, botti kertoo, että työnjohtajan on tarkistettava asia. Sen ei pidä täydentää aukkoa uskottavalta kuulostavalla arviolla. Testaaja tarkistaa tämän tarkoituksella kysymyksellä, johon ohjeessa ei ole vastausta.

Projektin vastuuhenkilö hyväksyy aineiston ennen puheohjeen rakentamista. Jos tiedot ovat ristiriidassa, niitä ei jätetä kehittäjän ratkaistaviksi. Esimerkiksi palveluajan ja puhelinajan ero täytyy selvittää yrityksen sisällä. Muuten sama epäselvyys kuuluu pian asiakkaalle asti.

Päivät 3–4: keskustelu ja tallennus

Puhelun alussa kerrotaan lyhyesti, että vastaaja on yrityksen tekoälyavustaja. Sen jälkeen kysytään asiakkaan asiaa. Esimerkin botilla on kaksi pääreittiä: hyväksytty vastaus yleiseen kysymykseen tai takaisinsoittopyynnön kirjaaminen. Tarpeettomat kysymykset karsitaan. Palvelualueen tiedusteluun ei tarvita asiakkaan sähköpostiosoitetta.

Takaisinsoittopyynnön kentät määritellään ennen integraation tekemistä. Jokaiselle pyynnölle syntyy yksilöivä tunniste, jonka avulla saman tallennusyrityksen toisto voidaan tunnistaa. Jos yhteys katkeaa kuittauksen aikana, järjestelmä ei saa luoda kahta identtistä tehtävää pelkän uudelleenyrityksen vuoksi.

Puhelinnumeron vahvistaminen tehdään ääneen. Soittajan numeroa ei oleteta automaattisesti oikeaksi takaisinsoittonumeroksi, sillä asiakas voi soittaa työpaikan vaihteesta tai toisen henkilön puhelimesta. Epäselvä numero kysytään uudelleen. Tallennuksen onnistuminen ja numeron oikeellisuus ovat kaksi eri tarkistusta.

Päivä 5: toimintatapa henkilöstölle

Työnjohtaja ja varahenkilö käyvät yhdessä läpi, miltä uusi pyyntö näyttää ja miten siihen vastataan. He kokeilevat myös virheellisen numeron korjaamista sekä päällekkäisen pyynnön käsittelyä. Koulutuksen tuloksena jää lyhyt työohje, jonka seuraavakin työntekijä pystyy lukemaan.

Samalla sovitaan, kuka päivittää palvelutiedot ja kuka voi keskeyttää pilotin. Henkilöstöltä kerätään kysymykset, joita suunnittelussa ei huomattu. Esimerkiksi yrityksen lomaviikko voi muuttaa takaisinsoiton aikataulua. Tällainen muutos kuuluu myös botin käyttämään ohjeeseen, ei vain toimiston seinäkalenteriin.

Päivät 6–14: testistä valvottuun käyttöön

Toinen viikko alkaa testipuheluilla, ei koko puhelinliikenteen siirtämisellä. Testit tehdään sovitulla numerolla ja keksityillä asiakastiedoilla. Jokaisesta tapauksesta kirjataan odotettu lopputulos sekä havaittu tulos. Tallennuksen tarkastaja katsoo tehtävän työjonosta; botin sujuva loppulause ei ole todiste onnistumisesta.

Päivät 6–8: myös epäonnistumiset testataan

Testilistalla on tavallinen palvelukysymys ja takaisinsoittopyyntö, mutta myös puuttuva tieto, asiakkaan keskeytys ja pyyntö päästä ihmiselle. Mukana on puhelu, jossa asiakas vaihtaa takaisinsoittonumeroa kesken keskustelun. Testaaja puhuu välillä nopeasti ja tarkistaa, pystyykö botti korjaamaan väärin ymmärretyn asian.

Tekniset virheet testataan erikseen. Mitä tapahtuu, jos tehtäväjono ei vastaa? Entä jos työntekijän numero on varattu? Puhelun siirtäminen ei saa muodostaa silmukkaa, jossa sama soitto palaa botille uudelleen. Kun tallennusta ei voida vahvistaa, asiakkaalle kerrotaan epäonnistumisesta ja tarjotaan yrityksen hyväksymä vaihtoehtoinen yhteydenottotapa.

Tässä esimerkissä käyttöönoton estävä virhe on kadonnut pyyntö, väärä vastaanottaja tai tallennuksen onnistumista koskeva väärä vahvistus. Myös sitovan hinnan keksiminen pysäyttää siirtymisen tuotantoon. Puheen pieni tyylivirhe käsitellään eri tavalla, jos se ei muuta viestin sisältöä eikä estä asiointia.

Testausta voi tukea myös käytetyn alustan työkaluilla. Esimerkiksi ElevenLabsin testausohje erottaa keskustelun lopputuloksen, seuraavan vastauksen ja työkalukutsun tarkistamisen. Tämä auttaa jäsentämään testilistan. Simulaation läpäisy ei silti korvaa yrityksen oman puheluohjauksen ja tehtäväjonon kokeilemista.

Päivät 9–10: rajattu puheluliikenne

Kun testit on hyväksytty, yritys ohjaa botille vain ennalta sovitun osan puheluista. Se voi olla esimerkiksi tavalliseen numeroon tulevien vastaamattomien puheluiden jatko-ohjaus rajattuina aikoina. Tarkka toteutus riippuu yrityksen puhelinratkaisusta. Ohjaus ja sen purkaminen kokeillaan ennen asiakasliikenteen avaamista.

Nimetty työntekijä tarkistaa pilotin pyynnöt tavallista tiheämmin ja vertaa niitä sovittuun työnkulkuun. Hän kirjaa virheet samaan havaintolistaan. Jos asiakas joutuu kertomaan asiansa kahdesti, tarkistetaan, puuttuuko yhteenvedosta tietoja vai eikö vastaanottaja löydä sitä työjonosta.

Päivät 11–14: korjaukset ja jatkopäätös

Loppuviikolla korjataan havaittuja puutteita. Jos botti kysyy tarpeettomasti sähköpostiosoitetta, kysymys poistetaan. Jos yhteenveto jättää työn kannalta olennaisen tiedon pois, sen rakennetta täsmennetään. Muutetut kohdat testataan uudelleen, myös niiden virhepolut. Aikataulua ei suojella jättämällä tarkistusta väliin.

Neljäntenätoista päivänä tehdään päätös jatkosta. Vaihtoehtoina ovat pilotin jatkaminen samalla rajauksella, laajentaminen tai palautuminen aiempaan puheluohjaukseen. Kahden viikon tavoitteen täyttyminen tarkoittaa tässä toimivaa, valvottua ensimmäistä versiota. Se ei tarkoita, että kaikkien puheluiden automatisointi olisi valmis.

Mitä pk-yrityksen AI-puhelinpalvelusta mitataan?

Esimerkin yritys seuraa ensin sitä, päätyykö yhteydenotto käsiteltäväksi. Mittarin nimittäjä kirjataan näkyviin: verrataanko onnistuneita pyyntöjä kaikkiin botille tulleisiin puheluihin vai vain niihin, joissa asiakas halusi takaisinsoiton? Nämä kertovat eri asioista. Keskeytyneitä puheluita ei poisteta aineistosta vain siksi, että tulos näyttäisi paremmalta.

Kuvitteellisessa testierässä tehdään 30 takaisinsoittopyyntöä. Niistä 27 sisältää ensimmäisellä yrityksellä oikean numeron ja riittävän kuvauksen. Kahdessa numeron vahvistus epäonnistuu, ja yhdessä tallennuspalvelu on poissa käytöstä. Ensimmäisellä yrityksellä onnistuneiden osuus on silloin 27 / 30 eli 90 prosenttia. Tämä on laskentaesimerkki, ei palvelun laatulupaus tai hyväksymisraja.

Testierän virheet on silti selvitettävä, vaikka keskiarvo näyttäisi hyvältä. Tallennushäiriön hallittu ilmoitus on eri asia kuin kadonnut pyyntö, josta asiakas saa onnistumisvahvistuksen. Tulosta kannattaa tarkastella virhetyypeittäin. Pieni otos auttaa löytämään ongelmia, mutta siitä ei voi päätellä luotettavasti harvinaisten virheiden yleisyyttä.

Työajan säästö mitataan koko tehtävästä

Työnjohtaja voi käyttää vähemmän aikaa tietojen kysymiseen mutta enemmän aikaa puutteellisten yhteenvetojen korjaamiseen. Siksi seurataan myös pyynnön tarkastukseen, takaisinsoittoon ja korjauksiin käytettyä aikaa. Botin hoitaman puhelun kesto ei yksin kerro yrityksen säästöstä.

Vertailujakson pitää muistuttaa pilotin jaksoa. Lomaviikon puhelumäärää ei kannata verrata kiireiseen sesonkiin ja tulkita eroa automaation vaikutukseksi. Yritys merkitsee poikkeavat päivät muistiin ja kerää lisää havaintoja, jos kahden viikon aineisto jää pieneksi. Pilotti voi olla teknisesti onnistunut, vaikka taloudellisesta hyödystä ei vielä olisi riittävästi tietoa.

Asiakkaan kokemusta kysytään mahdollisuuksien mukaan suoraan. Lyhyt kysymys siitä, saiko hän asiansa hoidettua, kertoo eri asian kuin tekninen loki. Jos asiakas odotti vahvistettua huoltoaikaa mutta sai vain takaisinsoittopyynnön, keskustelun rajaus on ollut epäselvä, vaikka tallennus olisi onnistunut. Silloin korjataan botin sanamuotoja eikä tilastoida puhelua automaattisesti onnistuneeksi.

Työntekijän palaute täydentää mittareita. Hän voi huomata, että asiakkaan kuvaus on sanasta sanaan oikein mutta asian kiireellisyys jää epäselväksi. Ratkaisu voi olla yksi lisäkysymys tai selkeämpi siirto ihmiselle. Uutta kysymystä ei kuitenkaan lisätä jokaiseen puheluun varmuuden vuoksi, vaan vain tilanteisiin, joissa vastaus vaikuttaa seuraavaan työvaiheeseen.

Mitä pilotista pitää jäädä yritykselle?

Jatkokehitystä varten talteen jää hyväksytty palveluohje, testitapaukset tuloksineen ja luettelo avoimista virheistä. Lisäksi dokumentoidaan puheluohjaus, käyttöoikeudet sekä tapa poistaa tarpeettomat tiedot. Henkilötietojen käsittelyn ehdot ja vastuut selvitetään ennen asiakasliikennettä; tämä esimerkki ei ole niiden oikeudellinen arvio.

Yritys tarvitsee myös kustannusten erittelyn. Aloitustyö, käyttöön perustuvat maksut, ylläpito ja henkilöstön oma tarkastustyö erotetaan toisistaan. Halpa puheluminuutti ei ratkaise kokonaisuutta, jos jokainen pyyntö pitää kirjoittaa uudelleen. Lisää käyttöönoton rajaamisesta voit lukea AI-puhelinpalvelun käyttöönotto-oppaasta.

Yhteenveto: kahdessa viikossa ensimmäinen toimiva rajaus

Pk-yrityksen ensimmäinen AI-puhelinpalvelu voi olla varsin pieni: hyväksytyt vastaukset, luotettava takaisinsoittopyyntö ja reitti ihmiselle. Tässä suunnitteluesimerkissä kahden viikon työ kohdistuu niiden toteuttamiseen ja testaamiseen. Vaativammat integraatiot, puuttuvat palvelutiedot tai keskeneräiset vastuut siirtävät aikataulua.

Ennen aloittamista yrityksen kannattaa nimetä pilotin omistaja ja valita puhelutyyppi, jonka lopputuloksen voi nähdä omassa työjonossa. Sen jälkeen määritellään, millä havainnoilla kokeilua jatketaan ja milloin puheluohjaus palautetaan ennalleen. Näin päätös ei jää sen varaan, kuulostaako botti esittelypuhelussa vakuuttavalta.

Haluatko rajata vastaavan pilotin oman yrityksesi puheluihin? Tutustu Aisterin puhe-AI-palveluun tai ota yhteyttä. Ensimmäisessä keskustelussa voidaan käydä läpi yksi puhelutyyppi, sen nykyinen käsittely ja se, mistä onnistuminen käytännössä nähtäisiin.