Älykkäät äänibotit IoT-ympäristöissä: IoT, AI ja puhe käytännössä

IoT, AI ja puhe kohtaavat käytännössä silloin, kun asiakas kysyy puhelimessa jotakin, jonka vastaus löytyy laitteesta. Onko ilmanvaihtokone yhteydessä verkkoon? Milloin lämpötila on viimeksi mitattu? Onko huollon ilmoittama häiriö edelleen päällä? Älykkäät äänibotit IoT-ympäristöissä voivat hakea nämä tiedot keskustelun aikana ja kertoa ne ymmärrettävästi.

Pelkkä puhuva käyttöliittymä ei kuitenkaan tee laitepalvelusta toimivaa. Jos botti lukee eilisen mittauksen nykytilanteena tai ilmoittaa laitteen käynnistyneen pelkän lähetetyn käskyn perusteella, sujuva ääni peittää virheen. Siksi ensimmäinen suunnittelukysymys koskee tietoa: mitä laitteesta todella tiedetään juuri nyt?

Tässä oppaassa käymme läpi sopivia käyttökohteita, tiedon kulun laitteelta puheluun sekä rajatun pilotin toteutuksen. Esimerkit ovat kuvitteellisia suunnittelutilanteita, eivät Aisterin asiakastuloksia. Lähtökohtana on yrityksen puhelinpalvelu, jossa puhe-AI tukee asiakkaan tai huoltotyöntekijän asiointia olemassa olevan IoT-järjestelmän rinnalla.

IoT, AI ja puhe: mitä äänibotti oikeastaan tekee?

IoT tarkoittaa tässä verkkoon kytkettyjä laitteita, jotka välittävät esimerkiksi mittauksia, tilatietoja tai hälytyksiä. Äänibotti tulkitsee soittajan kysymyksen, pyytää tarvittavan tiedon taustajärjestelmästä ja muodostaa vastauksen. Laitteen anturi mittaa lämpötilan; kielimallin tehtävä on auttaa ihmistä saamaan mittauksesta tarvitsemansa tieto.

Puheluun ei välttämättä tarvita uutta älykaiutinta tai mikrofonia laitteen kylkeen. Asiakas voi soittaa tavalliseen palvelunumeroon. Botti käyttää hyväksyttyä integraatiota samalla tavoin kuin asiakaspalvelija käyttäisi huollon näkymää. Ratkaisun arvo syntyy siitä, ettei asiakkaan tarvitse etsiä sovellusta ja asiakaspalvelijan kopioida lukemia järjestelmästä toiseen.

Lukeminen, kirjaaminen ja ohjaaminen ovat eri tehtäviä

Ensimmäinen käyttötapa on tilatiedon lukeminen. Soittaja pyytää viimeisimmän mittauksen tai tiedon siitä, onko laite lähettänyt havaintoja. Tämä on usein järkevä aloitus, kun käyttöoikeudet ja laitteiden tunnisteet ovat kunnossa.

Toinen käyttötapa on asian kirjaaminen. Botti yhdistää asiakkaan kuvauksen ja saatavilla olevan laitetiedon huoltopyyntöön. Huollolle voidaan välittää esimerkiksi havaittu ääni, asiakkaan ilmoittama alkamisaika ja viimeisimmän yhteydenoton ajankohta. Pelkkä anturin lukema ei yleensä kerro, mitä asiakas on kokenut.

Kolmas käyttötapa on laitteen ohjaaminen. Siinä keskustelu johtaa fyysiseen muutokseen, kuten asetuksen säätöön. Ohjaus vaatii erikseen määritellyt oikeudet, sallitut arvot ja vahvistuksen lopputuloksesta. Se kannattaa arvioida omana projektinaan, vaikka tiedon lukeminen olisi jo saatu toimimaan.

Yksinkertainen raja auttaa hankinnassa: ensimmäisessä pilotissa botti saa lukea valittuja tietoja ja tehdä huoltopyynnön, mutta sillä ei ole laitteen ohjausoikeuksia. Rajauksen pitää näkyä rajapinnan oikeuksissa asti. Pelkkä keskusteluohje ei riitä.

Missä älykkäät äänibotit IoT-ympäristöissä auttavat?

Kiinteistöhuolto: asiakkaan havainto ja anturitieto samaan pyyntöön

Kuvitellaan toimistokiinteistön yhteyshenkilö, joka soittaa kylmästä neuvottelutilasta. Botti varmistaa kiinteistön ja tilan, tarkistaa soittajan oikeuden tietoihin ja hakee viimeisimmän huonelämpötilan aikaleimoineen. Sen jälkeen se kysyy, koskeeko ongelma vain kyseistä tilaa vai muitakin huoneita.

Hyvä vastaus voisi olla: "Neuvottelutilan viimeisin mittaus on 18 astetta kello 9.10. Teen ilmoituksen huollolle. Onko tila ollut kylmä koko aamun?" Mittaus ei yksin kerro syytä, joten botti ei päättele lämmityslaitteen rikkoutuneen. Se kirjaa havainnon ja mittauksen erikseen.

Jos mittaus on vanha, vastaus muuttuu: "Viimeisin tieto on eilisillalta, joten en pysty vahvistamaan nykyistä lämpötilaa." Asiakas tietää heti, mitä palvelu pystyy tekemään. Lisätietoa puhelun vastaanotosta löytyy Aisterin puhe-AI-palvelusta.

Laitetoimittajan tuki: oikea laite ennen vian selvitystä

Yritysasiakas voi omistaa kymmeniä samanlaisia laitteita eri toimipisteissä. Tuen ensimmäinen tehtävä on löytää oikea laite. Äänibotti voi pyytää toimipisteen ja lyhyen laitetunnuksen sekä lukea tunnistetun kohteen takaisin ennen tietojen hakua.

Kun kohde on varmistettu, botti tarkistaa sallitut perustiedot: viimeisin yhteys, ilmoitettu virhekoodi ja avoin huoltopyyntö. Se ei arvaa virhekoodin merkitystä, vaan käyttää hyväksyttyä ohjeistusta. Jos koodille ei löydy ohjetta, asia siirtyy tuelle alkuperäisen koodin kanssa.

Tällainen esikäsittely voi vähentää työntekijän tiedonhakua. Säästö pitää silti mitata. Jos asiakas joutuu toistamaan pitkän sarjanumeron neljä kertaa, käsittely ei välttämättä nopeudu. Tunnistamiseen kannattaa tarjota myös muu yrityksen hyväksymä tapa, esimerkiksi kirjautuneesta palvelusta käynnistetty yhteydenotto.

Huoltotyöntekijän tilannekysely kentällä

Kentällä työntekijä voi tarvita tiedon laitteen viimeisimmästä hälytyksestä ilman kannettavan tietokoneen avaamista. Puhekäyttöliittymä voi palvella tätä rajattua tarvetta, jos työympäristö sallii turvallisen puhelun ja tiedon kuulemisen.

Meluisa konehuone on silti eri asia kuin hiljainen toimisto. Testaa oikeat laitenimet, taustamelu ja puhelinyhteys. Jos käyttö vaatii jatkuvaa korjaamista, tekstinäkymä tai skannattava laitetunniste voi olla parempi. Puhetta ei kannata lisätä työvaiheeseen vain siksi, että se on mahdollista.

Näin IoT, AI ja puhe yhdistetään samaan palveluun

Toimiva tiedonkulku alkaa laitetunnuksesta. Yrityksellä pitää olla luotettava yhteys asiakkaan, toimipisteen ja laitteen välillä. Laitteen vapaamuotoinen lempinimi ei yksin riitä kohteen valintaan, jos samoja nimiä käytetään eri rakennuksissa.

Puhepalvelun ja IoT-alustan väliin kannattaa tehdä rajattu palvelurajapinta. Se palauttaa vain kyseisen tehtävän tarvitsemat tiedot. Botti ei tarvitse pääsyä koko laitekannan hallintaan vastatakseen yhteen lämpötilakysymykseen.

Tiedonhakupyyntö voi edetä esimerkiksi näin:

• Soittajan käyttöoikeus ja kohde tarkistetaan yrityksen hyväksymällä tavalla.
• Botti valitsee sallitun toiminnon, kuten viimeisimmän mittauksen haun.
• Rajapinta tarkistaa käyttöoikeuden uudelleen ja hakee tiedon IoT-alustasta.
• Vastauksessa kulkevat mittaus, yksikkö, aikaleima ja tieto mahdollisesta virheestä.
• Botti kertoo tuloksen tai ohjaa asian eteenpäin, jos tieto ei riitä.

Tässä työnjaossa kielimalli auttaa keskustelussa. Varsinaiset oikeustarkistukset ja sallitut toiminnot toteutetaan ohjelmallisesti taustapalvelussa. Näin puhelussa esitetty pyyntö ei itsessään laajenna botin valtuuksia.

Tiedon ikä kuuluu vastaukseen

Määritä jokaiselle tietotyypille, kuinka vanhaa havaintoa voidaan käyttää. Sisälämpötilan tilannekysely ja nopeasti muuttuvan tuotantolaitteen tila eivät tarvitse samaa tuoreusrajaa. Raja on palvelukohtainen päätös, joka sovitaan prosessin omistajan kanssa.

Myös puuttuva tieto tarvitsee oman vastauksensa. Nolla, tyhjä kenttä ja epäonnistunut haku ovat eri asioita. Jos taustapalvelu palauttaa virheen, botin ei pidä täyttää aukkoa uskottavalta kuulostavalla arvolla. Käytännöllinen vastaus on: "Laitetiedon haku ei nyt onnistu. Voin kirjata huoltopyynnön kuvauksesi perusteella."

Lähetetty pyyntö ei vielä ole toteutunut muutos

AWS:n Device Shadow -dokumentaatio erottaa tavoitellun tilan, laitteen ilmoittaman tilan ja niiden välisen eron. Nämä ovat palvelussa nimeltään desired, reported ja delta. Erottelu havainnollistaa, miksi asetuksen lähettäminen ja sen toteutuminen pitää käsitellä erikseen. AWS:n kuvaus laitetilan rakenteesta.

Jos myöhempään toteutukseen lisätään ohjausta, asiakas saa ensin vahvistuksen pyynnön vastaanotosta. Toteutumisesta kerrotaan vasta, kun järjestelmästä saadaan siihen riittävä vahvistus. Aikakatkaisulle tarvitaan oma käsittely: samaa käskyä ei lähetetä sokkona uudelleen, jos ensimmäisen pyynnön tulos on epäselvä.

Käyttöoikeudet ja poikkeustilanteet suunnitellaan ennen pilottia

Laiteympäristössä virheellinen vastaus voi johtaa väärään huoltotoimeen. Siksi käyttöoikeuksia ei kannata jättää projektin loppuun. NISTin IoT-tietoturvan perusmalli käsittelee muun muassa laitteiden tunnistamista, tiedon suojaamista, rajapintojen käytön rajaamista ja ohjelmistopäivityksiä. Se on hyödyllinen tarkistusrunko myös puhepalveluun liitettävän laitteen arviointiin. NISTin IoT-laitteiden tekniset tietoturvaominaisuudet.

Käytännön suunnittelussa kannattaa aloittaa asiakasrajasta. Yhden yrityksen käyttäjä ei saa kuulla toisen yrityksen laitetietoja, vaikka hän osaisi arvata laitetunnuksen. Käyttöoikeuden pitää kohdistua sekä toimintoon että kohteeseen. Myöskään soittajan numeroa ei pidä yksin tulkita todisteeksi oikeudesta tehdä muutoksia.

Vahvistus tarkoittaa täsmällistä toistoa

Jos palvelu myöhemmin sallii rajattuja asetusten muutoksia, vahvistuspyynnössä kerrotaan laite, nykyinen asetus ja pyydetty uusi asetus. Epämääräinen "haluatko jatkaa?" ei auta käyttäjää huomaamaan väärää kohdetta. Sallittu muutosalue tarkistetaan taustajärjestelmässä riippumatta siitä, mitä keskustelussa sanotaan.

Turvallisuuteen vaikuttavien toimintojen, kuten suojauksien ohittamisen, ei tule kuulua yleisen äänibotin tehtäviin. Laitteen omat turvajärjestelmät ja hyväksytyt huoltomenettelyt säilyvät käytössä. Puhepalvelu voi välittää havainnon vastuuhenkilölle, mutta se ei korvaa laitteen turvallisuuslogiikkaa.

Siirto ihmiselle on osa normaalia palvelua

Sopikaa siirto ainakin tilanteisiin, joissa kohde jää epäselväksi, soittaja pyytää ihmistä tai havaittu ongelma ei kuulu botin ohjeistukseen. Siirron mukana kulkevat vahvistettu kohde, asiakkaan kuvaus, haettu tieto aikaleimoineen ja jo tehdyt toimet. Työntekijän pitää erottaa toisistaan asiakkaan kertoma asia ja järjestelmästä vahvistettu tieto.

Lokeihin tarvitaan riittävästi tapahtumatietoa virheen selvittämiseksi, mutta kaikkea keskustelua ei tarvitse kopioida jokaiseen järjestelmään. Määritä etukäteen, mitä puhepalveluun, huoltotikettiin ja tekniseen lokiin tallennetaan, kuka tietoja käyttää ja milloin ne poistetaan. Näin sama asia ei jää tarpeettomasti moneen paikkaan.

Rajaa pilotti yhteen kysymykseen ja mittaa koko työvaihe

Hyvä ensimmäinen tavoite on konkreettinen: "Asiakas saa yhden laiteryhmän viimeisimmän tilatiedon ja voi jättää siihen liittyvän huoltopyynnön." Yhden laiteryhmän rajaus pitää tunnisteet, tietosisällöt ja poikkeukset hallittavina. Samalla näkee, löytyykö käyttötavalle oikeasti kysyntää.

Aloita kokoamalla todellisia, asianmukaisesti käsiteltyjä esimerkkikysymyksiä asiakaspalvelusta. Mukaan tarvitaan myös epäselviä tapauksia, ei vain siististi muotoiltuja lauseita. "Se alakerran laite vilkuttaa taas" on uskottavampi testi kuin täydellinen mallikysymys, jossa kaikki tunnisteet ovat valmiina.

Ensin testataan virheet

Testiaineistoon kannattaa sisällyttää väärä laitetunnus, vanha mittaus, katkennut yhteys, puuttuva käyttöoikeus ja saman pyynnön toistuminen. Kokeile myös, mitä tapahtuu, kun soittaja korjaa kohteen kesken puhelun. Botin on hylättävä väärään kohteeseen liittyvät päätelmät ennen jatkamista.

Huoltopyynnön luonnissa toisto on tavallinen tilanne: puhelu voi katketa juuri tallennuksen jälkeen. Toteutukseen tarvitaan keino tunnistaa jo tehty pyyntö, jotta uusintayritys ei synnytä kahta työtehtävää. Samalla asiakkaalle pitää pystyä kertomaan, syntyikö pyyntö vai jäikö asia kesken.

Hyväksymiskriteerit sovitaan ennen testiä. Esimerkiksi väärän asiakkaan tietojen palautuminen keskeyttää pilotin, kun taas tarpeeton täsmennyskysymys voi johtaa keskusteluohjeen korjaukseen. Näitä ei pidä laskea samaan virheluokkaan.

Laske työaika, älä vain botin vastaamia puheluita

Seuraa, kuinka moni tilannekysely ratkeaa oikealla tiedolla, kuinka usein tarvitaan ihmistä ja paljonko jälkikorjausta syntyy. Mittaa koko käsittelyaika asiakkaan yhteydenotosta valmiiseen kirjaukseen. Lyhyt puhelu ei ole onnistuminen, jos huolto joutuu myöhemmin selvittämään kohteen uudelleen.

Kuvitteellisessa laskelmassa kuukaudessa tulee 200 sopivaa tilannekyselyä. Jos 120 kyselystä poistuu kolme minuuttia työntekijän tiedonhakua, bruttosäästö on kuusi tuntia. Jos laadunvalvontaan ja korjauksiin kuluu kaksi tuntia, jäljelle jää neljä tuntia ennen muita ylläpitotöitä. Tämä on laskentamalli, ei lupaus saavutettavasta säästöstä.

Kustannusvertailuun kuuluvat puhelujen lisäksi integraation rakentaminen, laitekannan tietojen ylläpito ja muutostilanteiden testaus. Jos laiterekisteri on puutteellinen, sen korjaaminen voi olla pilotin suurin työ. Se kannattaa tietää ennen palvelun tilaamista.

Aloita luotettavasta tilatiedosta

Älykkäät äänibotit IoT-ympäristöissä ovat käyttökelpoisia silloin, kun ne lyhentävät matkaa asiakkaan kysymyksestä oikeaan laitetietoon. Ensimmäiseksi kannattaa ratkaista kohteen tunnistus, tiedon tuoreus ja huoltopyynnön välitys. Laitteen ohjaaminen voidaan arvioida myöhemmin erillisenä laajennuksena.

Ennen pilotin käynnistämistä pitäisi pystyä vastaamaan kahteen kysymykseen: minkä asian botti saa hoitaa loppuun, ja mitä tapahtuu, kun tieto ei riitä? Jos vastaukset ovat selvät, toteutusta on helpompi testata ja sen hyötyä mitata.

Jos haluat arvioida puhepalvelun liittämistä yrityksesi laitetietoon, ota yhteyttä Aisteriin. Keskustelun pohjaksi riittävät kuvaus yhdestä yleisestä puhelutilanteesta ja tieto siitä, missä laitteen tilatiedot ovat saatavilla.