Så lade vi till en AI-assistent i en SaaS-plattform — utan att förstöra den

Varje SaaS-team vi pratar med säger förr eller senare samma mening högt: "Vi borde lägga in en AI-assistent här." Ibland är det press från styrelsen, ibland en konkurrents lansering, ibland är det äkta. Det intressanta är aldrig idén — nästan alla har idén. Det intressanta är klyftan mellan den meningen och en funktion som riktiga användare faktiskt förlitar sig på. Det här är berättelsen om ett team som tog sig över den, och de föga glamorösa beslut som förde dem dit.

En snabb notis innan vi börjar: vi har anonymiserat kunden och avrundat siffrorna. Det är ett litet, lönsamt B2B-SaaS-bolag — under tjugo personer — som säljer ett arbetsflödesverktyg till driftteam. Vi har ändrat tillräckligt många detaljer för att ni inte ska känna igen dem, men projektets form är precis som det gick till. Siffrorna är illustrativa, inte reviderade; vi visar er hellre mönstret än pyntar upp ett diagram.

Vi skriver ner det här eftersom projektet är ett nästan perfekt exempel på hur sådana här saker faktiskt går till. Det gick inte som kickoff-presentationen sa. Det gick bättre — men bara för att vi var villiga att kasta den första versionen.

Situationen: två problem i en och samma kostym

När grundaren först hörde av sig var begäran enkel: "Vi vill ha en AI-chatbot i appen." Där börjar de flesta projekt, och där går de flesta också tyst fel. "AI-chatbot" är inte ett mål, det är en form. Vår första uppgift var alltså att ta reda på vilket problem chatboten skulle lösa — och om det ens var ett problem.

Det var det inte. Under den enda begäran låg två helt olika smärtor. Den första var supportbelastning: ett kundserviceteam på två personer drunknade i upprepade ärenden — "hur exporterar jag det här", "var är inställningen för det", "varför kördes inte min rapport". Ungefär 60 % av de inkommande ärendena var frågor som redan var besvarade någonstans i hjälpdokumentationen. Den andra smärtan var tystare och dyrare: aktivering. Produkten hade en verkligt kraftfull funktion begravd tre klick ner som nästan ingen upptäckte på egen hand. Användare som hittade den stannade i åratal. De som inte gjorde det försvann inom de första två månaderna.

Samma kostym, två problem. Och de drog åt olika håll. En supportbot vill avvärja frågor och komma ur vägen. En aktiveringsassistent vill starta samtal och knuffa folk mot saker de inte frågade om. Hade vi byggt "en AI-chatbot" utan att skilja på dessa hade vi byggt något som gjorde bägge jobben dåligt.

Ner till något vi kunde slutföra

Ställd inför två problem är frestelsen att bygga en storslagen assistent som hanterar bägge från dag ett. Vi pratade teamet ur det. Inte för att visionen var fel, utan för att en sex månaders "allt-assistent" är precis den sortens projekt som levererar för sent, faller platt och gör alla nervösa för AI de kommande två åren.

Så vi valde ett. Vi valde att avvärja support först, av tre tråkiga men avgörande skäl. Det hade ett tydligt, mätbart mål — antal ärenden. Det använde innehåll som redan fanns — hjälpdokumentationen och tidigare ärenden. Och om det underpresterade var nedsidan liten: en användare som inte fick ett bra svar gjorde helt enkelt det de redan gjorde och öppnade ett ärende. Låg risk, snabb återkoppling, ärligt mätetal. Det är en bra första AI-funktion, varje gång.

Aktiveringsassistenten försvann inte — vi parkerade den, på papperet, med en tydlig notering: fas två, när återvinningslagret är bevisat. Det enda beslutet räddade förmodligen projektet. Det gav teamet en mållinje de faktiskt kunde nå på veckor i stället för kvartal.

Den första prototypen vi byggde — och raderade

Här är delen som de flesta case studies utelämnar. Vår första fungerande prototyp var, milt uttryckt, inte bra. Vi gjorde det uppenbara: kopplade produktens hjälpartiklar till en stor språkmodell, la till en chattruta och lät användarna ställa frågor. I demon såg det magiskt ut. I riktig testning föll det samman på ett mycket specifikt, mycket lärorikt sätt.

Modellen hade självsäkert fel. Tillfrågad om en inställning som döpts om ett halvår tidigare hittade den glatt på den gamla menyvägen. Tillfrågad om en funktion i ett dyrare abonnemang förklarade den hur man använde den — för en kund som inte hade tillgång. Varje svar lät auktoritativt, vilket gjorde de felaktiga värre än inget svar alls. En supportbot som ljuger artigt minskar inte ärenden; den skapar argare.

Vi kunde ha maskerat det med prompt-justeringar. I stället gjorde vi något som kändes som ett steg bakåt och visade sig vara hela grejen: vi kastade den första prototypen och byggde om den kring en strikt regel — assistenten får bara svara utifrån källor den kan citera, och måste annars säga "jag vet inte".

Vad vi faktiskt byggde

Versionen som lanserades var medvetet blygsam i vad den försökte sig på och strikt i hur den betedde sig. Under huven var det en återvinningsförankrad assistent: när en användare frågade något sökte systemet först i en kurerad, aktuell kunskapsbas och bad sedan modellen svara enbart utifrån det den hittade, med en länk tillbaka till källan. Ingen källa, inget självsäkert svar — bara en prydlig överlämning till en människa.

Tre designval gjorde det mesta av det tunga arbetet, och inget av dem är spännande. Det är just poängen — de tråkiga valen avgör oftast om en AI-funktion blir betrodd eller tyst avstängd.

Förankring framför skärpa

Varje svar var knutet till ett riktigt, aktuellt dokument. Vi lade mer tid på att städa och strukturera kunskapsbasen än på att finjustera modellen. Föga glamoröst, och det klart mest utslagsgivande arbetet i projektet. En medelmåttig modell på utmärkt, välskött innehåll slår en briljant modell på en föråldrad röra.

En smidig överlämning

När assistenten inte var säker gissade den inte. Den sa det och erbjöd en väg på ett klick till en människa — och bar med sig samtalskontexten så att användaren aldrig behövde upprepa sig. Tvärtemot intuitionen fick det folk att lita mer på boten: en assistent som erkänner sina gränser känns ärlig, och de lutade sig mot den för de enkla 60 % just för att den steg åt sidan vid de svåra 40 %.

Medveten om vem som frågar

Eftersom den levde inuti produkten visste assistenten användarens abonnemang, roll och var i appen de befann sig. På så vis förklarade den aldrig en funktion de inte hade tillgång till, och den kunde säga "knappen ni letar efter finns på skärmen ni redan är på." Den produktmedvetenheten är den verkliga fördelen med en assistent i appen framför en generisk chatbot fastskruvad på en marknadsföringssida.

1. 1
   Städade och strukturerade kunskapsbasen

   Granskade varje hjälpdokument, rensade de föråldrade och taggade resten efter abonnemang och funktion. Det var vecka ett, och det var den viktigaste veckan.
2. 2
   Byggde återvinningslagret

   Sök först, svara sedan. Modellen såg bara granskat, aktuellt innehåll — och instruerades att neka allt den inte kunde förankra i en källa.
3. 3
   Kopplade in produktkontext

   Kopplade assistenten till användarens abonnemang, roll och aktuella skärm, så att svaren var skräddarsydda och aldrig pekade på funktioner de inte kunde använda.
4. 4
   Designade den ärliga reservlösningen

   Byggde vägen 'jag är inte säker — här är en människa' som en fullvärdig funktion, med hela samtalskontexten överlämnad till supportteamet.
5. 5
   Lanserade till 10 % av användarna bakom en flagga

   Rullade tyst ut till en del av kontona, följde riktiga samtal i två veckor, fixade det som gick sönder och breddade sedan utrullningen.

Resultaten — och det som överraskade oss

Efter att assistenten varit live för alla i ungefär tre månader var bilden tydlig. Vi ger er avrundade, illustrativa siffror — riktningen betyder mer än decimalerna.

Supportsiffran var den vi hade lovat, och den levererade: drygt hälften av de upprepade ärendena slutade helt enkelt komma in, och teamet på två fick tillbaka sin vecka för att hantera de ärenden som verkligen behövde en människa. Bra resultat, precis som utlovat.

Men resultatet som faktiskt överraskade grundaren var ett som vi inte alls hade optimerat för. Eftersom assistenten svarade på "hur gör jag X"-frågor hela dagarna pekade den naturligt användare mot den begravda, klibbiga funktionen — den som var knuten till retention. Vi hade inte byggt aktiveringsassistenten än. Supportboten gjorde tyst en del av dess jobb som en bieffekt, helt enkelt genom att vara hjälpsam och produktmedveten. Nya användare hittade funktionen veckor tidigare än förut.

Vad vi skulle säga till nästa team

Om ni är ett SaaS-team som stirrar på samma mening "vi borde lägga till en AI-assistent", finns det några saker från det här projektet som gäller långt bortom det.

• Skilj på problemen innan ni bygger. "AI-chatbot" döljer nästan alltid två eller tre distinkta jobb som vill ha olika design.
• Börja med användningsfallet där ett felaktigt svar kostar minst. Att avvärja support är ett nästan perfekt första drag; reservlösningen är status quo.
• Lägg det mesta av er ansträngning på innehållet, inte modellen. Förankring i rena, aktuella data är det som gör en assistent pålitlig.
• Gör 'jag vet inte' till en funktion, inte ett misslyckande. En ärlig överlämning bygger det förtroende som får användarna att luta sig mot det boten gör bra.
• Lansera bakom en flagga till en liten del först. Riktiga samtal lär er saker som ingen demo någonsin gör.

Vanliga frågor