Hvordan vi la til en AI-assistent i en SaaS-plattform — uten å ødelegge den

Hvert SaaS-team vi snakker med sier før eller siden den samme setningen høyt: "Vi burde legge en AI-assistent inn her." Noen ganger er det press fra styret, noen ganger en konkurrents lansering, noen ganger er det ekte. Det interessante er aldri idéen — nesten alle har idéen. Det interessante er gapet mellom den setningen og en funksjon som ekte brukere faktisk stoler på. Dette er historien om ett team som krysset det gapet, og de lite glamorøse beslutningene som førte dem dit.

En kort merknad før vi begynner: vi har anonymisert kunden og rundet av tallene. Det er et lite, lønnsomt B2B-SaaS-selskap — under tjue ansatte — som selger et arbeidsflytverktøy til driftsteam. Vi har endret nok detaljer til at du ikke kjenner dem igjen, men formen på prosjektet er nøyaktig slik det skjedde. Tallene er illustrerende, ikke reviderte; vi viser deg heller mønsteret enn å pynte på et diagram.

Vi skriver dette ned fordi prosjektet er et nesten perfekt eksempel på hvordan slike ting faktisk går. Det gikk ikke slik oppstartspresentasjonen sa. Det gikk bedre — men bare fordi vi var villige til å kaste den første versjonen.

Situasjonen: to problemer i ett kostyme

Da gründeren først tok kontakt, var forespørselen enkel: "Vi vil ha en AI-chatbot i appen." Det er der de fleste prosjekter starter, og også der de fleste stille går galt. "AI-chatbot" er ikke et mål, det er en form. Vår første oppgave var derfor å finne ut hvilket problem chatboten skulle løse — og om det i det hele tatt var ett problem.

Det var det ikke. Under den ene forespørselen lå to helt forskjellige smerter. Den første var supportbelastning: et kundeserviceteam på to personer druknet i repeterende henvendelser — "hvordan eksporterer jeg dette", "hvor er innstillingen for det", "hvorfor kjørte ikke rapporten min". Omtrent 60 % av innkommende henvendelser var spørsmål som allerede var besvart et sted i hjelpedokumentasjonen. Den andre smerten var stillere og dyrere: aktivering. Produktet hadde en virkelig kraftig funksjon begravd tre klikk dypt som nesten ingen oppdaget på egen hånd. Brukere som fant den, ble værende i årevis. De som ikke fant den, forsvant i løpet av de første to månedene.

Samme kostyme, to problemer. Og de trakk i hver sin retning. En supportbot vil avvise spørsmål og komme seg ut av veien. En aktiveringsassistent vil starte samtaler og dytte folk mot ting de ikke spurte om. Hadde vi bygd "en AI-chatbot" uten å skille disse, ville vi bygd noe som gjorde begge jobbene dårlig.

Ned til noe vi kunne fullføre

Stilt overfor to problemer er fristelsen å bygge en storslått assistent som håndterer begge fra dag én. Vi snakket teamet fra det. Ikke fordi visjonen var feil, men fordi en seks måneders "alt-assistent" er nettopp den typen prosjekt som leverer for sent, faller flatt og gjør alle nervøse for AI de neste to årene.

Så vi valgte ett. Vi valgte å avvise support først, av tre kjedelige, men avgjørende grunner. Det hadde et tydelig, målbart mål — antall henvendelser. Det brukte innhold som allerede fantes — hjelpedokumentasjonen og tidligere henvendelser. Og hvis det underpresterte, var nedsiden liten: en bruker som ikke fikk et godt svar, gjorde ganske enkelt det de allerede gjorde og opprettet en henvendelse. Lav risiko, rask tilbakemelding, ærlig måltall. Det er en god første AI-funksjon, hver gang.

Aktiveringsassistenten forsvant ikke — vi parkerte den, på papiret, med en tydelig merknad: fase to, når gjenfinningslaget er bevist. Den ene beslutningen reddet trolig prosjektet. Den ga teamet en målstrek de faktisk kunne nå på uker i stedet for kvartaler.

Den første prototypen vi bygde — og slettet

Her er delen de fleste case studies utelater. Vår første fungerende prototype var, for å si det pent, ikke bra. Vi gjorde det åpenbare: koblet produktets hjelpeartikler til en stor språkmodell, la til et chattevindu og lot brukerne stille spørsmål. I demoen så det magisk ut. I ekte testing falt det fra hverandre på en veldig spesifikk, veldig lærerik måte.

Modellen tok selvsikkert feil. Spurt om en innstilling som var omdøpt et halvt år tidligere, fant den muntert opp den gamle menystien. Spurt om en funksjon på et høyere abonnement, forklarte den hvordan man brukte den — til en kunde som ikke hadde tilgang. Hvert svar hørtes autoritativt ut, noe som gjorde de feilaktige verre enn ingen svar i det hele tatt. En supportbot som lyver høflig, reduserer ikke henvendelser; den skaper sintere.

Vi kunne dekket over det med promptjusteringer. I stedet gjorde vi noe som føltes som et steg tilbake og viste seg å være hele spillet: vi kastet den første prototypen og bygde den på nytt rundt en streng regel — assistenten kan bare svare fra kilder den kan sitere, og må ellers si "jeg vet ikke".

Hva vi faktisk bygde

Versjonen som ble lansert, var bevisst beskjeden i hva den forsøkte og streng i hvordan den oppførte seg. Under panseret var det en gjenfinningsforankret assistent: når en bruker spurte om noe, søkte systemet først i en kuratert, oppdatert kunnskapsbase, og ba deretter modellen svare kun fra det den fant, med en lenke tilbake til kilden. Ingen kilde, ingen selvsikkert svar — bare en ryddig overlevering til et menneske.

Tre designvalg gjorde mesteparten av det tunge løftet, og ingen av dem er spennende. Det er nettopp poenget — de kjedelige valgene avgjør som regel om en AI-funksjon blir stolt på eller stille slått av.

Forankring fremfor smarthet

Hvert svar var knyttet til et ekte, oppdatert dokument. Vi brukte mer tid på å rydde og strukturere kunnskapsbasen enn på å finjustere modellen. Lite glamorøst, og det klart mest utslagsgivende arbeidet i prosjektet. En middelmådig modell på utmerket, godt vedlikeholdt innhold slår en briljant modell på et utdatert rot.

En smidig overlevering

Når assistenten ikke var sikker, gjettet den ikke. Den sa det og tilbød en rute på ett klikk til et menneske — og bar med seg samtalekonteksten, slik at brukeren aldri måtte gjenta seg selv. Mot intuisjonen fikk dette folk til å stole mer på boten: en assistent som innrømmer sine grenser føles ærlig, og de lente seg på den for de enkle 60 % nettopp fordi den trakk seg unna ved de vanskelige 40 %.

Bevisst på hvem som spør

Fordi den levde inne i produktet, kjente assistenten brukerens abonnement, rolle og hvor de var i appen. Slik forklarte den aldri en funksjon de ikke hadde tilgang til, og den kunne si "knappen du leter etter er på skjermen du allerede er på." Den produktbevisstheten er den ekte fordelen med en assistent i appen fremfor en generisk chatbot skrudd fast på en markedsføringsside.

1. 1
   Ryddet og strukturerte kunnskapsbasen

   Gikk gjennom hvert hjelpedokument, kvittet oss med de utdaterte og merket resten etter abonnement og funksjon. Dette var uke én, og det var den viktigste uken.
2. 2
   Bygde gjenfinningslaget

   Søk først, svar etterpå. Modellen så bare verifisert, oppdatert innhold — og fikk beskjed om å avslå alt den ikke kunne forankre i en kilde.
3. 3
   Koblet inn produktkontekst

   Koblet assistenten til brukerens abonnement, rolle og gjeldende skjerm, slik at svarene var tilpasset og aldri pekte på funksjoner de ikke kunne bruke.
4. 4
   Designet den ærlige reserveløsningen

   Bygde ruten 'jeg er ikke sikker — her er et menneske' som en fullverdig funksjon, med hele samtalekonteksten overlevert til supportteamet.
5. 5
   Lanserte til 10 % av brukerne bak et flagg

   Rullet stille ut til en del av kontoene, fulgte ekte samtaler i to uker, fikset det som brakk, og utvidet så utrullingen.

Resultatene — og det som overrasket oss

Etter at assistenten hadde vært live for alle i omtrent tre måneder, var bildet tydelig. Vi gir deg avrundede, illustrerende tall — retningen betyr mer enn desimalene.

Supporttallet var det vi hadde lovet, og det leverte: litt over halvparten av de repeterende henvendelsene sluttet rett og slett å komme, og teamet på to fikk uken sin tilbake til å håndtere sakene som virkelig trengte et menneske. Godt utfall, nøyaktig som avtalt.

Men resultatet som faktisk overrasket gründeren, var ett vi ikke hadde optimalisert for i det hele tatt. Fordi assistenten svarte på "hvordan gjør jeg X"-spørsmål hele dagen, pekte den naturlig brukere mot den begravde, klebrige funksjonen — den knyttet til fastholdelse. Vi hadde ikke bygd aktiveringsassistenten ennå. Supportboten gjorde stille en del av jobben dens som en sidevirkning, ganske enkelt ved å være hjelpsom og produktbevisst. Nye brukere fant funksjonen uker tidligere enn før.

Hva vi ville sagt til det neste teamet

Er du et SaaS-team som stirrer på den samme setningen "vi burde legge til en AI-assistent", er det noen ting fra dette prosjektet som gjelder langt bredere enn det.

• Skill problemene før du bygger. "AI-chatbot" skjuler nesten alltid to eller tre distinkte jobber som vil ha ulike design.
• Start med bruksområdet der et feil svar koster minst. Å avvise support er et nesten perfekt første trekk; reserveløsningen er status quo.
• Sett av mesteparten av innsatsen til innholdet, ikke modellen. Forankring på rene, oppdaterte data er det som gjør en assistent til å stole på.
• Gjør 'jeg vet ikke' til en funksjon, ikke en feil. En ærlig overlevering bygger tilliten som får brukerne til å lene seg på det boten gjør godt.
• Lanser bak et flagg til en liten del først. Ekte samtaler lærer deg ting ingen demo noensinne gjør.

Vanlige spørsmål