Case-esimerkki: kuljetusyrityksen AI-puhelinpalvelu ja 500 puhelua päivässä

Kuljetusyrityksen AI-puhelinpalvelua tarvitaan etenkin aamulla, kun asiakkaat kyselevät toimituksistaan ja ajojärjestelijä yrittää samalla saada autot matkaan. Viisisataa puhelua päivässä kuulostaa kapasiteettiongelmalta. Ensin pitää kuitenkin selvittää, mitä soittajat tarvitsevat: lähetyksen viimeisimmän tilatiedon, uuden noudon vai ihmisen ratkaisemaan poikkeuksen.

Tässä case-esimerkissä suunnitellaan 500 päivittäistä puhelua vastaanottavan kuljetusyrityksen palvelu. Yritys ja puhelujakauma ovat kuvitteellisia. Myös käsittelyajat ja laskelman tulokset ovat oletuksia, eivät Aisterin asiakkaalta mitattuja säästöjä tai lupaus automaation suorituskyvystä.

Tavoite on näyttää, mitä tällainen palvelu vaatisi ja millä ehdoilla siitä olisi hyötyä. Puhelimeen vastaaminen on vasta alku. Asiakkaan pitää saada paikkansapitävä tieto tai asiansa sellaisen työntekijän käsiteltäväksi, joka pystyy tekemään päätöksen.

Kuljetusyrityksen AI-puhelinpalvelu alkaa puheluiden jaottelusta

Kuvitteellinen yritys kuljettaa kappaletavaraa yritysasiakkaille. Asiakaspalvelu ja ajojärjestely palvelevat kymmenen tunnin ajan päivässä. Oletetaan, että puheluita tulee 500 ja että kaikki saadaan lähtötilanteessa käsiteltyä. Näin laskelma vertaa samaa työmäärää molemmissa malleissa. Vastaamattomien puheluiden taloudellista arvoa ei tarvitse arvailla.

Jaetaan päivän yhteydenotot suunnittelua varten näin:

• 220 puhelua koskee lähetyksen tilaa tai toimitusajankohtaa.
• 100 puhelussa pyydetään noutoa tai muutosta aiempaan tilaukseen.
• 80 puhelua liittyy viiveeseen, vahinkoon tai epäonnistuneeseen toimitukseen.
• 60 puhelussa kysytään palvelualueesta, aukioloajasta tai asiointiohjeesta.
• 40 puhelua koskee hinnoittelua, laskutusta tai muuta selvitettävää asiaa.

Jaottelu on esimerkki siitä, mitä puhelulokista kannattaa selvittää. Oman yrityksen jakauma voi olla aivan toinen. Pelkkä puhelun otsikko ei myöskään kerro, onko asia helppo: toimitusaikakysely voi muuttua reklamaatioksi, kun asiakas kertoo työmaan seisovan odottamassa lähetystä.

Mitkä asiat annetaan ensimmäiseen pilottiin?

Rajaisin aluksi automaation yleisiin palvelutietoihin ja lähetysseurantaan, jossa tiedon lähde on yksiselitteinen. Noutopyyntöjä voidaan kerätä luonnoksiksi, mutta kuljetuksen vahvistaminen edellyttää erillistä kapasiteetin ja ehtojen tarkistusta. Vahingot, korvausvaatimukset ja kiireelliset toimitusmuutokset ohjataan sovitulle työntekijälle.

Jokaiselle puhelutyypille kirjoitetaan konkreettinen onnistumisehto. Seurantapuhelussa onnistuminen tarkoittaa, että asiakas saa oikean lähetyksen hyväksytyn tilatiedon ja ymmärtää, kuinka tuore tieto on. Noutopyynnössä onnistuminen voi tarkoittaa vain tietojen kirjaamista ja vastaanottokuittausta. Sitä ei pidä raportoida vahvistettuna noutona.

Yleisempää työnjakoa käsittelee oppaamme logistiikan ja kuljetusyritysten AI-puhelinpalvelusta. Tässä esimerkissä ratkaiseva rajaus on, että ajojärjestelijä säilyttää päätösvallan poikkeustilanteissa.

Miten 500 puhelua päivässä mitoitetaan?

Viisisataa puhelua kymmenessä tunnissa tarkoittaa keskimäärin 50 puhelua tunnissa. Jos yhden puhelun kesto on oletuksena kolme minuuttia, samanaikaisia puheluita on keskimäärin 2,5. Tulos saadaan kertomalla tuntikohtainen puhelumäärä kolmella minuutilla ja jakamalla 60:llä.

Tästä ei seuraa, että kolme puhelukanavaa riittäisi. Keskiarvo peittää alleen aamun ruuhkan, pitkät selvittelyt ja tilanteet, joissa asiakas odottaa siirtoa ihmiselle. Jos tunnin aikana saapuu 120 kolmen minuutin puhelua, keskimääräinen samanaikaisuus on jo kuusi. Hetkellinen tarve voi olla suurempi.

Mitoituksen pohjaksi kerätään saapumiset esimerkiksi viidentoista minuutin jaksoissa sekä puheluiden kestot. Mukaan otetaan tavallisten päivien lisäksi häiriöpäivä, jolloin saman viivästyksen vuoksi soittaa monta asiakasta. Näillä tiedoilla testataan, paljonko samanaikaisia puheluita tarvitaan valittuun palvelutasoon.

Puhekanava on vain yksi kapasiteettiraja

Vaikka AI-palvelu vastaanottaisi riittävän monta puhelua, kuljetusjärjestelmän tietohaku voi hidastua. Yksi puhelu saattaa sisältää useita hakuja: lähetyksen tunnistus, viimeisin tapahtuma ja toimitusajan tarkistus. Myös puhelinsiirto ja tehtävän kirjaaminen tarvitsevat toimivan yhteyden.

DHL:n Shipment Tracking - Unified -rajapinnan dokumentaatio havainnollistaa asiaa: siinä kuvattu aloitustaso on tarkoitettu kehitykseen, ei tuotantokäyttöön, ja suurempaa kutsukiintiötä haetaan erikseen. Tämä ei tarkoita, että esimerkkimme käyttäisi DHL:ää. Se näyttää, miksi rajapinnan olemassaolo ja riittävä käyttöoikeus ovat eri asioita.

Suunnitelmaan tarvitaan vastaus myös siihen, mitä tapahtuu kapasiteetin loppuessa. Voidaanko puhelu ohjata ihmisten jonoon, tarjota takaisinsoittoa tai kertoa häiriöstä? Takaisinsoittoa ei luvata tiettyyn kellonaikaan, ellei vastaanottavalla tiimillä ole mahdollisuutta pitää lupausta. Ylikuormituksen toimintamalli testataan ennen käyttöönottoa, ei ensimmäisen myöhästyneen runkokuljetuksen aikana.

Kuljetusyrityksen AI-puhelinpalvelu tarvitsee tuoreen tilatiedon

Seurantakyselyn kulku kannattaa pitää lyhyenä. Palvelu kertoo olevansa tekoälyavustaja, kysyy lähetyksen tunnisteen ja tekee yrityksen määrittelemän tarkistuksen ennen lähetystietojen kertomista. Pelkkää soittajan numeroa ei tässä toteutuksessa pidetä riittävänä perusteena luovuttaa asiakaskohtaisia tietoja.

Tunniste toistetaan tarvittaessa osissa. Jos puheesta tunnistettu numero ei täsmää, tarjotaan vaihtoehto, kuten näppäily tai siirto työntekijälle. Asiakkaan ei kuulu toistaa samaa pitkää rahtikirjanumeroa viittä kertaa. Yritys päättää etukäteen, kuinka monta epäonnistunutta yritystä sallitaan ennen muuta palvelutapaa.

Tapahtuma, arvio ja lupaus ovat eri tietoja

DHL:n samassa rajapintakuvauksessa lähetyksen tapahtumat aikaleimoineen ja arvioitu toimitusaika ovat erillisiä tietoja. Arvioidun toimitusajan saatavuus riippuu palvelusta ja tuotteesta. Saman erottelun kannattaa näkyä puhepalvelun suunnittelussa riippumatta siitä, minkä kuljetusjärjestelmän tietoja käytetään.

Jos järjestelmä kertoo lähetyksen saapuneen terminaaliin kello 7.20, avustaja voi kertoa tämän tapahtuman. Se ei saa päätellä pelkästä terminaalimerkinnästä, että toimitus saapuu asiakkaalle puoleenpäivään mennessä. Mahdollinen toimitusarvio kerrotaan arviona ja vain siihen tarkoitetusta tietokentästä.

Puhe voisi kuulostaa tältä: "Viimeisin kirjattu tapahtuma on saapuminen terminaaliin tänään kello 7.20. Toimitusaika-arviota ei tällä hetkellä ole. Voin välittää tarkistuspyynnön asiakaspalveluun." Sanamuoto ei ratkaise viivästystä, mutta asiakas kuulee, mitä tiedetään ja mitä seuraavaksi tehdään.

Vanhentunutta tietoa ei kaunistella

Yritys määrittelee kullekin tiedolle käyttöehdot: mistä se haetaan, mikä aikaleima vastaukseen liitetään ja milloin tarvitaan ihmisen tarkistus. Kaikelle tiedolle ei sovi sama vanhenemisraja. Eilinen terminaalitapahtuma voi olla lähetyksen uusin oikea tapahtuma, mutta eilinen toimitusarvio ei välttämättä enää kuvaa tämän päivän tilannetta.

Rajapinnan virhe, tuntematon tilakoodi ja puuttuva lähetys käsitellään erikseen. Hakuhäiriöstä ei tehdä johtopäätöstä, että lähetys olisi kadonnut. Jos tietoa ei saada, palvelu sanoo sen ja tarjoaa sovitun jatkon. Pelkkä sujuva ääni ei korjaa puuttuvaa tietoa.

Myös noutopyynnön kirjaamisessa tarvitaan varmistus. Jos yhteys katkeaa tallennuksen jälkeen, samaa pyyntöä ei saa luoda uudelleen jokaisella yrityksellä. Tallennus sidotaan yksilöivään pyyntötunnisteeseen, ja onnistuminen tarkistetaan ennen asiakkaalle annettavaa kuittausta. Kirjauskuittaus kertoo pyynnön vastaanottamisesta, ei vielä auton lähettämisestä.

Paljonko ihmistyötä laskentaesimerkissä jää?

Oletetaan lähtötilanteessa, että jokaiseen puheluun kuluu kolme minuuttia keskustelua ja yksi minuutti jälkikirjausta. Päivän työmäärä on silloin 500 × 4 minuuttia eli 2 000 minuuttia, yhteensä 33 tuntia 20 minuuttia. Tämä on tiimin yhteenlaskettua työtä, ei yhden työntekijän päivä.

Automaatiomalliin tarvitaan erilliset oletukset. Tässä laskelmassa 200 puhelua ratkeaa avustajan avulla, 220 siirtyy ihmiselle hyödyllisen yhteenvedon kanssa ja 80 ohjataan suoraan työntekijälle. Ratkaistujen 200 puhelun oletetaan koostuvan 160 seurantakyselystä ja 40 yleisestä palvelukysymyksestä. Luvut eivät ole arvio alan keskimääräisestä automaatioasteesta.

Lasketaan jäljelle jäävä työ näin:

• 220 siirrettyä puhelua vie ihmiseltä keskimäärin kolme minuuttia jälkitöineen: 660 minuuttia.
• 80 suoraan ohjattua puhelua vie keskimäärin neljä minuuttia: 320 minuuttia.
• Laaduntarkistukseen, korjauksiin ja palvelun ylläpitoon varataan yhteensä 80 minuuttia päivässä.

Ihmistyötä kertyy 1 060 minuuttia eli 17 tuntia 40 minuuttia. Ero lähtötilanteeseen on 940 minuuttia, siis 15 tuntia 40 minuuttia päivässä. Laskelmassa hyöty syntyy sekä ratkaistuista rutiineista että oletuksesta, että yhteenveto lyhentää siirrettyjen puheluiden käsittelyä.

Yhteenvedon hyöty pitää mitata. Jos työntekijä joutuu korjaamaan yhteenvedon tai kysymään kaiken uudelleen, minuutin hyötyä ei synny. Oletetaan vaihtoehtoisesti, että 220 siirrettyä puhelua viekin neljä minuuttia, 80 muuta puhelua edelleen neljä minuuttia ja valvontaan kuluu 160 minuuttia. Ihmistyötä jää silloin 1 360 minuuttia. Erotus lähtötilanteeseen pienenee 640 minuuttiin eli 10 tuntiin 40 minuuttiin.

Vapautunut aika ei ole sama kuin rahasäästö

Kumpikaan laskelma ei vielä osoita kannattavuutta. Palvelun kustannuksiin kuuluvat käyttöönotto, integraatiot, puhelinliikenne, AI-käyttö ja jatkuva ylläpito. Ihmiselle siirretty puhelu voi aiheuttaa sekä automaation että työntekijän kustannuksia. Samoin epäonnistunut puhelu voi synnyttää uuden yhteydenoton.

Työajan väheneminen kannattaa yhdistää todelliseen käyttötarkoitukseen: tarvitaanko vähemmän ylityötä, saadaanko kasvava puhelumäärä hoidettua nykyisellä tiimillä vai jääkö ajojärjestelylle enemmän keskeytyksetöntä aikaa? Ellei työvuoro tai muu kustannus muutu, palkkameno ei alene samassa suhteessa kuin laskennalliset käsittelyminuutit.

Kirjaisin pilottiin myös tilanteet, joissa hyöty jää saavuttamatta. Jos asiakkaat eivät löydä lähetysnumeroa, merkittävä osa seurantapuheluista siirtyy edelleen ihmiselle. Jos toimitusarviot puuttuvat, AI voi kertoa tapahtuman oikein mutta asiakkaan varsinainen kysymys jää auki. Tällainen puhelu ei kuulu ratkaistuihin vain siksi, että avustaja antoi vastauksen.

Poikkeuspuhelulle tarvitaan vastaanottaja ja seuranta

Asiakas ilmoittaa, että toimitusosoite muuttui, vaikka auto on jo matkalla. Avustaja kerää yrityksen ohjeistamat tiedot ja siirtää asian ajojärjestelyyn. Se ei vahvista uutta osoitetta, toimitusaikaa tai lisämaksua ennen toimivaltaisen työntekijän päätöstä. Sama periaate koskee vaurioitunutta lähetystä ja asiakkaan pyytämää hyvitystä.

Työntekijälle välitetään lyhyt yhteenveto: mitä asiakas pyytää, mikä lähetys on kyseessä, mitä järjestelmästä saatiin selville ja mitä jäi varmistamatta. Yhteenveto erottaa asiakkaan kertoman tiedon järjestelmästä tarkistetusta tiedosta. Näin esimerkiksi asiakkaan arvioitu purkuaika ei muutu huomaamatta vahvistetuksi varaukseksi.

Jos siirto ei onnistu, asia kirjataan vastuutiimin työjonoon. Asiakkaalle kerrotaan todellinen seuraava vaihe. Yhteydenoton vastaanottoa seurataan, sillä siirtopainikkeen painaminen ei todista, että joku sai asian hoitaakseen. Puheluiden reitityksen oppaassa käsitellään tarkemmin ohjauksen suunnittelua.

Näin rajaisin pilotin

Ennen asiakaspuheluita kokeillaan testilähetyksillä ainakin väärää tunnistetta, puuttuvaa toimitusarviota, vanhaa tapahtumaa, rajapinnan katkoa ja epäonnistunutta puhelinsiirtoa. Mukana pitää olla myös meluisa puhelu ja asiakas, joka pyytää suoraan ihmistä. Yrityksen oma asiakaspalvelu arvioi, olisiko vastaus käyttökelpoinen oikeassa tilanteessa.

Ensimmäinen asiakaspilotti rajataan yhteen numeroon tai pieneen osuuteen puheluista. Työntekijä voi tarvittaessa palauttaa puhelut tavalliseen asiakaspalveluun. Pilotissa seurataan vähintään oikeellisuutta, siirtojen onnistumista, asiakkaan uusintayhteydenottoja ja ihmisten todellisia käsittelyminuutteja. Mittareille sovitaan tavoitetaso ja keskeytysehto ennen aloitusta.

Ratkaisuasteen seurannassa määritellään, mitä sama asia tarkoittaa. Lähetysnumero auttaa erottamaan uuden toimituskysymyksen saman ongelman uusintasoitosta. Esimerkiksi kahden vuorokauden seurantajakso voidaan valita pilotin lähtökohdaksi, mutta sen sopivuus riippuu kuljetuksen kestosta. Pelkkä puhelun päättyminen ilman siirtoa ei riitä onnistumisen mittariksi.

Pilottia ei laajenneta vain siksi, että AI vastaa nopeasti. Laajentamisen perusteeksi tarvitaan näyttö siitä, että tieto pitää paikkansa, poikkeukset päätyvät oikeille henkilöille ja kokonaiskuorma vähenee. Käyttöönoton vaiheita voi täydentää AI-puhelinpalvelun pilotointioppaalla.

Mitä kuljetusyrityksen kannattaa tehdä seuraavaksi?

Viidensadan päivittäisen puhelun palvelu kannattaa suunnitella puhelusyiden ja ruuhkahuippujen perusteella. Tässä esimerkissä automaation tehtäväksi rajattiin tarkistetun tiedon kertominen ja asioiden valmistelu. Ihmisille jäivät päätökset, poikkeukset ja ne puhelut, joita avustaja ei pysty ratkaisemaan.

Aloita oman puheluliikenteen otoksesta. Merkitse jokaiselle puhelulle yhteydenoton syy, tarvittu tietolähde, ihmistyön määrä ja lopputulos. Selvitä sen jälkeen kuljetusjärjestelmän käyttöoikeudet ja testaa yksi selvästi rajattu puhelutyyppi. Laske hyöty oman yrityksesi tiedoilla.

Jos haluat arvioida toteutusta Aisterin kanssa, ota yhteyttä. Keskusteluun riittävät aluksi puhelumäärät, tavallisimmat yhteydenottosyyt ja käytössä olevan kuljetusjärjestelmän nimi. Niiden perusteella voidaan rajata, mitä pilotissa kannattaa mitata.