Slik legger du til AI-funksjoner i en SaaS du allerede har bygget

Det finnes et særskilt slags press som rammer enhver SaaS-gründer akkurat nå. Et styremedlem, en kunde, eller bare stemmen i ditt eget hode sier de samme tre ordene: «vi trenger AI». Produktet virker allerede. Folk betaler for det. Og likevel føles det plutselig som om det mangler noe alle andre ser ut til å ha. Så du åpner en sprint, kobler på et API, lanserer en chatbot i hjørnet — og en måned senere bruker ingen den. Problemet var aldri modellen. Det var beslutningen om hva den skulle rettes mot.

Å legge til AI i et helt nytt produkt er, merkelig nok, den enkle versjonen. Du har ingen brukere å skuffe, ingen datamodell å respektere, ingen supportavdeling å orientere. Å legge til AI i en SaaS som allerede finnes — en med betalende kunder, en etablert arbeidsflyt og et rykte for å være pålitelig — er en helt annen sport. Hver ny funksjon lander inni et system folk allerede stoler på, og tillit er det ene en altfor ivrig AI-funksjon brenner raskest av.

Vi har hjulpet ganske mange programvareteam med å gjøre dette godt, og sett noen få gjøre det dårlig. Teamene som lykkes, starter nesten aldri med teknologien. De starter med ett smertefullt spørsmål brukerne deres stadig stiller, og først da spør de om AI er det billigste ærlige svaret. Denne guiden er nettopp den tilnærmingen skrevet ut — hvordan du velger funksjonen, bygger den uten å ødelegge det som virker, og lanserer den slik at folk faktisk strekker seg etter den.

Hvorfor de fleste påklistrede AI-funksjoner mislykkes

Gå gjennom nok SaaS-dashbord, og du begynner å kjenne igjen gravlunden. En «✨ AI-assistent»-knapp ingen klikker på. Et oppsummeringspanel som produserer tre intetsigende setninger hvem som helst kunne ha skrevet. En chatbot som svarer på spørsmål produktet allerede svarte bedre på med et vanlig søkefelt. Disse funksjonene mislyktes ikke fordi AI-en var svak. De mislyktes fordi de var løsninger på jakt etter et problem.

Mønsteret er nesten alltid det samme. Noen kjente på presset for å lansere noe AI-formet, så de grep det mest generiske, mest synlige alternativet — et chatfelt — fordi det er det som tydeligst leses som «AI». Men et chatfelt er en tom side, og en tom side er et elendig grensesnitt for folk som kom til produktet ditt for å få en bestemt jobb gjort. De vil ikke samtale. De vil ha rapporten ferdig, e-posten skrevet, dataene ryddet.

Den andre feiltypen er mer subtil og dyrere: å lansere en funksjon som har rett mesteparten av tiden, inn i en arbeidsflyt der feil er uakseptabelt. Et forslag med 90 % nøyaktighet høres flott ut i en demo. I et verktøy folk bruker til å sende fakturaer eller sette opp vaktlister, leses én selvsikker feil av ti ikke som «imponerende AI» — det leses som «dette produktet kan man ikke stole på». Lista inni et eksisterende produkt ligger høyere enn på en landingsside, fordi du bruker av en tillit du allerede har opparbeidet.

Start med spørsmålet, ikke modellen

Den gode nyheten er at en eksisterende SaaS gir deg noe et ferskt produkt aldri har: bevis. Du vet allerede hvor brukerne dine sliter, fordi de forteller deg det hver dag. Råmaterialet til din første virkelig gode AI-funksjon sitter i support-innboksen din, churn-undersøkelsene dine og de delene av ditt eget produkt folk stille unngår.

Så før noen skriver en ledetekst, gå og samle de bevisene. Les de siste to hundre supportsakene og merk de gjentakende. Spør supportteamet ditt hvilket spørsmål de er lei av å svare på. Se i analysen etter skjermen der folk bremser, gir opp eller raseriklikker. Et eller annet sted der inne er en oppgave som er kjedelig, språkformet og gjøres om og om igjen — og det er nøyaktig formen på en oppgave AI er god til.

Legg merke til hva disse forespørslene har til felles: ingen av dem er «legg til en chatbot». De er spesifikke, innebygde og slutter med et konkret resultat. Det er forskjellen mellom en AI-funksjon og en AI-leke. En funksjon forsvinner inn i arbeidsflyten og sparer et steg. En leke sitter på siden og ber brukeren gjøre ekstra arbeid for å få verdi ut av den.

En rask måte å rangere AI-kandidatene dine på

Når du har en kortliste på tre til seks ideer, trenger du en måte å velge på som ikke kommer an på hvem som argumenterer høyest i planleggingsmøtet. Vi gir hver kandidat poeng på tre rette akser, én til fem, og den høyeste totalen vinner som regel — eller starter i det minste den riktige diskusjonen.

1. 1
   Verdi: hvor sterkt vil brukerne ha dette?

   Gi 5 hvis det svarer på en forespørsel du hører konstant og synlig ville spart brukerne tid. Gi 1 hvis det er et «kjekt å ha» noen på teamet fant på.
2. 2
   Toleranse: hva skjer når den tar feil?

   Gi 5 hvis en feil er billig og lett å oppdage — et utkast brukeren uansett gjennomgår. Gi 1 hvis en feil stille ødelegger data, penger eller et kundeforhold.
3. 3
   Gjennomførbarhet: kan du faktisk fôre den?

   Gi 5 hvis du allerede har dataene funksjonen trenger i brukbar form. Gi 1 hvis den avhenger av data du ikke har, ikke får tilgang til, eller som er et rot.
4. 4
   Multipliser, og gjør så en fornuftssjekk

   Multipliser de tre. Still så det menneskelige spørsmålet: kan vi lansere en første versjon av vinneren på omtrent en måned? Hvis ikke, snevre den inn til du kan.

Den midterste aksen — feiltoleranse — er den teamene hopper over, og det er den som senker prosjekter. En funksjon kan ha høy verdi og være fullt gjennomførbar og likevel være et elendig førstevalg, rett og slett fordi prisen for et selvsikkert feil svar er for høy. Din første AI-funksjon bør bo et sted tilgivende, der mennesket blir i loopen og en feil koster noen sekunder, ikke en kunde.

Bygg den inn i produktet, ikke ved siden av

Her er feilen som skiller en AI-funksjon folk elsker fra en de tolererer: hvor du plasserer den. Instinktet er å legge til en ny, separat AI-flate — et panel, en side, en chatskuff — fordi det føles som en ren måte å lansere på. Men en separat flate ber brukeren forlate det de holdt på med, gå et annet sted og komme tilbake. Hvert av de stegene mister folk.

Funksjonene som blir værende, er de som dukker opp akkurat der arbeidet allerede skjer. Utkast-knappen sitter inni svarfeltet, ikke i et sidefelt. De uthentede dataene flyter rett inn i skjemafeltene, forhåndsutfylt og redigerbare. Den foreslåtte prioriteten vises som et diskret merke i lista brukeren allerede skummer. AI-en kunngjør ikke seg selv; den gjør bare det neste klikket åpenbart enklere. Det er hele håndverket.

Det er også her et eksisterende produkt er en gave snarere enn en begrensning. Du kjenner allerede det nøyaktige øyeblikket brukeren din står fast, det nøyaktige feltet de er i ferd med å fylle ut, den nøyaktige e-posten de er i ferd med å skrive. Bruk den konteksten. Den samme modellen, gitt de omkringliggende dataene produktet ditt allerede har, produserer noe ti ganger nyttigere enn et tomt chatfelt noensinne kunne — fordi den ikke gjetter på hva brukeren vil. Den vet det allerede.

Hold et menneske i loopen — og gjør det tydelig

For dine første AI-funksjoner er det tryggeste og mest betrodde mønsteret nesten alltid foreslå, ikke handle. AI-en foreslår; mennesket godkjenner. Den skriver e-posten og personen sender den. Den fyller feltene og personen sjekker dem. Den flagger prioriteten og personen bestemmer. Dette er ikke mangel på ambisjon — det er slik du bygger merittlista som lar deg automatisere mer senere.

Det er en designdimensjon i dette, ikke bare en teknisk. Gjør det visuelt klart når noe kom fra AI-en og venter på et menneskes velsignelse. En diskret etikett, en annen bakgrunn, et uttrykkelig «gjennomgå og send» snarere enn en stille autohandling. Brukere tilgir et AI-forslag som er litt feil langt lettere enn en AI-handling som skjedde uten å spørre. Det første føles som en hjelpsom kollega; det andre føles som om programvaren gikk amok.

• Vis AI-ens utdata som et utkast eller forslag brukeren kan redigere før det teller.
• Gjør det visuelt tydelig så ingen forveksler en maskingjetning med et bekreftet faktum.
• Tilby alltid et rent «nei takk» — la folk avvise forslaget og fortsette på den gamle måten.
• Når AI-en er usikker, si det, og degrader elegant i stedet for å finne på et selvsikkert svar.
• Logg hva som ble foreslått og hva mennesket gjorde med det — det er nøyaktighetsdataene dine til senere.

Det siste punktet er stille det mest verdifulle. Hver gang en bruker godtar, redigerer eller avviser et forslag, forteller de deg hvor god funksjonen din faktisk er — i den virkelige verden, på ekte data, ikke i en demo. Den tilbakemeldingssløyfen er hvordan du avgjør om en funksjon er klar til å bli mer autonom, og hvor den fortsatt trenger en menneskehånd på rattet.

Den tekniske virkeligheten ingen advarer deg om

Demoen er de enkle 20 prosentene. Å få en AI-funksjon produksjonsklar inni en ekte SaaS er de andre 80 prosentene, og det er for det meste uglamorøst arbeid som har lite med selve modellen å gjøre. Det er verdt å vite på forhånd, så en fungerende prototype ikke lurer deg til å love en lanseringsdato du kommer til å bomme på.

Datarør og kontekst

En modell er bare så nyttig som det du fôrer den med. Det vanskelige er å pålitelig samle riktig kontekst fra den eksisterende databasen din, formatere den, holde den oppdatert og respektere hvilken bruker som har lov til å se hva. I en SaaS med flere leietakere betyr dette enormt mye: en AI-funksjon som ved et uhell blander én kundes data inn i en annens svar, er ikke en feil, det er en hendelse. Adskillelsen mellom leietakere må strekke seg helt inn i AI-laget ditt.

Kostnad og responstid

Hvert AI-kall koster penger og tar tid, og begge skalerer med bruken på måter et fast SaaS-abonnement ikke gjør. En funksjon som er herlig for ti betabrukere, kan stille bli et marginproblem ved ti tusen. Du må tenke tidlig på hvilken modell som passer til hvilken jobb — du trenger ikke den kraftigste, dyreste modellen for å kategorisere en supportsak — på å mellomlagre gjentatt arbeid, og på hva funksjonen gjør når et svar tar fire sekunder i stedet for ett.

Feil og den ulykkelige stien

Ekte brukere limer inn søppel, laster opp feil fil, skriver på tre språk og treffer funksjonen din på verst tenkelige tidspunkt. AI-leverandøren har et avbrudd. Et svar kommer tilbake misdannet. Funksjonen din må håndtere alt det uten å ødelegge resten av produktet. Regelen er enkel og streng: at en AI-funksjon feiler skal aldri dra en kjernearbeidsflyt med seg ned. Den skal feile stille, falle tilbake til den manuelle stien og la brukeren jobbe videre.

Å prise den: en funksjon, et tillegg eller hele historien?

Når funksjonen virker, står du overfor et forretningsspørsmål som feller mange team: hvordan tar du betalt for den? Det finnes ikke ett riktig svar, men det finnes noen få ærlige mønstre. Du kan folde den inn i de eksisterende planene dine som en merverdi som forbedrer kundelojalitet og rettferdiggjør prisen din. Du kan gjøre den til et betalt tillegg eller et høyere nivå, noe som virker når funksjonen leverer åpenbar, målbar verdi. Eller du kan måle den etter bruk når den underliggende kostnaden faktisk skalerer med forbruket.

Fellen du må unngå, er å prise funksjonen som om AI er produktet. For de fleste SaaS-selskaper er AI ikke en ny produktlinje — det er en ny evne som gjør det eksisterende produktet ditt mer verdifullt. Kunder våkner ikke med lyst til å kjøpe «AI». De vil ha det faktiske problemet sitt løst litt enklere, og de betaler for det utfallet enten det er en maskin bak eller ikke. Pris utfallet, ikke teknologien.

Lanser én liten ting, klatre så

Hele strategien koker ned til en sekvens, ikke en enkelt lansering. Velg den ene høyverdige, feiltolerante funksjonen brukerne dine allerede ber om. Bygg den inn der arbeidet skjer. Hold et menneske i loopen. Lanser den til en del av kundene bak et flagg. Se hvordan de faktisk bruker den, fiks det grove, og utvid den så. Først når den funksjonen har fortjent plassen sin, strekker du deg etter den neste, litt mer ambisiøse.

Gjør dette et par ganger, og noe stille kraftfullt skjer. Produktet ditt slutter å være «programvare med en påklistret AI-knapp» og blir et verktøy som er genuint smartere på de spesifikke jobbene kundene dine bryr seg om. Det er en langt sterkere posisjon enn teamet som lanserte en imponerende chatbot-demo i uke én og brukte det neste halvåret på å forklare hvorfor ingen bruker den.

Vanlige spørsmål