Webhook ja reaaliaikainen data — AI-puheluiden jälkikäsittely

Webhook on yksinkertainen idea: kun puhelussa tapahtuu jotain tärkeää, järjestelmä lähettää siitä tiedon toiseen järjestelmään heti. AI-puhelinpalvelussa tämä on usein ero mukavan demon ja oikean tuotantoprosessin välillä.

Ilman webhookeja puhelu jää helposti raporttiin. Joku katsoo sen myöhemmin, jos muistaa. Webhookin avulla puhelu voi luoda tiketin, päivittää CRM:n, lähettää Slack-ilmoituksen, varata ajan, käynnistää laskutusprosessin tai avata takaisinsoittotehtävän saman tien.

Reaaliaikainen data ei silti tarkoita, että kaikki pitää lähettää kaikkialle. Hyvä jälkikäsittely lähettää oikean tiedon oikeaan paikkaan ja jättää turhan kohinan pois.

Mitä webhook tekee AI-puhelussa?

Webhook on HTTP-kutsu, jonka AI-puhelinpalvelu lähettää sovittuun osoitteeseen. Se voi lähteä puhelun aikana tai puhelun päätyttyä.

Tyypillisiä tapahtumia ovat:

• puhelu alkoi
• asiakas tunnistettiin
• intentti tunnistettiin
• botti loi varauksen tai tiketin
• asiakas pyysi ihmistä
• puhelu päättyi
• transkriptio ja yhteenveto valmistuivat
• puhelussa havaittiin virhe tai riski

Vastaanottava järjestelmä voi olla oma backend, CRM, tikettijärjestelmä, automaatiotyökalu, data warehouse tai no-code-alusta kuten Zapier tai Make.

Teknisesti webhook on melko tylsä. Liiketoiminnallisesti se on hyödyllinen, koska se poistaa manuaalisen jälkikäsittelyn.

Puhelun jälkeen tarvitaan enemmän kuin transkriptio

Moni ajattelee ensin transkriptiota. Se on hyödyllinen, mutta harvoin riittävä. Jos CRM:ään tallentuu vain pitkä puheluteksti, ihminen joutuu edelleen lukemaan ja päättelemään.

Parempi webhook-data sisältää rakenteisen yhteenvedon:

• puhelun tunniste
• asiakkaan tunnistetiedot, jos ne on vahvistettu
• puhelun aihe
• lopputulos
• kerätyt kentät
• sovitut jatkotoimet
• kiireellisyys
• siirron syy, jos asia meni ihmiselle
• linkki transkriptioon tai nauhoitteeseen käyttöoikeuksien takana

Rakenteinen data tekee automaatiosta luotettavampaa. CRM ei tarvitse esseetä. Se tarvitsee oikeat kentät oikeisiin paikkoihin.

Esimerkiksi myyntiliidissä tärkeät kentät voivat olla yrityksen nimi, yhteyshenkilö, tarve, budjettiluokka, aikataulu ja suostumus yhteydenottoon. Huoltotapauksessa taas asiakkaan laite, ongelman kuvaus, kiireellisyys, sijainti ja toivottu aika.

Suunnittele tapahtumat prosessin mukaan

Huono webhook-suunnittelu alkaa kysymyksestä: mitä kaikkea dataa saamme ulos? Hyvä suunnittelu alkaa kysymyksestä: mitä seuraavaksi pitää tapahtua?

Jos puhelun lopputulos on ajanvaraus, webhookin pitää viedä tieto kalenteriin ja lähettää vahvistus. Jos lopputulos on reklamaatio, webhookin pitää luoda tiketti oikealla prioriteetilla. Jos lopputulos on kuuma liidi, myyjälle pitää syntyä tehtävä nopeasti.

Tee jokaiselle puhelutyypille jälkikäsittelykartta:

1. mikä tapahtuma syntyy 2. mikä järjestelmä vastaanottaa sen 3. mitä kenttiä tarvitaan 4. mikä on onnistunut lopputulos 5. mitä tehdään, jos vastaanottava järjestelmä ei vastaa

Viides kohta on se, joka usein unohtuu. Tuotannossa API:t ovat välillä hitaita, tokenit vanhenevat ja kenttämallit muuttuvat. Webhook-prosessin pitää selvitä tästä ilman, että asiakas jää ilmaan.

Reaaliaikainen vai puhelun jälkeinen käsittely?

Kaikkea ei tarvitse tehdä puhelun aikana. Osa tapahtumista kannattaa lähettää heti, osa vasta kun AI on tehnyt yhteenvedon.

Reaaliaikainen webhook sopii tilanteisiin, joissa toisesta järjestelmästä tarvitaan vastaus puhelun jatkamiseen. Esimerkiksi vapaat ajat, tilauksen tila, asiakkuuden tunnistus tai huollon saatavuus.

Puhelun jälkeinen webhook sopii raportointiin ja jatkotehtäviin. Esimerkiksi CRM-muistiinpano, tiketin luonti, Slack-kooste, myyntitehtävä tai analytiikkatapahtuma.

Näitä ei kannata sotkea. Jos kaikki tehdään reaaliajassa, puhelu hidastuu ja virheherkkyys kasvaa. Jos kaikki tehdään vasta lopussa, botti ei voi tehdä oikeita päätöksiä puhelun aikana.

Hyvä arkkitehtuuri erottaa puhelun aikana tarvittavat kriittiset kutsut ja puhelun jälkeen tehtävän rikastamisen.

Tietoturva: älä lähetä kaikkea varmuuden vuoksi

Webhookeissa houkutus on lähettää koko puhelun sisältö joka paikkaan. Se on huono tapa, erityisesti jos puheluissa käsitellään henkilötietoja.

Lähetä vain se tieto, jota vastaanottava järjestelmä tarvitsee. Jos Slack-ilmoitus kertoo vain, että uusi liidi tuli, siihen ei tarvitse laittaa koko transkriptiota. Jos CRM tarvitsee yhteyshenkilön ja yhteenvedon, se ei tarvitse nauhoitteen raakadataa.

Perusasiat pitää olla kunnossa:

• webhook allekirjoitetaan tai suojataan salaisella avaimella
• vastaanottaja validoi allekirjoituksen
• henkilötiedot minimoidaan
• lokit eivät tallenna arkaluonteista raakadataa turhaan
• epäonnistuneet lähetykset yritetään hallitusti uudelleen
• käyttöoikeudet transkriptioihin rajataan

Erityisen tärkeää on erottaa tekninen loki ja liiketoimintadata. Tekninen loki kertoo, onnistuiko lähetys. Sen ei pidä sisältää asiakkaan koko asiaa.

Idempotenssi estää tuplatyöt

Webhookit voivat joskus lähteä kahdesti. Verkko pätkii, vastaanottaja vastaa hitaasti tai lähettävä järjestelmä yrittää varmuuden vuoksi uudelleen. Jos vastaanottaja ei käsittele tätä, sama puhelu voi luoda kaksi tikettiä tai kaksi myyntitehtävää.

Siksi jokaisella tapahtumalla pitää olla tunniste. Vastaanottava järjestelmä tarkistaa, onko sama tapahtuma jo käsitelty. Jos on, se ei tee työtä uudelleen.

Tätä kutsutaan idempotenssiksi. Sana on ruma, mutta tuotannossa se säästää hermoja.

Hyvä tapahtumatunniste voi olla esimerkiksi puhelun ID ja tapahtuman tyyppi yhdessä. Ajanvaraus syntyy kerran. CRM-muistiinpano syntyy kerran. Uudelleenlähetys vain vahvistaa, että tieto meni perille.

Seuraa epäonnistumisia näkyvästi

Webhook on integraatio, ja integraatiot hajoavat välillä. Siksi epäonnistumisia ei saa piilottaa lokien pohjalle.

Tarvitaan näkymä, josta näkee:

• kuinka monta tapahtumaa lähti
• kuinka monta onnistui
• mitkä epäonnistuivat
• voiko ne yrittää uudelleen
• syntyikö asiakkaalle jatkotehtävä varapolussa

Jos webhook luo takaisinsoittopyynnön ja se epäonnistuu hiljaa, asiakas odottaa turhaan. Se on pahempi kuin se, ettei automaatiota olisi lainkaan.

Esimerkkipayload: mitä AI-puhelu voi lähettää?

Webhookin suunnittelu helpottuu, kun puhutaan konkreettisista kentistä. Tyypillinen puhelun päättymistapahtuma voi sisältää esimerkiksi puhelun ID:n, tapahtuman ajan, puhelun aiheen, asiakkaan vahvistetut yhteystiedot, yhteenvedon, jatkotoimen ja kiireellisyyden.

Tärkeää on erottaa havainto ja päätös. AI voi havaita, että asiakas kuulostaa turhautuneelta. Päätös voi olla, että tapaus merkitään kiireelliseksi ja siirretään ihmiselle. Molemmat voidaan tallentaa, mutta niitä ei pidä sekoittaa samaan tekstikenttään.

Hyvä payload on vakaa. Kentät eivät vaihda nimeä joka viikko. Jos jokin tieto puuttuu, se puuttuu selkeästi eikä piiloudu vapaaseen tekstiin. Tämä tekee vastaanottavasta automaatiosta helpomman testata.

Käytännössä kannattaa tehdä versioitu sopimus: call.completed.v1. Kun rakennetta muutetaan, tehdään uusi versio. Näin vanhat työnkulut eivät hajoa yllättäen.

Testaa webhookit erillisillä testitapahtumilla

Webhookeja ei pidä testata vain oikeilla puheluilla. Tarvitaan myös testitapahtumia, jotka voidaan lähettää uudelleen ilman asiakasta.

Tee vähintään nämä testit:

• onnistunut ajanvaraus
• liidi ilman sähköpostia
• reklamaatio korkealla prioriteetilla
• puhelu, jossa asiakas pyytää ihmistä
• epäonnistunut integraatiokutsu
• puuttuva pakollinen kenttä
• sama tapahtuma lähetetään kahdesti

Näillä nähdään, kestääkö vastaanottava järjestelmä normaalit ja huonot tilanteet. Testi kannattaa ajaa aina, kun CRM:n kenttiä, Zapier-työnkulkuja tai omaa backendia muutetaan.

Erilliset testitapahtumat ovat myös hyviä koulutuksessa. Myynti näkee, millainen liidi syntyy. Asiakaspalvelu näkee, millainen tiketti tulee. IT näkee, mikä tieto kulkee ja mikä ei.

Pidä raakadata ja operatiivinen data erillään

Puhelusta syntyy usein paljon dataa: ääni, transkriptio, AI:n sisäinen päättely, yhteenveto, tunnistetut kentät, järjestelmätoimet ja lokit. Kaikkea tätä ei pidä käsitellä samalla tavalla.

Operatiivinen data on sitä, jolla työ tehdään: asiakas pyysi takaisinsoittoa, aihe oli laskutus, kiireellisyys korkea, vastuutiimi talous. Raakadata on laajempi puhelusisältö. Se voi olla hyödyllinen auditointiin, mutta sitä ei tarvitse työntää jokaiseen automaatioon.

Tämä jako vähentää tietosuojariskiä ja tekee järjestelmistä siistimpiä. CRM:ään kirjataan yhteenveto ja jatkotoimi. Nauhoite säilytetään rajatussa paikassa, jos sitä ylipäätään säilytetään. Slackiin lähetetään vain se, mitä tiimi tarvitsee reagoidakseen.

Suunnittele uudelleenlähetys ja virhejono

Webhookin lähettäjä tarvitsee retry-logiikan. Vastaanottaja voi olla alhaalla, vastata liian hitaasti tai palauttaa virheen. Yksi epäonnistuminen ei saa kadottaa asiakkaan asiaa.

Hyvä malli on porrastettu uudelleenyritys. Esimerkiksi uusi yritys minuutin, viiden minuutin ja puolen tunnin päästä. Jos kaikki epäonnistuvat, tapahtuma menee virhejonoon, josta ihminen tai tekninen ylläpito näkee tilanteen.

Virhejonon pitää näyttää liiketoiminnalle ymmärrettävä tieto: mikä asiakas tai puhelu, mikä jatkotoimi jäi tekemättä ja voiko sen ajaa uudelleen. Pelkkä tekninen stack trace ei auta asiakaspalvelupäällikköä.

Tämä kuulostaa pieneltä reunalta, mutta tuotannossa juuri virhepolut ratkaisevat luottamuksen. Onnistuneet webhookit ovat näkymättömiä. Epäonnistuneet muistetaan.

Yhteenveto

Webhook tekee AI-puhelinpalvelusta osan yrityksen operatiivista järjestelmää. Puhelu ei jää irralliseksi keskusteluksi, vaan muuttuu rakenteiseksi tapahtumaksi: tiketti, varaus, CRM-päivitys, myyntitehtävä tai raportointirivi.

Hyvä toteutus lähtee prosessista, ei datatulvasta. Päätä mitä pitää tapahtua, lähetä vain tarvittava tieto, suojaa kutsut, estä tuplat ja seuraa epäonnistumisia.

Aisteri rakentaa webhookit ja reaaliaikaiset integraatiot niin, että AI-puhelut eivät jää transkriptioiksi. Jos haluat kartoittaa oman jälkikäsittelyketjun, ota yhteyttä: visa.valkonen@aisteri.fi.