Näin lisäät tekoälyominaisuuksia jo rakentamaasi SaaS-tuotteeseen

On olemassa eräänlainen paine, joka iskee juuri nyt jokaiseen SaaS-perustajaan. Hallituksen jäsen, asiakas tai pelkkä oman pään sisäinen ääni sanoo samat kolme sanaa: ”me tarvitsemme tekoälyä”. Tuote toimii jo. Ihmiset maksavat siitä. Ja silti tuntuu yhtäkkiä siltä, että siitä puuttuu jotain, mitä kaikilla muilla näyttää olevan. Joten avaat sprintin, kytket API:n, julkaiset chatbotin nurkkaan — ja kuukautta myöhemmin kukaan ei käytä sitä. Ongelma ei koskaan ollut malli. Se oli päätös siitä, mihin se osoitetaan.

Tekoälyn lisääminen aivan uuteen tuotteeseen on, kummallista kyllä, se helppo versio. Sinulla ei ole käyttäjiä, joita pettää, ei datamallia, jota kunnioittaa, eikä tukitiimiä, jolle briiffata. Tekoälyn lisääminen SaaS-tuotteeseen, joka on jo olemassa — sellaiseen, jolla on maksavia asiakkaita, vakiintunut työnkulku ja maine luotettavana — on aivan eri laji. Jokainen uusi ominaisuus laskeutuu järjestelmään, johon ihmiset jo luottavat, ja luottamus on se ainoa asia, jonka liian innokas tekoälyominaisuus polttaa nopeimmin.

Olemme auttaneet melkoista määrää ohjelmistotiimejä tekemään tämän hyvin ja katsoneet muutaman tekevän sen huonosti. Onnistuvat tiimit eivät lähes koskaan aloita teknologiasta. He aloittavat yhdestä kipeästä kysymyksestä, jota heidän käyttäjänsä toistuvasti esittävät, ja vasta sitten kysyvät, onko tekoäly halvin rehellinen vastaus. Tämä opas on juuri tuo lähestymistapa kirjoitettuna auki — miten valita ominaisuus, rakentaa se rikkomatta toimivaa ja julkaista se niin, että ihmiset todella tarttuvat siihen.

Miksi useimmat päälle liimatut tekoälyominaisuudet epäonnistuvat

Kun käyt läpi tarpeeksi SaaS-näkymiä, alat tunnistaa hautausmaan. ”✨ Tekoälyavustaja” -nappi, jota kukaan ei klikkaa. Yhteenvetopaneeli, joka tuottaa kolme mitäänsanomatonta lausetta, jotka kuka tahansa olisi voinut kirjoittaa. Chatbot, joka vastaa kysymyksiin, joihin tuote vastasi jo paremmin tavallisella hakukentällä. Nämä ominaisuudet eivät epäonnistuneet siksi, että tekoäly oli heikko. Ne epäonnistuivat, koska ne olivat ratkaisuja ongelmaa etsimässä.

Kaava on lähes aina sama. Joku tunsi paineen julkaista jotain tekoälyn muotoista, joten hän tarttui kaikkein yleisimpään, näkyvimpään vaihtoehtoon — chat-kenttään — koska se on se, joka selvimmin luetaan ”tekoälyksi”. Mutta chat-kenttä on tyhjä sivu, ja tyhjä sivu on kauhea käyttöliittymä ihmisille, jotka tulivat tuotteeseesi saadakseen tietyn työn tehtyä. He eivät halua keskustella. He haluavat raportin valmiiksi, sähköpostin luonnostelluksi, datan siivotuksi.

Toinen epäonnistumistapa on hienovaraisempi ja kalliimpi: julkaista ominaisuus, joka on oikeassa suurimman osan ajasta, työnkulkuun, jossa väärin oleminen on mahdotonta hyväksyä. 90-prosenttisesti tarkka ehdotus kuulostaa hienolta demossa. Työkalussa, jolla ihmiset lähettävät laskuja tai laativat työvuoroja, yksi itsevarma virhe kymmenestä ei lue ”vaikuttavana tekoälynä” — se lukee ”tähän tuotteeseen ei voi luottaa”. Rima on olemassa olevan tuotteen sisällä korkeammalla kuin laskeutumissivulla, koska käytät luottamusta, jonka olet jo ansainnut.

Aloita kysymyksestä, älä mallista

Hyvä uutinen on, että olemassa oleva SaaS antaa sinulle jotain, mitä tuore tuote ei koskaan: todisteita. Tiedät jo, missä käyttäjäsi kamppailevat, koska he kertovat sen sinulle joka päivä. Ensimmäisen loistavan tekoälyominaisuutesi raaka-aine istuu tukipostissasi, poistumakyselyissäsi ja niissä oman tuotteesi osissa, joita ihmiset hiljaa välttelevät.

Joten ennen kuin kukaan kirjoittaa kehotetta, mene keräämään nuo todisteet. Lue viimeiset kaksisataa tukipyyntöä ja merkitse toistuvat. Kysy tukitiimiltäsi, mihin kysymykseen he ovat kyllästyneet vastaamaan. Katso analytiikastasi se näkymä, jossa ihmiset hidastuvat, luovuttavat tai klikkailevat raivosta. Jossain siellä on tehtävä, joka on tylsä, kielen muotoinen ja tehdään yhä uudelleen — ja juuri sen muotoinen tehtävä on sellainen, jossa tekoäly on hyvä.

Huomaa, mitä näillä pyynnöillä on yhteistä: yksikään niistä ei ole ”lisää chatbot”. Ne ovat tarkkoja, upotettuja ja päättyvät konkreettiseen tulokseen. Siinä on ero tekoälyominaisuuden ja tekoälylelun välillä. Ominaisuus katoaa työnkulkuun ja säästää vaiheen. Lelu istuu sivussa ja pyytää käyttäjää tekemään ylimääräistä työtä saadakseen siitä arvoa.

Nopea tapa asettaa tekoälyehdokkaasi paremmuusjärjestykseen

Kun sinulla on lyhyt lista kolmesta kuuteen ideaa, tarvitset tavan valita, joka ei kiteydy siihen, kuka väittää äänekkäimmin suunnittelukokouksessa. Pisteytämme jokaisen ehdokkaan kolmella suoralla akselilla, yhdestä viiteen, ja korkein summa yleensä voittaa — tai ainakin aloittaa oikean väittelyn.

1. 1
   Arvo: kuinka kovasti käyttäjät tätä haluavat?

   Anna 5, jos se vastaa pyyntöön, jonka kuulet jatkuvasti, ja säästäisi näkyvästi käyttäjien aikaa. Anna 1, jos se on ”kiva lisä”, jonka joku tiimissä keksi.
2. 2
   Sietokyky: mitä tapahtuu, kun se on väärässä?

   Anna 5, jos virhe on halpa ja helppo havaita — luonnos, jonka käyttäjä joka tapauksessa tarkistaa. Anna 1, jos virhe hiljaa turmelee dataa, rahaa tai asiakassuhteen.
3. 3
   Toteutettavuus: voitko todella syöttää sille tietoa?

   Anna 5, jos sinulla on jo ominaisuuden tarvitsema data käyttökelpoisessa muodossa. Anna 1, jos se riippuu datasta, jota sinulla ei ole, johon et pääse käsiksi tai joka on sekasotku.
4. 4
   Kerro, sitten järkitarkista

   Kerro kolme keskenään. Kysy sitten inhimillinen kysymys: voimmeko julkaista voittajan ensimmäisen version noin kuukaudessa? Jos emme, rajaa sitä, kunnes voit.

Tuo keskimmäinen akseli — virheen sietokyky — on se, jonka tiimit ohittavat, ja se on se, joka upottaa projektit. Ominaisuus voi olla erittäin arvokas ja täysin toteutettavissa ja silti olla kauhea ensimmäinen valinta yksinkertaisesti siksi, että itsevarman väärän vastauksen hinta on liian korkea. Ensimmäisen tekoälyominaisuutesi pitäisi asua jossain anteeksiantavassa, jossa ihminen pysyy mukana ja virhe maksaa muutaman sekunnin, ei asiakasta.

Rakenna se tuotteeseen, älä sen viereen

Tässä on se virhe, joka erottaa rakastetun tekoälyominaisuuden siedetystä: mihin sen sijoitat. Vaisto on lisätä uusi, erillinen tekoälypinta — paneeli, sivu, chat-laatikko — koska se tuntuu siistiltä tavalta julkaista. Mutta erillinen pinta pyytää käyttäjää poistumaan siitä, mitä hän oli tekemässä, menemään muualle ja palaamaan. Jokainen noista vaiheista menettää ihmisiä.

Ominaisuudet, jotka jäävät, ovat ne, jotka ilmestyvät juuri sinne, missä työ jo tapahtuu. Luonnosnappi istuu vastauskentän sisällä, ei sivupalkissa. Poimittu data virtaa suoraan lomakekenttiin, esitäytettynä ja muokattavana. Ehdotettu prioriteetti näkyy hiljaisena merkkinä listassa, jonka käyttäjä jo silmäilee. Tekoäly ei julista itseään; se vain tekee seuraavasta klikkauksesta selvästi helpomman. Siinä on koko taito.

Tässä myös olemassa oleva tuote on lahja eikä rajoite. Tiedät jo tarkan hetken, jolloin käyttäjäsi on jumissa, tarkan kentän, jonka hän on täyttämässä, tarkan sähköpostin, jonka hän on kirjoittamassa. Käytä tuota kontekstia. Sama malli, jolle annetaan tuotteesi jo hallussa pitämä ympäröivä data, tuottaa jotain kymmenen kertaa hyödyllisempää kuin tyhjä chat-kenttä koskaan voisi — koska se ei arvaa, mitä käyttäjä haluaa. Se tietää sen jo.

Pidä ihminen mukana — ja tee siitä ilmeistä

Ensimmäisille tekoälyominaisuuksillesi turvallisin ja luotetuin malli on lähes aina ehdota, älä toimi. Tekoäly ehdottaa; ihminen hyväksyy. Se luonnostelee sähköpostin ja ihminen lähettää sen. Se täyttää kentät ja ihminen tarkistaa ne. Se merkitsee prioriteetin ja ihminen päättää. Tämä ei ole kunnianhimon puutetta — tällä tavalla rakennat näytöt, jotka antavat sinun automatisoida enemmän myöhemmin.

Tässä on mukana suunnittelu-ulottuvuus, ei vain tekninen. Tee visuaalisesti selväksi, milloin jokin tuli tekoälystä ja odottaa ihmisen siunausta. Hienovarainen merkintä, eri tausta, eksplisiittinen ”tarkista ja lähetä” hiljaisen automaattitoiminnon sijaan. Käyttäjät antavat anteeksi hieman pielessä olevan tekoälyehdotuksen paljon helpommin kuin tekoälytoiminnon, joka tapahtui kysymättä. Ensimmäinen tuntuu avuliaalta kollegalta; toinen tuntuu siltä, että ohjelmisto karkasi käsistä.

• Näytä tekoälyn tuotos luonnoksena tai ehdotuksena, jota käyttäjä voi muokata ennen kuin se astuu voimaan.
• Tee siitä visuaalisesti erottuva, jottei kukaan sekoita koneen arvausta vahvistettuun faktaan.
• Tarjoa aina siisti ”ei kiitos” — anna ihmisten hylätä ehdotus ja jatkaa vanhalla tavalla.
• Kun tekoäly on epävarma, sano se, ja heikkene hallitusti sen sijaan, että keksisit itsevarman vastauksen.
• Kirjaa, mitä ehdotettiin ja mitä ihminen teki sillä — se on tarkkuusdatasi myöhempää varten.

Tuo viimeinen kohta on hiljaa kaikkein arvokkain. Joka kerta, kun käyttäjä hyväksyy, muokkaa tai hylkää ehdotuksen, hän kertoo sinulle, kuinka hyvä ominaisuutesi todella on — oikeassa maailmassa, oikealla datalla, ei demossa. Tuo palautesilmukka on se, jolla päätät, onko ominaisuus valmis muuttumaan itsenäisemmäksi ja missä se yhä tarvitsee ihmiskäden ohjaksissa.

Tekninen todellisuus, josta kukaan ei varoita sinua

Demo on se helppo 20 %. Tekoälyominaisuuden saaminen tuotantokuntoon oikeassa SaaS-tuotteessa on se toinen 80 %, ja se on enimmäkseen kunniatonta työtä, jolla on vähän tekemistä itse mallin kanssa. Tämä kannattaa tietää etukäteen, jottei toimiva prototyyppi huijaa sinua lupaamaan julkaisupäivää, jonka tulet myöhästymään.

Datan putkitus ja konteksti

Malli on vain niin hyödyllinen kuin se, mitä sille syötät. Vaikea osa on luotettavasti kerätä oikea konteksti olemassa olevasta tietokannastasi, muotoilla se, pitää se ajantasaisena ja kunnioittaa sitä, kuka käyttäjä saa nähdä mitä. Monitenanttisessa SaaS-tuotteessa tällä on valtava merkitys: tekoälyominaisuus, joka vahingossa sekoittaa yhden asiakkaan datan toisen vastaukseen, ei ole bugi, vaan tietoturvapoikkeama. Tenanttien eristyksen on ulotuttava aina tekoälykerrokseesi asti.

Kustannus ja viive

Jokainen tekoälykutsu maksaa rahaa ja vie aikaa, ja molemmat skaalautuvat käytön mukana tavoilla, joilla kiinteä SaaS-tilaus ei. Ominaisuus, joka on ihana kymmenelle beta-käyttäjälle, voi hiljaa muuttua katteongelmaksi kymmenelle tuhannelle. Sinun on mietittävä varhain, mikä malli sopii mihinkin tehtävään — et tarvitse tehokkainta, kalleinta mallia tukipyynnön luokitteluun — toistuvan työn välimuistitusta ja sitä, mitä ominaisuus tekee, kun vastaus kestää neljä sekuntia yhden sijaan.

Epäonnistuminen ja onneton polku

Oikeat käyttäjät liittävät sisään roskaa, lataavat väärän tiedoston, kirjoittavat kolmella kielellä ja osuvat ominaisuuteesi pahimpana mahdollisena hetkenä. Tekoälyntarjoajalla on käyttökatko. Vastaus palaa väärin muotoiltuna. Ominaisuutesi on käsiteltävä kaikki tuo rikkomatta muuta tuotetta. Sääntö on yksinkertainen ja tiukka: tekoälyominaisuuden epäonnistuminen ei saa koskaan kaataa ydintyönkulkua mukanaan. Sen pitäisi epäonnistua hiljaa, pudota takaisin manuaaliseen polkuun ja antaa käyttäjän jatkaa työskentelyä.

Hinnoittelu: ominaisuus, lisäosa vai koko tarina?

Kun ominaisuus toimii, edessäsi on liiketoimintakysymys, joka kompastuttaa monet tiimit: miten laskutat siitä? Ei ole yhtä oikeaa vastausta, mutta on muutama rehellinen malli. Voit sisällyttää sen olemassa oleviin paketteihisi lisäarvona, joka parantaa pysyvyyttä ja oikeuttaa hintasi. Voit tehdä siitä maksullisen lisäosan tai korkeamman tason, mikä toimii, kun ominaisuus tuottaa ilmeistä, mitattavaa arvoa. Tai voit mitata sen käytön mukaan, kun taustalla oleva kustannus aidosti skaalautuu kulutuksen mukana.

Vältettävä ansa on hinnoitella ominaisuus ikään kuin tekoäly olisi tuote. Useimmille SaaS-yrityksille tekoäly ei ole uusi tuotelinja — se on uusi kyvykkyys, joka tekee olemassa olevasta tuotteestasi arvokkaamman. Asiakkaat eivät herää haluten ostaa ”tekoälyä”. He haluavat varsinaisen ongelmansa ratkaistuksi hieman helpommin, ja he maksavat tuosta lopputuloksesta riippumatta siitä, onko taustalla kone vai ei. Hinnoittele lopputulos, älä teknologia.

Julkaise yksi pieni asia, sitten kiipeä

Koko strategia kiteytyy sarjaan, ei yhteen julkaisuun. Valitse se yksi arvokas, virhettä sietävä ominaisuus, jota käyttäjäsi jo pyytävät. Upota se sinne, missä työ tapahtuu. Pidä ihminen mukana. Julkaise se osalle asiakkaista ominaisuuslipun takana. Katso, miten he todella käyttävät sitä, korjaa karkeat kohdat, sitten laajenna. Vasta kun tuo ominaisuus on ansainnut paikkansa, tartut seuraavaan, hieman kunnianhimoisempaan.

Tee tämä muutaman kerran, ja jotain hiljaa voimakasta tapahtuu. Tuotteesi lakkaa olemasta ”ohjelmisto, johon on pultattu tekoälynappi”, ja siitä tulee työkalu, joka on aidosti älykkäämpi niissä tietyissä tehtävissä, joista asiakkaasi välittävät. Se on paljon vahvempi asema kuin tiimillä, joka julkaisi vaikuttavan chatbot-demon ensimmäisellä viikolla ja vietti seuraavat kuusi kuukautta selittäen, miksei kukaan käytä sitä.

Yleisiä kysymyksiä