Hoe wij een AI-assistent aan een SaaS-platform toevoegden — zonder het stuk te maken

Elk SaaS-team waarmee we praten zegt uiteindelijk dezelfde zin hardop: "We zouden hier een AI-assistent in moeten zetten." Soms komt de druk van de board, soms van de lancering van een concurrent, soms is het oprecht. Het interessante is nooit het idee — bijna iedereen heeft het idee. Het interessante is de kloof tussen die zin en een functie waar echte gebruikers daadwerkelijk op vertrouwen. Dit is het verhaal van één team dat die kloof overbrugde, en de weinig glamoureuze beslissingen die hen daar brachten.

Even een korte kanttekening vooraf: we hebben de klant geanonimiseerd en de cijfers afgerond. Het is een klein, winstgevend B2B-SaaS-bedrijf — minder dan twintig mensen — dat een workflowtool verkoopt aan operationele teams. We hebben genoeg details veranderd dat u ze niet zult herkennen, maar de vorm van het project is precies zoals het gebeurde. De cijfers zijn illustratief, niet geauditeerd; we tonen u liever het patroon dan dat we een grafiek mooier maken dan hij is.

We schrijven dit op omdat het project een bijna perfect voorbeeld is van hoe deze dingen echt verlopen. Het ging niet zoals de kickoff-deck had beloofd. Het ging beter — maar alleen omdat we bereid waren de eerste versie weg te gooien.

De situatie: twee problemen in één kostuum

Toen de oprichter voor het eerst contact opnam, was de vraag simpel: "We willen een AI-chatbot in de app." Daar beginnen de meeste projecten, en daar gaan de meeste ook stilletjes de mist in. "AI-chatbot" is geen doel, het is een vorm. Onze eerste taak was dus uitzoeken welk probleem de chatbot moest oplossen — en of het überhaupt om één probleem ging.

Dat was niet zo. Onder die ene vraag zaten twee compleet verschillende pijnpunten. Het eerste was supportdruk: een klantenserviceteam van twee personen verdronk in herhalende tickets — "hoe exporteer ik dit", "waar staat de instelling daarvoor", "waarom draaide mijn rapport niet". Ruwweg 60% van de binnenkomende tickets waren vragen die al ergens in hun helpdocumentatie beantwoord waren. Het tweede pijnpunt was stiller en duurder: activatie. Hun product had een werkelijk krachtige functie die drie klikken diep verborgen zat en die bijna niemand zelf ontdekte. Gebruikers die haar vonden, bleven jarenlang. Gebruikers die haar niet vonden, haakten binnen de eerste twee maanden af.

Hetzelfde kostuum, twee problemen. En ze trokken elk een andere kant op. Een supportbot wil vragen afvangen en zich uit de weg maken. Een activatie-assistent wil gesprekken starten en mensen duwen naar dingen waar ze niet om vroegen. Als we "een AI-chatbot" hadden gebouwd zonder deze te scheiden, hadden we iets gebouwd dat beide taken slecht deed.

Terugschalen naar iets dat we konden afmaken

Geconfronteerd met twee problemen is de verleiding om een grootse assistent te bouwen die beide vanaf dag één aankan. We hebben het team daarvan afgepraat. Niet omdat de visie verkeerd was, maar omdat een zes maanden durende "alles-assistent" precies het soort project is dat te laat oplevert, geen indruk maakt en iedereen voor de komende twee jaar nerveus maakt over AI.

Dus kozen we er één. We kozen eerst voor support afvangen, om drie saaie maar doorslaggevende redenen. Het had een helder, meetbaar doel — het aantal tickets. Het gebruikte content die al bestond — hun helpdocumentatie en oude tickets. En als het onderpresteerde, was de schade klein: een gebruiker die geen goed antwoord kreeg, deed simpelweg wat hij al deed en opende een ticket. Laag risico, snelle feedback, eerlijke maatstaf. Dat is elke keer weer een goede eerste AI-functie.

De activatie-assistent verdween niet — we parkeerden hem, op papier, met een duidelijke notitie: fase twee, zodra de retrieval-laag bewezen is. Die ene beslissing heeft het project waarschijnlijk gered. Ze gaf het team een eindstreep die ze daadwerkelijk in weken konden halen in plaats van kwartalen.

Het eerste prototype dat we bouwden — en verwijderden

Hier komt het deel dat de meeste case studies weglaten. Ons eerste werkende prototype was, om het vriendelijk te zeggen, niet goed. We deden het voor de hand liggende: we koppelden de helpartikelen van het product aan een large language model, voegden een chatvenster toe en lieten gebruikers vragen stellen. In de demo zag het er magisch uit. In echte tests viel het uiteen op een heel specifieke, heel leerzame manier.

Het model had het zelfverzekerd mis. Gevraagd naar een instelling die zes maanden eerder was hernoemd, verzon het vrolijk het oude menupad. Gevraagd naar een functie in een hoger abonnement, legde het uit hoe je die gebruikte — aan een klant die er geen toegang toe had. Elk antwoord klonk gezaghebbend, wat de foute antwoorden erger maakte dan helemaal geen antwoord. Een supportbot die beleefd liegt, vermindert geen tickets; hij creëert bozere.

We hadden het kunnen verdoezelen met prompt-aanpassingen. In plaats daarvan deden we iets dat als een stap terug voelde en de hele wedstrijd bleek te zijn: we gooiden het eerste prototype weg en herbouwden het rond een strikte regel — de assistent mag alleen antwoorden vanuit bronnen die hij kan citeren, en moet anders "ik weet het niet" zeggen.

Wat we uiteindelijk bouwden

De versie die live ging, was bewust bescheiden in wat ze probeerde en strikt in hoe ze zich gedroeg. Onder de motorkap was het een retrieval-gefundeerde assistent: als een gebruiker iets vroeg, doorzocht het systeem eerst een gecureerde, actuele kennisbank, en vroeg vervolgens het model om alleen te antwoorden vanuit wat het vond, met een link terug naar de bron. Geen bron, geen zelfverzekerd antwoord — gewoon een nette overdracht naar een mens.

Drie ontwerpkeuzes deden het meeste zware werk, en geen ervan is spannend. Dat is nu juist de kern — de saaie keuzes bepalen meestal of een AI-functie vertrouwd wordt of stilletjes uitgezet.

Fundering boven slimheid

Elk antwoord was gekoppeld aan een echt, actueel document. We besteedden meer tijd aan het opschonen en structureren van de kennisbank dan aan het afstellen van het model. Weinig glamoureus, en veruit het meest hefboomwerkende werk in het project. Een middelmatig model op uitstekende, goed onderhouden content verslaat een briljant model op een verouderde rommel.

Een soepele overdracht

Als de assistent niet zeker was, gokte hij niet. Hij zei het en bood een route van één klik naar een mens — waarbij hij de gesprekscontext meenam zodat de gebruiker zichzelf nooit hoefde te herhalen. Tegen de intuïtie in maakte dit dat mensen de bot méér gingen vertrouwen: een assistent die zijn grenzen toegeeft, voelt eerlijk, en ze leunden op hem voor de makkelijke 60% juist omdat hij aan de kant stapte bij de moeilijke 40%.

Bewust van wie de vraag stelt

Omdat hij in het product zelf leefde, wist de assistent het abonnement van de gebruiker, diens rol en waar diegene zich in de app bevond. Zo legde hij nooit een functie uit waar iemand geen toegang toe had, en kon hij zeggen "de knop die u zoekt staat op het scherm waar u al bent." Dat productbewustzijn is het echte voordeel van een in-app-assistent boven een generieke chatbot die op een marketingsite geplakt is.

1. 1
   De kennisbank opgeschoond en gestructureerd

   Elk helpdocument doorgelicht, de verouderde geschrapt en de rest getagd per abonnement en functie. Dit was week één, en het was de belangrijkste week.
2. 2
   De retrieval-laag gebouwd

   Eerst zoeken, dan pas antwoorden. Het model kreeg alleen geverifieerde, actuele content te zien — en kreeg de instructie alles te weigeren wat het niet in een bron kon funderen.
3. 3
   Productcontext ingebouwd

   De assistent gekoppeld aan het abonnement, de rol en het huidige scherm van de gebruiker, zodat antwoorden op maat waren en nooit wezen naar functies die diegene niet kon gebruiken.
4. 4
   De eerlijke terugvaloptie ontworpen

   Het pad 'ik weet het niet zeker — hier is een mens' als volwaardige functie gebouwd, met de volledige gesprekscontext overgedragen aan het supportteam.
5. 5
   Uitgerold naar 10% van de gebruikers achter een flag

   Stilletjes uitgerold naar een deel van de accounts, twee weken echte gesprekken bekeken, gerepareerd wat brak, en toen de uitrol verbreed.

De resultaten — en het cijfer dat ons verraste

Nadat de assistent ongeveer drie maanden voor iedereen live was, was het beeld duidelijk. We geven u afgeronde, illustratieve cijfers — de richting telt meer dan de decimalen.

Het supportcijfer was het cijfer dat we hadden beloofd, en het leverde: iets meer dan de helft van de herhalende tickets kwam simpelweg niet meer binnen, en het team van twee kreeg hun week terug om de gevallen aan te pakken die écht een mens nodig hadden. Goede uitkomst, precies zoals afgesproken.

Maar het resultaat dat de oprichter echt verraste, was er een waar we helemaal niet op geoptimaliseerd hadden. Omdat de assistent de hele dag "hoe doe ik X"-vragen beantwoordde, wees hij gebruikers vanzelf steeds naar die verborgen, klevende functie — die met de retentie te maken had. We hadden de activatie-assistent nog niet gebouwd. De supportbot deed stilletjes een stuk van diens werk als bijeffect, gewoon door behulpzaam en productbewust te zijn. Nieuwe gebruikers vonden de functie weken eerder dan voorheen.

Wat we het volgende team zouden vertellen

Als u een SaaS-team bent dat naar diezelfde zin "we zouden een AI-assistent moeten toevoegen" staart, zijn er een paar dingen uit dit project die veel breder gelden dan alleen dit geval.

• Scheid de problemen voordat u bouwt. "AI-chatbot" verbergt bijna altijd twee of drie verschillende taken die om verschillende ontwerpen vragen.
• Begin met de toepassing waar een fout antwoord het minst kost. Support afvangen is een bijna perfecte eerste zet; de terugvaloptie is de status quo.
• Reserveer het meeste van uw inspanning voor de content, niet het model. Fundering op schone, actuele data maakt een assistent betrouwbaar.
• Maak van 'ik weet het niet' een functie, geen falen. Een eerlijke overdracht bouwt het vertrouwen op dat gebruikers laat leunen op de delen die de bot wél goed doet.
• Rol eerst achter een flag uit naar een klein deel. Echte gesprekken leren u dingen die geen enkele demo ooit doet.

Veelgestelde vragen