Näin lisäsimme tekoälyavustajan SaaS-alustaan — rikkomatta sitä

Jokainen SaaS-tiimi, jonka kanssa keskustelemme, päätyy ennemmin tai myöhemmin sanomaan saman lauseen ääneen: "Meidän pitäisi laittaa tänne tekoälyavustaja." Joskus paine tulee hallitukselta, joskus kilpailijan lanseerauksesta, joskus se on aitoa. Mielenkiintoista ei ole koskaan itse idea — se on lähes kaikilla. Mielenkiintoista on kuilu tuon lauseen ja sellaisen ominaisuuden välillä, johon oikeat käyttäjät todella nojaavat. Tämä on tarina yhdestä tiimistä, joka ylitti kuilun, ja niistä vaatimattomista päätöksistä, jotka veivät heidät sinne.

Pieni huomautus ennen kuin aloitamme: olemme anonymisoineet asiakkaan ja pyöristäneet luvut. Kyseessä on pieni, kannattava B2B-SaaS-yritys — alle kaksikymmentä henkeä — joka myy työnkulkutyökalua operatiivisille tiimeille. Olemme muuttaneet yksityiskohtia riittävästi, ettet tunnista heitä, mutta projektin muoto on tismalleen sellainen kuin se tapahtui. Luvut ovat havainnollistavia, eivät auditoituja; näytämme mieluummin kaavan kuin kaunistelemme kaaviota.

Kirjoitamme tämän auki, koska projekti on lähes täydellinen esimerkki siitä, miten nämä asiat todella etenevät. Se ei mennyt niin kuin aloitusdiat lupasivat. Se meni paremmin — mutta vain siksi, että olimme valmiita poistamaan ensimmäisen version.

Tilanne: kaksi ongelmaa yhdessä valeasussa

Kun perustaja otti ensimmäistä kertaa yhteyttä, pyyntö oli yksinkertainen: "Haluamme tekoäly-chatbotin sovellukseen." Siitä useimmat projektit alkavat, ja siihen useimmat myös hiljaa kompastuvat. "Tekoäly-chatbot" ei ole tavoite, se on muoto. Joten ensimmäinen tehtävämme oli selvittää, mitä ongelmaa chatbotin oli tarkoitus ratkaista — ja oliko se edes yksi ongelma.

Ei ollut. Tuon yhden pyynnön alla oli kaksi täysin erilaista kipupistettä. Ensimmäinen oli tukikuorma: kaksihenkinen asiakaspalvelutiimi hukkui toistuviin tukipyyntöihin — "miten vien tämän tiedot ulos", "missä on tuon asetus", "miksi raporttini ei ajautunut". Karkeasti 60 % saapuvista pyynnöistä oli kysymyksiä, joihin vastaus löytyi jo jostakin heidän ohjeistaan. Toinen kipupiste oli hiljaisempi ja kalliimpi: aktivointi. Heidän tuotteessaan oli aidosti tehokas ominaisuus, joka oli haudattu kolmen klikkauksen syvyyteen ja jota lähes kukaan ei löytänyt itse. Käyttäjät, jotka löysivät sen, pysyivät vuosia. Ne, jotka eivät löytäneet, lähtivät ensimmäisten kahden kuukauden aikana.

Sama valeasu, kaksi ongelmaa. Ja ne vetivät eri suuntiin. Tukibotti haluaa torjua kysymyksiä ja väistyä tieltä. Aktivointiavustaja haluaa aloittaa keskusteluja ja tuupata ihmisiä kohti asioita, joita he eivät osanneet kysyä. Jos olisimme rakentaneet "tekoäly-chatbotin" erottamatta näitä, olisimme rakentaneet jotakin, joka hoitaa molemmat tehtävät huonosti.

Rajaaminen johonkin, jonka pystyimme saattamaan valmiiksi

Kahden ongelman edessä houkutus on rakentaa suurenmoinen avustaja, joka hoitaa molemmat heti alusta. Puhuimme tiimin siitä pois. Ei siksi, että visio olisi ollut väärä, vaan siksi, että kuuden kuukauden "kaikki hoitava avustaja" on juuri sellainen projekti, joka valmistuu myöhässä, jää latteaksi ja saa kaikki hermostumaan tekoälystä seuraavaksi kahdeksi vuodeksi.

Joten valitsimme yhden. Valitsimme ensin tukipyyntöjen torjunnan, kolmesta tylsästä mutta ratkaisevasta syystä. Sillä oli selkeä, mitattava tavoite — tukipyyntöjen määrä. Se käytti sisältöä, joka oli jo olemassa — heidän ohjeensa ja menneet tukipyynnöt. Ja jos se olisi alisuoriutunut, haitta olisi ollut pieni: käyttäjä, joka ei saanut hyvää vastausta, teki yksinkertaisesti sen mitä ennenkin ja avasi tukipyynnön. Pieni riski, nopea palaute, rehellinen mittari. Se on hyvä ensimmäinen tekoälyominaisuus, joka kerta.

Aktivointiavustaja ei kadonnut — pysäköimme sen paperille selkeällä merkinnällä: vaihe kaksi, kun hakukerros on todistettu. Tuo yksittäinen päätös luultavasti pelasti projektin. Se antoi tiimille maaliviivan, jonka he todella ehtivät saavuttaa viikoissa vuosineljännesten sijaan.

Ensimmäinen prototyyppi, jonka rakensimme — ja poistimme

Tässä on se osa, jonka useimmat esimerkkitapaukset jättävät pois. Ensimmäinen toimiva prototyyppimme oli, kohteliaasti sanottuna, ei hyvä. Teimme itsestäänselvyyden: kytkimme tuotteen ohjeartikkelit suureen kielimalliin, lisäsimme chat-laatikon ja annoimme käyttäjien kysellä. Demossa se näytti taianomaiselta. Oikeassa testauksessa se hajosi hyvin tietyllä ja hyvin opettavaisella tavalla.

Malli oli itsevarman väärässä. Kun siltä kysyttiin asetuksesta, joka oli nimetty uudelleen puoli vuotta aiemmin, se keksi iloisesti vanhan valikkopolun. Kun siltä kysyttiin korkeamman tason paketin ominaisuudesta, se selitti sen käytön — asiakkaalle, joka ei päässyt siihen käsiksi. Jokainen vastaus kuulosti arvovaltaiselta, mikä teki vääristä vastauksista pahempia kuin ei vastausta lainkaan. Tukibotti, joka valehtelee kohteliaasti, ei vähennä tukipyyntöjä; se synnyttää vihaisempia.

Olisimme voineet paikata sen kehotteiden virittelyllä. Sen sijaan teimme jotakin, joka tuntui askeleelta taaksepäin ja osoittautui koko pelin ytimeksi: heitimme ensimmäisen prototyypin pois ja rakensimme sen uudelleen tiukan säännön ympärille — avustaja saa vastata vain lähteistä, jotka se voi mainita, ja muuten sen on sanottava "en tiedä".

Mitä oikeasti rakensimme

Julkaistu versio oli tarkoituksella vaatimaton yrittämässään ja tiukka käytöksessään. Konepellin alla se oli hakuun perustuva avustaja: kun käyttäjä kysyi jotakin, järjestelmä haki ensin kuratoidusta, ajantasaisesta tietopankista, ja pyysi sitten mallia vastaamaan vain löytämänsä perusteella, linkki takaisin lähteeseen mukanaan. Ei lähdettä, ei itsevarmaa vastausta — vain siisti luovutus ihmiselle.

Kolme suunnitteluvalintaa teki suurimman työn, eikä yksikään niistä ole jännittävä. Se on juuri pointti — tylsät valinnat ovat yleensä ne, jotka ratkaisevat, luotetaanko tekoälyominaisuuteen vai kytketäänkö se hiljaa pois.

Ankkurointi ennen nokkeluutta

Jokainen vastaus oli sidottu todelliseen, ajantasaiseen dokumenttiin. Käytimme enemmän aikaa tietopankin siivoamiseen ja jäsentämiseen kuin mallin virittelyyn. Vaatimatonta, ja ylivoimaisesti projektin vaikuttavinta työtä. Keskinkertainen malli erinomaisen, hyvin ylläpidetyn sisällön päällä voittaa loistavan mallin vanhentuneen sotkun päällä.

Sulava luovutus

Kun avustaja ei ollut varma, se ei arvannut. Se sanoi niin ja tarjosi yhden klikkauksen reitin ihmiselle — kantaen keskustelun kontekstin mukanaan, jotta käyttäjän ei koskaan tarvinnut toistaa itseään. Vastoin intuitiota tämä sai ihmiset luottamaan bottiin enemmän: avustaja, joka myöntää rajansa, tuntuu rehelliseltä, ja he nojasivat siihen helpon 60 %:n osalta juuri siksi, että se väistyi vaikean 40 %:n kohdalla.

Tietoinen siitä, kuka kysyy

Koska se eli tuotteen sisällä, avustaja tiesi käyttäjän paketin, roolin ja sen, missä kohtaa sovellusta hän oli. Niinpä se ei koskaan selittänyt ominaisuutta, johon käyttäjä ei päässyt käsiksi, ja se saattoi sanoa "etsimäsi painike on juuri sillä näytöllä, jolla olet." Tuo tuotetietoisuus on sovelluksen sisäisen avustajan todellinen etu markkinointisivulle pultattuun geneeriseen chatbottiin verrattuna.

1. 1
   Siivosimme ja jäsensimme tietopankin

   Kävimme jokaisen ohjeen läpi, poistimme vanhentuneet ja merkitsimme loput paketin ja ominaisuuden mukaan. Tämä oli ensimmäinen viikko, ja se oli tärkein viikko.
2. 2
   Rakensimme hakukerroksen

   Ensin haku, sitten vastaus. Malli näki vain tarkistettua, ajantasaista sisältöä — ja se ohjeistettiin kieltäytymään kaikesta, mitä se ei voinut ankkuroida lähteeseen.
3. 3
   Kytkimme tuotekontekstin

   Yhdistimme avustajan käyttäjän pakettiin, rooliin ja nykyiseen näyttöön, jotta vastaukset olivat räätälöityjä eivätkä koskaan osoittaneet ominaisuuksiin, joita käyttäjä ei voinut käyttää.
4. 4
   Suunnittelimme rehellisen varasuunnitelman

   Rakensimme 'en ole varma — tässä on ihminen' -polun ensiluokkaiseksi ominaisuudeksi, jossa koko keskustelun konteksti luovutettiin tukitiimille.
5. 5
   Julkaisimme 10 %:lle käyttäjistä lipun takana

   Otimme sen hiljaa käyttöön osalle tileistä, seurasimme oikeita keskusteluja kaksi viikkoa, korjasimme mikä rikkoutui ja laajensimme sitten käyttöönottoa.

Tulokset — ja se, joka yllätti meidät

Kun avustaja oli ollut kaikille käytössä noin kolme kuukautta, kuva oli selkeä. Annamme pyöristetyt, havainnollistavat luvut — suunta merkitsee enemmän kuin desimaalit.

Tukiluku oli se, jonka olimme luvanneet, ja se toteutui: hieman yli puolet toistuvista tukipyynnöistä lakkasi yksinkertaisesti tulemasta, ja kaksihenkinen tiimi sai viikkonsa takaisin hoitaakseen tapaukset, jotka aidosti vaativat ihmistä. Hyvä lopputulos, tismalleen niin kuin rajattiin.

Mutta tulos, joka todella yllätti perustajan, oli sellainen, jota emme olleet lainkaan optimoineet. Koska avustaja vastaili "miten teen X" -kysymyksiin koko päivän, se päätyi luonnostaan ohjaamaan käyttäjiä kohti sitä haudattua, koukuttavaa ominaisuutta — sitä, joka oli sidoksissa pysyvyyteen. Emme olleet vielä rakentaneet aktivointiavustajaa. Tukibotti hoiti hiljaa siivun sen tehtävästä sivutuotteena, pelkästään olemalla avulias ja tuotetietoinen. Uudet käyttäjät löysivät ominaisuuden viikkoja aiemmin kuin ennen.

Mitä sanoisimme seuraavalle tiimille

Jos olet SaaS-tiimi, joka tuijottaa samaa "meidän pitäisi lisätä tekoälyavustaja" -lausetta, muutama asia tästä projektista yleistyy hyvin sen ulkopuolellekin.

• Erota ongelmat ennen kuin rakennat. "Tekoäly-chatbot" piilottaa lähes aina kaksi tai kolme erillistä tehtävää, jotka kaipaavat eri suunnittelua.
• Aloita käyttötapauksesta, jossa väärä vastaus maksaa vähiten. Tukipyyntöjen torjunta on lähes täydellinen ensiliike; varasuunnitelma on nykytila.
• Varaa suurin osa työstä sisällölle, ei mallille. Ankkurointi puhtaaseen, ajantasaiseen dataan on se, mikä tekee avustajasta luotettavan.
• Tee 'en tiedä' -vastauksesta ominaisuus, ei epäonnistuminen. Rehellinen luovutus rakentaa luottamuksen, joka saa käyttäjät nojaamaan niihin osiin, jotka botti hoitaa hyvin.
• Julkaise ensin lipun takana pienelle osalle. Oikeat keskustelut opettavat sinulle asioita, joita mikään demo ei koskaan opeta.

Usein kysytyt kysymykset