Case: SaaS-yrityksen onboarding-puhelut automaattisesti

SaaS-yrityksen onboarding-puhelut voivat auttaa asiakasta tilanteessa, jossa tunnukset on luotu mutta ohjelmiston käyttö ei etene. Tervetuloviesti on lähtenyt, ohjekeskus löytyy ja sovellus näyttää aloituslistan. Silti ensimmäinen varsinainen työ jää tekemättä. Asiakas ei ehkä tiedä, mistä aloittaa, tai hän odottaa kollegaltaan yhtä puuttuvaa tietoa.

Tässä SaaS-onboardingin case-esimerkissä suunnitellaan automaattinen puhelu juuri tähän kohtaan. Esimerkki on kuvitteellinen, ei kuvaus Aisterin toteutuneesta asiakasprojektista. Puhelumäärät ja työaikalaskelma ovat oletuksia. Niiden tarkoitus on auttaa arvioimaan toteutusta, ei luvata aktivoinnin tai myynnin kasvua.

Kuvitellaan suomalainen B2B-ohjelmistoyritys, jonka palvelulla asiakkaat hallitsevat huoltotöitä. Uuden asiakasyrityksen pääkäyttäjän pitäisi perustaa ensimmäinen työkohde ja kutsua asentaja mukaan. Jos tämä jää kesken, koko tiimin aloitus viivästyy. Puhebotin tehtävä on selvittää este ja sopia yksi seuraava toimi. Puhelu ei korvaa tuotteen käytettävyyttä eikä ratkaise puuttuvaa integraatiota puhumalla.

SaaS-yrityksen onboarding-puhelut: rajaa yksi aloitusvaihe

Esimerkin yritys tarjoaa uuden asiakkaan pääkäyttäjälle mahdollisuuden pyytää lyhyt käyttöönottopuhelu. Asiakas valitsee sopivan ajankohdan ja saa tietää, että soittaja on tekoälyavustaja. Puhelut kohdistetaan tähän pyyntöön, eikä kaikkia kokeilutilin luoneita lisätä automaattisesti soittolistalle. Puhelutavan, henkilötietojen käsittelyn ja mahdollisen tallentamisen edellytykset selvitetään erikseen ennen toteutusta.

Rajaus tekee palvelusta myös helpommin mitattavan. Yritys tietää, mitä asiakas odottaa ja missä tehtävässä avustajan pitäisi auttaa. Jos asiakas haluaa vain kokeilla tuotetta rauhassa, puhelua ei tarvita. Jos hän pyytää aloitustapaamista asiantuntijan kanssa, bottipuhelua ei laiteta sen väliin ylimääräiseksi vaiheeksi.

Ensimmäinen hyöty pitää määritellä tuotteen kautta

Huoltotöiden hallinnassa pelkkä kirjautuminen on heikko onnistumisen mittari. Esimerkkituotteen ensimmäinen hyödyllinen tapahtuma on se, että pääkäyttäjä perustaa työkohteen ja asentaja näkee sen omassa näkymässään. Vasta silloin ohjelmisto on auttanut työn jakamisessa. Tuotetiimi määrittelee, mistä tapahtumista tämä voidaan luotettavasti havaita.

Puhebotille annetaan tätä tehtävää koskeva hyväksytty ohjeistus. Sen pitää tietää, mitä pääkäyttäjä voi tehdä itse, mitä oikeuksia asentaja tarvitsee ja mistä kutsun lähetys tarkistetaan. Ohjeet sidotaan käytössä olevaan tuoteversioon. Vanha valikkonimi on puhelimessa erityisen hankala: asiakas etsii sitä ruudulta, mutta avustaja ei näe, mitä hän näkee.

Jos ohjelmistossa on useita palvelupaketteja, myös niiden erot kuuluvat ohjeistukseen. Puhebotti ei saa neuvoa asiakasta ottamaan käyttöön ominaisuutta, joka puuttuu tämän paketista. Pilotissa rajataan siksi mukaan yksi paketti ja yksi käyttöönottopolku. Laajempaa työnjakoa käsittelemme hybridiasiakaspalvelun oppaassa.

Kysy esteestä, älä lue esittelyä

Puhelun alussa avustaja kertoo yrityksen nimen, oman roolinsa tekoälyavustajana ja yhteydenoton syyn. Sen jälkeen se varmistaa, sopiiko lyhyt keskustelu. Asiakkaan kiire ei ole vastaväite, joka pitäisi voittaa. Puhelu siirretään sovittuun aikaan tai päätetään asiakkaan toiveen mukaan.

Ensimmäinen varsinainen kysymys voisi olla: "Mihin kohtaan ensimmäisen työkohteen perustaminen jäi?" Asiakas saattaa tarvita käyttöohjeen, mutta yhtä hyvin hän voi odottaa kollegalta kohdeluetteloa. Jälkimmäisessä tilanteessa pidempi ohjelmistoesittely ei auta. Puhebotti kirjaa sovitun jatkon eikä selitä väkisin toimintoa, jonka asiakas jo osaa.

Käynnistä SaaS-yrityksen onboarding-puhelut oikeasta tapahtumasta

Puhelun käynnistys tarvitsee sekä asiakkaan pyynnön että ajantasaisen tiedon käyttöönotosta. Esimerkissä taustapalvelu tarkistaa ennen sovittua soittoa, onko asiakas jo saanut ensimmäisen työkohteen tiiminsä käyttöön. Jos tehtävä valmistui itsenäisesti, aloitusapua ei oleteta enää tarvittavan. Asiakkaalle sovitaan etukäteen, peruuntuuko tällainen puhelu vai muutetaanko sen tarkoitusta.

SaaS-yrityksen onboarding-puhelut tarvitsevat myös yhteisen näkymän asiakkaan muihin tukiasioihin. Jos ihminen selvittää jo samaa käyttöönoton estettä, automaattinen soitto voi sekoittaa sovitun työnjaon. Pilotissa avoin käyttöönottotukipyyntö ohjaa puhelun ensin nimetyn vastuuhenkilön tarkistettavaksi. Asiakkaan ei tarvitse kertoa samaa ongelmaa kahdelle eri auttajalle.

Sama tarkistus tehdään asiakkuuden tilasta. Suljettuun kokeiluun, poistettuun yhteyshenkilöön tai peruttuun puhelupyyntöön ei soiteta vanhan jonotiedon perusteella. Tarkistusten pitää tapahtua lähellä soittoa. Edellisen illan lista ei välttämättä vastaa aamun tilannetta.

Yksi pyyntö ei saa synnyttää kahta soittoa

Tuotteen tapahtumasta voidaan tehdä webhook-ilmoitus taustapalvelulle. Suunnittelussa varaudutaan siihen, että sama ilmoitus saapuu uudelleen tai tiedot saapuvat eri järjestyksessä. Esimerkiksi Stripen webhook-ohje käsittelee tapahtumien kaksoistoimituksia ja järjestysriippuvuuksia. Stripe on tässä tekninen vertailuesimerkki, ei vaatimus onboarding-ratkaisulle.

Soittopyynnölle annetaan yksilöllinen tunniste, ja sen käsittelytila tallennetaan. Uusi toimitus samalla tunnisteella ei saa käynnistää uutta puhelua. Pelkkä saapuneiden tapahtumien muistaminen ei kuitenkaan riitä, jos useampi eri tapahtuma voi tarkoittaa samaa asiakastarvetta. Siksi myös asiakasyrityksen ja käyttöönoton vaiheen perusteella estetään päällekkäiset avoimet soitot.

Jos puhelupalvelu ei vastaa käynnistyspyyntöön, järjestelmä tarkistaa pyynnön tilan ennen uusintaa. Verkkoyhteyden aikakatkaisu ei todista, ettei puhelu käynnistynyt. Muuten asiakas voi saada kaksi soittoa samalla hetkellä, vaikka molempien taustalla on näennäisesti siisti virheenkäsittely.

Kirjaa lopputulos, älä päättele sitä puheen sävystä

Puhelun päättyessä tallennetaan erikseen asiakkaan kertoma tilanne, sovittu toimenpide ja tuotteen vahvistama tapahtuma. "Teen sen iltapäivällä" on jatkosuunnitelma. Se ei tarkoita, että työkohde on jo perustettu. Käyttöönoton onnistuminen varmistetaan ohjelmiston tapahtumista sovitun seuranta-ajan kuluessa.

Myös tavoittamatta jääminen tarvitsee oman tilansa. Tässä pilotissa asiakkaan pyytämälle puhelulle voidaan sopia enintään yksi uusi yritys, mutta yritysmäärä päätetään palvelun yhteydessä eikä sitä kasvateta automaattisesti. Vastaajaan ei jätetä asiakkuuden yksityiskohtia. Yhteydenottojen lopettamispyyntö pysäyttää tulevat yritykset, myös jo jonossa olevat.

Näin puhelu auttaa ja siirtää vaikean asian ihmiselle

Pääkäyttäjä vastaa sovittuun puheluun. Hän kertoo luoneensa työkohteen mutta asentajan kutsun puuttuvan. Puhebotti varmistaa, että asiakas haluaa ohjeen kutsun lähettämiseen, ja käy työvaiheen läpi yksi askel kerrallaan. Jokaisen vaiheen jälkeen asiakkaalle jää aikaa tehdä asia ruudulla. Pitkä ohjeluettelo yhdellä puheenvuorolla on vaikea muistaa.

Jos asiakas sanoo, ettei näe neuvottua painiketta, avustaja tarkistaa hyväksytystä ohjeesta käyttöoikeuteen liittyvän selityksen. Se ei keksi uutta valikkopolkua. Jos syy jää epäselväksi, asia siirtyy tuotetuelle. Puhelun hyöty voi olla myös oikein rajattu tukipyyntö, vaikka asiakas ei saisi tehtävää valmiiksi saman keskustelun aikana.

Puhelimessa ei kerätä tunnuksia tai integraation salaisuuksia

Avustaja voi neuvoa, mistä ohjelmiston oma kirjautumisohje löytyy. Se ei pyydä salasanaa, kertakäyttöistä kirjautumiskoodia tai rajapinta-avainta ääneen. Jos käyttöönotto vaatii ulkoisen järjestelmän liittämistä, asiakas tekee tunnistautumisen kyseisen järjestelmän hyväksytyssä näkymässä. Puhebotti voi auttaa löytämään oikean ohjeen.

Asiakaskohtaisia tietoja ei lueta puhelimessa vain siksi, että vastaaja tietää yrityksen nimen. Toteutuksessa erotetaan yleinen opastus ja tilitietoja vaativa palvelu. Jälkimmäiseen tarvitaan yrityksen hyväksymä tunnistamistapa. Ensimmäinen pilotti voidaan rajata yleiseen opastukseen, jolloin avustajan ei tarvitse saada laajoja oikeuksia asiakastiliin.

Siirron pitää päätyä jonkun työlistalle

Jos ongelmana on esimerkiksi epäonnistuva tietojen tuonti, puhebotti ottaa tukipyynnön. Yhteenvetoon kirjataan asiakkaan tavoite, havaittu este ja jo kokeiltu ohje. Asiakkaan tulkinta ja järjestelmästä tarkistettu tieto erotetaan toisistaan: "asiakas kertoo kutsun epäonnistuvan" on eri asia kuin todettu palveluvirhe.

Tukipyynnölle tarvitaan omistaja ja yrityksen hyväksymä käsittelytavoite. Puhebotti kertoo asiakkaalle, mitä seuraavaksi tapahtuu, mutta ei lupaa korjausaikaa, jota kukaan ei ole vahvistanut. Jos tukijärjestelmä on poissa käytöstä, avustaja ei sano pyyntöä tallennetuksi. Epäonnistuminen tallennetaan valvottuun jatkokäsittelyyn ja asiakkaalle kerrotaan toimiva vaihtoehto yhteydenottoon.

Laske työmäärä ja mittaa todellinen käyttöönotto

Oletetaan, että yritys tekee kuukaudessa 100 asiakkaan pyytämää aloituspuhelua. Nykyinen työmäärä on keskimäärin 12 minuuttia yhteydenottoa kohti valmisteluineen ja kirjauksineen. Lähtötilanteessa työhön kuluu siis 1 200 minuuttia eli 20 tuntia. Nämä luvut ovat tämän esimerkin laskentaoletuksia.

Oletetaan seuraavaksi, että 60 asiakkaan asia hoituu automaattisen puhelun ja tuotteen ohjeiden avulla. Niihin kuluu henkilöstöltä keskimäärin kaksi minuuttia laadun tarkistusta. Jäljelle jäävät 40 asiaa vaativat kukin 15 minuuttia ihmistyötä, koska ne ovat tavallisia aloituskysymyksiä vaikeampia. Pilotin ylläpitoon ja virheiden selvittämiseen varataan neljä tuntia kuukaudessa.

Laskelma on silloin seuraava:

• Automaattisesti hoidettujen asioiden tarkistus: 60 × 2 minuuttia = 120 minuuttia.
• Ihmiselle siirtyvien asioiden käsittely: 40 × 15 minuuttia = 600 minuuttia.
• Ylläpito ja poikkeamien selvitys: 240 minuuttia.
• Henkilöstön kokonaistyö: 960 minuuttia eli 16 tuntia kuukaudessa.

Näillä oletuksilla aikaa vapautuu neljä tuntia kuukaudessa. Tulos on varsin maltillinen. Jos ylläpito vie kuusi tuntia neljän sijaan, hyöty pienenee kahteen tuntiin. Käyttöönoton kertatyö sekä puhelupalvelun ja integraatioiden kustannukset arvioidaan erikseen. Pelkkä 60 prosentin automaatio-osuus ei kerro hankinnan kannattavuutta.

Vertailuryhmä auttaa erottamaan puhelun vaikutuksen

Työajan rinnalla mitataan, valmistuiko asiakkaan ensimmäinen työtehtävä. Pilotissa voidaan verrata puhebotin ja henkilöstön hoitamia aloituspuheluja keskenään, kun asiakkaat ja tehtävät ovat riittävän samanlaisia. Jos halutaan selvittää puhelun lisäarvoa suhteessa pelkkään kirjalliseen opastukseen, vertailuasetelma suunnitellaan erikseen asiakkaalle annetut palvelulupaukset huomioiden.

Sovitaan etukäteen, missä ajassa onnistumista tarkastellaan. Esimerkkituotteessa voidaan seurata ensimmäisen yhteisen työkohteen valmistumista seitsemän päivän sisällä sekä käyttöä seuraavalla viikolla. Rekisteröitymisviikko, yrityksen koko ja käyttöönottotapa kirjataan, jotta poikkeuksellisen helppo asiakasjoukko ei näytä automaation saavutukselta.

Pienestä kokeilusta ei kannata julkaista suurta kasvuväitettä. Jos toisessa ryhmässä onnistuu 12 ja toisessa 10 asiakasta, havainto voi auttaa löytämään jatkokysymyksiä, mutta se ei yksin osoita pysyvää vaikutusta. Tarkastele myös tukipyyntöjä, uusintayhteydenottoja ja asiakkaiden halua käyttää puhelinapua uudelleen. Onnistunut puhelu tuntuu hyödylliseltä myös vastaanottajasta.

Testaa epäonnistumiset ennen asiakasnumeroihin soittamista

Testaa myös puhetta eri nopeuksilla ja taustamelussa. Asiakkaan korjaus, kuten "tarkoitin toista työkohdetta", pitää huomioida seuraavassa ohjeessa. Epäselvä vastaus johtaa tarkentavaan kysymykseen, ei arvaukseen. Näin ohjausta voidaan arvioida muutenkin kuin rauhallisessa esittelytilanteessa.

Testiaineistoon otetaan tavallisen ohjepuhelun lisäksi väärä numero, vastaaja, kesken keskustelun katkeava yhteys ja asiakas, joka pyytää lopettamaan. Lisäksi kokeillaan samaa webhookia kahdesti, jo valmistunutta käyttöönottoa ja tukijärjestelmän häiriötä. Testit tehdään omilla testitileillä ja numeroilla.

Yksi hyväksymisehto on, ettei sama pyyntö aiheuta päällekkäisiä soittoja. Toinen on, että asiakkaan kielto katkaisee jatkoyritykset. Myös tukipyynnön todellinen tallentuminen ja luvattujen käyttöohjeiden oikeellisuus tarkistetaan. Jos nämä eivät toimi, miellyttävä ääni ei tee palvelusta julkaisuvalmista. Laajempi valmistelurunko löytyy AI-puhelinpalvelun pilotointioppaasta.

Aloita yhdestä käyttöönoton esteestä

SaaS-yrityksen onboarding-puhelut kannattaa rakentaa sellaisen tehtävän ympärille, jonka valmistumisen voi havaita tuotteessa. Esimerkin tavoite oli saada ensimmäinen työkohde asentajan näkyviin. Silloin sekä puhelun sisältö että seuranta pysyvät konkreettisina. Jos puhelu paljastaa toistuvan käyttöliittymäongelman, korjaus kuuluu myös tuotetiimin työlistalle.

Valitse aluksi yksi asiakasryhmä, sovi puhelun tarkoitus ja nimeä henkilö, joka vastaa poikkeuksista. Kerää nykyinen työmäärä ennen pilotin aloittamista. Sen jälkeen voit arvioida, helpottiko automaatio asiakkaan aloitusta vai siirsikö se työtä vain toiseen kohtaan.

Haluatko selvittää, sopisiko puhe-AI oman tuotteesi käyttöönottoon? Ota yhteyttä Aisteriin ja kuvaa vaihe, johon asiakkaat tavallisesti pysähtyvät. Voit myös jättää tarpeen konfiguraattorissa. Ensimmäiseen keskusteluun riittävät nykyinen käyttöönottopolku ja arvio siitä, kuinka paljon sen tukemiseen kuluu aikaa.