Julkaistu
Lukuaika
9 minuuttia
Artikkeli tiivistettynä
Asiakaspalvelujärjestelmän demon saa pystyyn viikonlopussa, mutta pinnan alla on mm. päällekkäisen vastaamisen esto, yhteydenoton tilat, reititys, sähköpostin toimitettavuus ja tekoälyn suojarakenteet, joita ei huomaa ennen kuin ne puuttuvat. Ero valmiiseen alustaan näkyy siinä päivässä kun tarvitset jotain uutta: se on asetus, ei uusi rakennusprojekti.
Chat-widgetin saa nettisivun nurkkaan yhdellä promptilla Claude Codella. Sen jälkeen kytkee sen kielimalliin rajapinnan kautta ja syöttää sisällöksi omat nettisivut, se vastaa asiakkaiden kysymyksiin yllättävän hyvin. Sama temppu toimii sähköpostille. Viikonloppu ohi ja asiakaspalvelu on pystyssä, vai onko sittenkään?
Näin pitkälle pääsee kevyesti ja kyse ei olekaan siitä onnistuuko se. Kyse on siitä, mitä tapahtuu puolen vuoden päästä, kun asiakaspalvelijoita on kahdeksan, yhteydenottoja tulee tuhat kuukaudessa ja joku kysyy miksi yksi niistä jäi vastaamatta.
Ero valmiiseen alustaan tiivistyy yhteen asiaan. Valmiissa järjestelmässä uusi tarve on asetus, jonka käyt kytkemässä päälle ja joka on valmiiksi kiinni kaikessa muussa. Omassa järjestelmässä jokainen uusi tarve on uusi rakennusprojekti, ja niitä tulee jatkuvasti lisää.
"Rakennan vain ne osat joita tarvitsen"
Ajatus kuulostaa järkevältä. Valmiissa asiakaspalvelujärjestelmässä on satoja ominaisuuksia, joista te ette todennäköisesti tarvitse kaikkia, ja ne jotka tarvitsette todennäköisesti pystytte rakentamaan itse.
Väite nojaa kuitenkin oletukseen, että ominaisuudet ovat toisistaan irrallisia palikoita, joista voi poimia haluamansa. Otetaan helpoin mahdollinen esimerkki: yhteinen saapuneet-kansio. Aluksi riittää, että sähköpostit tulevat yhteen näkymään. Yhtenä päivänä kuitenkin kaksi työntekijää vastaa samaan viestiin ja asiakas saa kaksi eri vastausta, joten tarvitaan tapa estää päällekkäinen vastaaminen (agent collision detection). Seuraavaksi huomataan, että osa viesteistä unohtuu kun kukaan ei ota niistä vastuuta, joten jokaiselle yhteydenotolle tarvitaan tila (ticket state model) ja tieto siitä kuka siitä vastaa. Sitten asiakkaat alkavat valittaa hitaudesta, joten tarvitaan vasteaikojen seuranta (SLA) aukioloaikoineen ja pyhäpäivineen.
Kolmessa kuukaudessa "tarvitsen vain inboxin" on ohjelmistoprojekti, eikä yksikään näistä lisäyksistä ollut listalla silloin kun työ aloitettiin.
Lue tästä, mitä hyvä asiakaspalvelujärjestelmä osaa ja millä kriteereillä sellainen valitaan.
Mitä siellä pinnan alla on
Käyttöliittymä on se osa, jonka tekoäly rakentaa sinulle minuuteissa. Loput ovat näkymätöntä logiikkaa, jota kukaan ei näe ennen kuin se puuttuu.
Nämä tulevat vastaan ensimmäisten kuukausien aikana:
Päällekkäisen vastaamisen esto: kaksi asiakaspalvelijaa ei vastaa samaan viestiin yhtä aikaa
Yhteydenoton tilat: avoin, odottaa asiakasta, siirretty, ratkaistu ja säännöt niiden välillä
Omistajuus: jokaisella yhteydenotolla on yksi omistaja
Reititys: kenelle yhteydenotto menee ja millä perusteella
Vasteaikojen seuranta aukioloaikoineen, pyhäpäivineen ja aikavyöhykkeineen
Käyttöoikeudet: mikä tieto näkyy asiakkaalle, mikä vain tietylle tiimille
Ja nämä vasta sitten, kun niitä oikeasti tarvitaan:
Tapahtumaloki siitä kuka muutti mitä ja milloin, eli ainoa työkalu selvittää miksi automaatio teki sen minkä teki
Saman asiakkaan tunnistaminen kolmesta sähköpostiosoitteesta, puhelinnumerosta ja chat-sessiosta
GDPR-poisto, joka anonymisoi asiakkaan mutta säilyttää tilastot
Sisällön pysyvä poistaminen, kun asiakaspalvelija liittää tikettiin vahingossa kortin numeron
Liitteiden virusskannaus ja tiedostotyyppirajoitukset
Oma jono roskapostille ja tuntemattomille lähettäjille
Webhookien uudelleenyritykset, kun vastaanottava järjestelmä on hetken alhaalla
Kaksi näistä kannattaa avata, koska ne yllättävät useimmin.
Sähköpostin toimitettavuus. Vastausten pitää mennä perille, ja se vaatii SPF-, DKIM- ja DMARC-asetukset omalle domainille sekä palautuvien viestien käsittelyn. Tässä kohtaa rakennelma kaatuu näkymättömästi: jos vastauksenne päätyvät asiakkaan roskapostikansioon, järjestelmä ei ilmoita siitä mitenkään. Se vain lakkaa toimimasta, ja te huomaatte asian siitä että asiakkaat lakkaavat vastaamasta.
Reititys. Kun asiakaspalvelijoita on yksi, reititystä ei tarvita. Kun heitä on kahdeksan ja he ovat eri aikavyöhykkeillä ja osaavat eri asioita, kysymys "kenelle tämä menee" ei ole enää yksi if-lause. Kuormaan, osaamiseen ja asiakkaan prioriteettiin perustuva jako on oma algoritminsa, ja sen pitää olla muutettavissa ilman että joku koodaa.
Nämä ovat kaikki järjestelmän sisäisiä asioita. Ulospäin näkyvin puute on kuitenkin toinen, eikä se ole ominaisuus vaan seuraus: kun järjestelmä ei ole kytketty muihin järjestelmiin, asiakaspalvelija tekee kytkennän itse. Hän pitää auki verkkokauppaa ja laskutusta, etsii saman asiakkaan molemmista erikseen ja kopioi tilausnumeron manuaalisesti. Tämä ei näy missään mittarissa ennen kuin katsotaan käsittelyaikoja ja siihen kuluu juuri se aika joka piti säästää.
Kielimalli on hyödyke
Tekoälypuolella kannattaa sanoa yksi asia ääneen heti. Kielimalli on hyödyke (commodity). Sama malli on kaikkien saatavilla samasta rajapinnasta ja se paranee itsestään riippumatta siitä mitä te teette. Varsinainen järjestelmä on kaikki se, mitä mallin ympärille rakennetaan.
Sen huomaa nopeasti. Hakutoiminnon saa pystyyn tunnissa: AI-agentti lukee dokumentteja, muodostaa niistä vastauksen ja hoitaa yleiset kysymykset. Sitten widget avataan julkisesti.
Kielimalli tuottaa tarvittaessa vastauksen, jota ei ole missään: asiakkaalle luvataan palautusoikeus jota teillä ei ole, tai takuuaika joka ei pidä paikkaansa. Samaan aikaan kuka tahansa voi kirjoittaa chattiin ohjeita, joilla mallin oma ohjeistus yritetään ohittaa (prompt injection) ja saada sen puhumaan aivan muusta kuin teidän palvelustanne.
Näiden estäminen on oma osaamisalueensa. Suojarakenteet (guardrails) tarkoittavat käytännössä sitä, että vastaukset rajataan tiettyihin aiheisiin, ne tarkistetaan ennen lähetystä ja poikkeamat päätyvät jonnekin mistä joku ne huomaa. Valmiissa alustassa tämä kerros on olemassa ja sitä kehitetään jatkuvasti. Itse rakennetussa se on yksi projekti lisää ja sen puuttuminen paljastuu vasta silloin kun asiakas on jo saanut väärän vastauksen ja vetoaa siihen.
Seuraava kerros on data. Se tulee vastaan siinä kohtaa, kun asiakas kysyy jotain itseään koskevaa. Missä tilaukseni on, voinko vaihtaa toimitusosoitteen, haluan palauttaa tämän tuotteen. Näihin ei vastata dokumenteista vaan verkkokaupasta tai toiminnanohjauksesta ja osaan pitää myös lähettää tietoa takaisin: palautus käynnistetään, osoite päivitetään jne. Jokainen tällainen yhteys tuo mukanaan omat kysymyksensä siitä, miten asiakas tunnistetaan ennen kuin hänen tietonsa näytetään ja mitä tapahtuu kun kutsu epäonnistuu kesken keskustelun.
Lue tästä, miten AI-agentin integraatiot taustajärjestelmiin rakennetaan Zendeskissä.
Kun tekoäly ei osaa vastata, sen on osattava eskaloida asia ihmiselle hallitusti. Eskaloidessa, itse rakennettu ratkaisu lähettää yleensä sähköposti-ilmoituksen, jonka liitteenä on chat-loki. Asiakaspalvelija avaa sen eikä näe mitään muuta: ei asiakkaan aiempia yhteydenottoja, ei sitä että hän soitti viime viikolla samasta asiasta, eikä niitä tilaustietoja jotka AI-agentti ehti hakea. Asiakas kertoo asiansa uudestaan, mikä on juuri se kokemus jota koko järjestelmällä yritettiin välttää.
Kun tekoäly on erillinen palanen, myös raportointi katkeaa siirron hetkellä. Näette kuinka moni keskustelu siirtyi ihmiselle, mutta ette sitä miksi. Silloin ette myöskään tiedä, mitä AI-agentille kannattaisi seuraavaksi opettaa.
Kustannuspuolella on vielä yksi ero, joka näkyy vasta laskussa. Kun tekoäly pyörii suoraan mallintarjoajan rajapinnan päällä, maksatte tokeneista: lasku seuraa liikennettä eikä ratkaistuja asioita, eikä siinä ole kattoa. Roskaposti, botit ja epäonnistuneet keskustelut maksavat siinä missä ratkaistutkin. Ette myöskään päätä itse hinnoittelusta, käyttörajoista tai siitä kuinka kauan käyttämänne malli on olemassa, ja kun se poistuu käytöstä, ohjeistus ja testaus tehdään uudelleen. Valmiissa alustassa nämä ovat osa sovittua hintaa.
Lue tästä, mitä asiakaspalvelun automaatio kattaa ja mistä kannattaa aloittaa.
Ero näkyy siinä päivässä kun tarvitset jotain uutta
Kuvitellaan tilanne puolen vuoden päästä. Asiakkaat alkavat kysellä samoja asioita WhatsAppissa. Myynti haluaa nähdä palvelutiketit omassa näkymässään. Joku haluaa tietää, mitkä aiheet vievät eniten asiakaspalvelijoiden aikaa.
Valmiissa alustassa nämä ovat asetuksia. Kytket kanavan päälle, ja se tulee samaan näkymään, samaan reititykseen, samaan raportointiin ja saman AI-agentin ulottuville, koska ne on rakennettu valmiiksi toistensa päälle. Työ on iltapäivän mittainen.
Omassa järjestelmässä jokainen niistä on projekti. WhatsApp tarkoittaa uutta rajapintaa, uutta viestimuotoa ja uutta tunnistautumista, jotka pitää kytkeä olemassa olevaan tikettimalliin. Ja kun Meta muuttaa ehtojaan tai Google tiukentaa lähettäjien todennusvaatimuksia, se hajoaa ajankohtana jota ette itse valitse.
Tämä on se kustannus, joka jää alkuperäisestä laskelmasta pois. Rakentaminen ei ole kertaluontoinen kustannus vaan pysyvä. Joku teillä on jatkuvasti korjaamassa sitä, ja se joku on yleensä sama ihminen, jonka pitäisi kehittää teidän omaa tuotettanne.
Milloin itse tehty riittää
Joskus itsetehty "purkkaratkaisu" riittää, jos tarve on väliaikainen, yhteydenottoja tulee muutama päivässä, niitä hoitaa yksi ihminen eikä asiakas syötä järjestelmään mitään arkaluonteista. Tässä tapauksessa oma widget tai sähköpostien reititys ohjelma voi olla täysin järkevä ratkaisu. Sen rakentamiseen menee hetki ja sen voi heittää pois sitten kun se ei enää riitä.
Raja tulee vastaan kolmesta suunnasta: kun asiakaspalvelijoita on useampi kuin yksi, kun asiakas alkaa syöttää järjestelmään henkilötietoja, tai kun haluatte tietää miksi jokin meni niin kuin meni. Tietoturva kannattaa ottaa vakavasti jo ennen sitä. Tietoturvayhtiö Escape.techin tutkimus 1 400 vibe-koodatusta sovelluksesta löysi niistä 2 038 kriittistä haavoittuvuutta, yli 400 vuotanutta salaisuutta ja 175 tapausta, joissa henkilötietoja oli avoimesti saatavilla. Joukossa oli potilastietoja ja pankkitilinumeroita, ja kaikki löydökset olivat tuotannossa olevissa sovelluksissa.
On myös tilanteita, joissa oma järjestelmä ei ole valinta vaan lähtökohta. Terveydenhuollossa, finanssialalla ja osassa julkishallintoa sääntely tai asiakassopimukset voivat vaatia, että tiedot pysyvät omassa konesalissa tai tietyllä lainkäyttöalueella. Osa näistä vaatimuksista ratkeaa alustan omilla datan sijaintivaihtoehdoilla, mutta jos vaatimus on ettei data poistu omasta ympäristöstä lainkaan, SaaS-alusta ei ole vaihtoehto. Silloin kaikki tässä artikkelissa kuvattu työ pitää tehdä joka tapauksessa ja kannattaa vain tietää etukäteen mihin sitoutuu.
Kun se raja tulee vastaan, kysymys ei ole enää siitä pystyttekö rakentamaan tarvittavat osat. Kysymys on siitä, haluatteko rakentaa ne uudestaan joka kerta kun jotain muuttuu.
Mietitkö, kannattaako teidän rakentaa itse vai ottaa valmis alusta?
Oikea vastaus riippuu siitä, kuinka paljon te palvelette asiakkaita, missä kanavissa ja mihin kehitysresurssinne kannattaa suunnata. Joskus vastaus on kevyt oma ratkaisu, joskus valmis alusta, ja usein yhdistelmä jossa alusta hoitaa rungon ja te rakennatte päälle sen mikä on teille ominaista.
Zennius on sertifioitu Zendesk-kumppani, ja tiimimme jäsenet ovat olleet mukana yli sadassa Zendesk-AI käyttöönotossa.
Haluatko sparrata, mikä ratkaisu palvelisi juuri teitä? Varaa tästä maksuton keskustelu ja käydään tilanteenne läpi yhdessä.
Usein kysytyt kysymykset
Voiko asiakaspalvelujärjestelmän rakentaa itse tekoälyn avulla?
Toimivan näköisen version saa tehtyä nopeasti, ja se riittää pienellä volyymilla. Työ ei kuitenkaan lopu käyttöönottoon. Reititys, käyttöoikeudet, tapahtumaloki, sähköpostin toimitettavuus ja integraatiot vaativat jatkuvaa ylläpitoa, ja jokainen uusi tarve on oma rakennusprojektinsa.
Mikä itse rakennetussa asiakaspalvelujärjestelmässä hajoaa tyypillisesti ensimmäisenä?
Milloin itse tehty kevyt ratkaisu riittää asiakaspalveluun?
Miksi kielimalli itsessään ei ole kilpailuetu asiakaspalvelussa?
Voiko säännellyn toimialan asiakaspalvelun hoitaa valmiilla pilvialustalla?
