Sådan tilføjede vi en AI-assistent til en SaaS-platform — uden at ødelægge den

Ethvert SaaS-team, vi taler med, siger før eller siden den samme sætning højt: "Vi burde lægge en AI-assistent ind her." Nogle gange er det pres fra bestyrelsen, nogle gange en konkurrents lancering, nogle gange er det ægte. Det interessante er aldrig idéen — næsten alle har idéen. Det interessante er kløften mellem den sætning og en funktion, som ægte brugere faktisk stoler på. Dette er historien om ét team, der krydsede den, og de lidet glamourøse beslutninger, der bragte dem derhen.

En kort bemærkning, før vi begynder: vi har anonymiseret kunden og rundet tallene af. Det er et lille, profitabelt B2B-SaaS-selskab — under tyve ansatte — der sælger et workflow-værktøj til driftsteams. Vi har ændret nok detaljer til, at du ikke genkender dem, men projektets form er præcis, som det skete. Tallene er illustrative, ikke reviderede; vi viser dig hellere mønsteret end at pynte på et diagram.

Vi skriver dette ned, fordi projektet er et næsten perfekt eksempel på, hvordan den slags faktisk forløber. Det gik ikke, som kickoff-præsentationen sagde. Det gik bedre — men kun fordi vi var villige til at kassere den første version.

Situationen: to problemer i ét kostume

Da grundlæggeren første gang henvendte sig, var anmodningen enkel: "Vi vil have en AI-chatbot i appen." Det er dér, de fleste projekter starter, og også dér, de fleste stille går galt. "AI-chatbot" er ikke et mål, det er en form. Vores første opgave var derfor at finde ud af, hvilket problem chatbotten skulle løse — og om det overhovedet var ét problem.

Det var det ikke. Under den ene anmodning lå to helt forskellige smerter. Den første var supportbelastning: et kundeserviceteam på to personer druknede i gentagne henvendelser — "hvordan eksporterer jeg det her", "hvor er indstillingen til det", "hvorfor kørte min rapport ikke". Omkring 60 % af de indkommende henvendelser var spørgsmål, der allerede var besvaret et sted i hjælpedokumentationen. Den anden smerte var mere stille og dyrere: aktivering. Produktet havde en virkelig kraftfuld funktion begravet tre klik nede, som næsten ingen opdagede på egen hånd. Brugere, der fandt den, blev i årevis. Dem, der ikke gjorde, forsvandt inden for de første to måneder.

Samme kostume, to problemer. Og de trak i hver sin retning. En supportbot vil afvise spørgsmål og komme af vejen. En aktiveringsassistent vil starte samtaler og skubbe folk mod ting, de ikke bad om. Havde vi bygget "en AI-chatbot" uden at adskille disse, havde vi bygget noget, der gjorde begge job dårligt.

Ned til noget, vi kunne gøre færdigt

Stillet over for to problemer er fristelsen at bygge en storslået assistent, der klarer begge fra dag ét. Vi talte teamet fra det. Ikke fordi visionen var forkert, men fordi en seks måneders "alt-assistent" er præcis den slags projekt, der leverer for sent, falder til jorden og gør alle nervøse for AI de næste to år.

Så vi valgte ét. Vi valgte at afvise support først, af tre kedelige, men afgørende grunde. Det havde et klart, målbart mål — antal henvendelser. Det brugte indhold, der allerede fandtes — hjælpedokumentationen og tidligere henvendelser. Og hvis det underpræsterede, var nedsiden lille: en bruger, der ikke fik et godt svar, gjorde ganske enkelt det, de allerede gjorde, og oprettede en henvendelse. Lav risiko, hurtig feedback, ærligt måltal. Det er en god første AI-funktion, hver gang.

Aktiveringsassistenten forsvandt ikke — vi parkerede den, på papiret, med en klar note: fase to, når genfindingslaget er bevist. Den ene beslutning reddede formentlig projektet. Den gav teamet en målstreg, de faktisk kunne nå på uger i stedet for kvartaler.

Den første prototype, vi byggede — og slettede

Her er den del, de fleste case studies udelader. Vores første fungerende prototype var, for at sige det pænt, ikke god. Vi gjorde det oplagte: koblede produktets hjælpeartikler til en stor sprogmodel, tilføjede et chatvindue og lod brugerne stille spørgsmål. I demoen så det magisk ud. I ægte test faldt det fra hinanden på en meget specifik, meget lærerig måde.

Modellen tog selvsikkert fejl. Spurgt om en indstilling, der var omdøbt et halvt år tidligere, opfandt den muntert den gamle menusti. Spurgt om en funktion på et højere abonnement forklarede den, hvordan man brugte den — til en kunde, der ikke havde adgang. Hvert svar lød autoritativt, hvilket gjorde de forkerte værre end slet intet svar. En supportbot, der lyver høfligt, reducerer ikke henvendelser; den skaber mere vrede.

Vi kunne have dækket over det med prompt-justeringer. I stedet gjorde vi noget, der føltes som et skridt tilbage og viste sig at være hele spillet: vi kasserede den første prototype og byggede den om omkring en streng regel — assistenten må kun svare ud fra kilder, den kan citere, og skal ellers sige "det ved jeg ikke".

Hvad vi faktisk byggede

Den version, der blev lanceret, var bevidst beskeden i, hvad den forsøgte, og streng i, hvordan den opførte sig. Under motorhjelmen var det en genfindingsforankret assistent: når en bruger spurgte om noget, søgte systemet først i en kurateret, opdateret vidensbase og bad derefter modellen svare kun ud fra det, den fandt, med et link tilbage til kilden. Ingen kilde, intet selvsikkert svar — bare en ryddelig overdragelse til et menneske.

Tre designvalg klarede det meste af det tunge arbejde, og ingen af dem er spændende. Det er netop pointen — de kedelige valg afgør som regel, om en AI-funktion bliver stolet på eller stille slået fra.

Forankring frem for smart

Hvert svar var knyttet til et ægte, aktuelt dokument. Vi brugte mere tid på at rydde op i og strukturere vidensbasen end på at finjustere modellen. Lidet glamourøst og langt det mest udslagsgivende arbejde i projektet. En middelmådig model på fremragende, velvedligeholdt indhold slår en genial model på et forældet rod.

En smidig overdragelse

Når assistenten ikke var sikker, gættede den ikke. Den sagde det og tilbød en rute på ét klik til et menneske — og bar samtalekonteksten med, så brugeren aldrig behøvede at gentage sig selv. Mod intuitionen fik dette folk til at stole mere på botten: en assistent, der indrømmer sine grænser, virker ærlig, og de lænede sig op ad den til de lette 60 % netop, fordi den trak sig ved de svære 40 %.

Bevidst om, hvem der spørger

Fordi den levede inde i produktet, kendte assistenten brugerens abonnement, rolle og hvor de var i appen. Sådan forklarede den aldrig en funktion, de ikke havde adgang til, og den kunne sige "knappen, du leder efter, er på den skærm, du allerede er på." Den produktbevidsthed er den ægte fordel ved en assistent i appen frem for en generisk chatbot skruet fast på en marketingside.

1. 1
   Ryddede op i og strukturerede vidensbasen

   Gennemgik hvert hjælpedokument, ryddede de forældede og mærkede resten efter abonnement og funktion. Det var uge ét, og det var den vigtigste uge.
2. 2
   Byggede genfindingslaget

   Søg først, svar bagefter. Modellen så kun verificeret, aktuelt indhold — og fik besked på at afvise alt, den ikke kunne forankre i en kilde.
3. 3
   Koblede produktkontekst på

   Forbandt assistenten til brugerens abonnement, rolle og aktuelle skærm, så svarene var tilpassede og aldrig pegede på funktioner, de ikke kunne bruge.
4. 4
   Designede den ærlige reserveløsning

   Byggede ruten 'jeg er ikke sikker — her er et menneske' som en fuldgyldig funktion, med hele samtalekonteksten overdraget til supportteamet.
5. 5
   Lancerede til 10 % af brugerne bag et flag

   Rullede stille ud til en del af kontiene, fulgte ægte samtaler i to uger, rettede det, der brød, og udvidede så udrulningen.

Resultaterne — og det, der overraskede os

Efter at assistenten havde været live for alle i omkring tre måneder, var billedet klart. Vi giver dig afrundede, illustrative tal — retningen betyder mere end decimalerne.

Supporttallet var det, vi havde lovet, og det leverede: lidt over halvdelen af de gentagne henvendelser holdt ganske enkelt op med at komme, og teamet på to fik deres uge tilbage til at håndtere de sager, der virkelig krævede et menneske. Godt resultat, præcis som aftalt.

Men det resultat, der faktisk overraskede grundlæggeren, var et, vi slet ikke havde optimeret efter. Fordi assistenten svarede på "hvordan gør jeg X"-spørgsmål hele dagen, pegede den naturligt brugere mod den begravede, klæbrige funktion — den, der var knyttet til fastholdelse. Vi havde ikke bygget aktiveringsassistenten endnu. Supportbotten gjorde stille en del af dens arbejde som en bivirkning, ganske enkelt ved at være hjælpsom og produktbevidst. Nye brugere fandt funktionen uger tidligere end før.

Hvad vi ville sige til det næste team

Er du et SaaS-team, der stirrer på den samme sætning "vi burde tilføje en AI-assistent", er der et par ting fra dette projekt, der gælder langt bredere end det.

• Adskil problemerne, før du bygger. "AI-chatbot" skjuler næsten altid to eller tre distinkte job, der vil have forskellige design.
• Start med anvendelsen, hvor et forkert svar koster mindst. At afvise support er et næsten perfekt første træk; reserveløsningen er status quo.
• Afsæt størstedelen af din indsats til indholdet, ikke modellen. Forankring på rene, aktuelle data er det, der gør en assistent troværdig.
• Gør 'det ved jeg ikke' til en funktion, ikke en fiasko. En ærlig overdragelse opbygger den tillid, der får brugerne til at læne sig op ad det, botten gør godt.
• Lancér bag et flag til en lille del først. Ægte samtaler lærer dig ting, ingen demo nogensinde gør.

Ofte stillede spørgsmål