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.

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.