ai voor productteams. ai voor productteams betekent een ai-feature inbouwen in de eigen productoppervlakken die gebruikers adopteren en blijven gebruiken. geen demo. een feature met een retentiecijfer en een supporttickettelling.
de meeste productteams hebben al een prototype. je hebt het in een weekend gebouwd met Lovable, Bolt of v0. het zag er geweldig uit in de standup. daarna stagneerde het op weg naar productie.
het gat is niet het model. het gat is alles eromheen. streaming, evals, auditlogging en een plek in het product waar de gebruiker al is. dat is het werk tussen een v0-scherm en een feature die je gebruikers bewaren.
#waarom stagneer je prototype vóór de lancering?
een prototype beantwoordt één vraag: kan het model het. een productiefeature beantwoordt vier meer. streamt het zodat de gebruiker niet naar een laadspinner staart. blijft het correct als de prompt verandert. kun je bewijzen wat het een klant zes weken geleden vertelde. en leeft het waar de gebruiker al werkt, niet achter een apart tabblad.
wat is het verschil tussen een ai-prototype en een productiefeature?
een prototype bewijst dat het model de taak aankan in een demo. een productiefeature voegt streaming toe zodat antwoorden direct aanvoelen, een eval-suite zodat de kwaliteit standhoud als prompts veranderen, auditlogging zodat je kunt bewijzen wat er is gezegd, en in-product-ux zodat gebruikers het adopteren. het prototype is de eenvoudige 20 procent.
#zet je een chatbox erbij of bouw je binnen je eigen oppervlakken?
de standaardkeuze is een zwevende chatbubbel in de hoek. dat is snel om te lanceren. het blijft ook ongebruikt, omdat je gebruiker niet gekomen is om te chatten. die is gekomen om een betaling te sturen, een afschrift te afstemmen of een geschil te openen.
de betere keuze is de ai inbouwen in het oppervlak waar die taak plaatsvindt. een slimme standaardwaarde in het formulier. een uitleg met één klik naast de transactie. een antwoord weergegeven in het deelvenster dat de gebruiker al open had.
we are
stennir bouwt ai in de productoppervlakken die je gebruikers al gebruiken, met de adoptie- en supporttickettelling als bewijs dat het is geland.
we aren't
stennir is niet het team dat een generieke chatbox op je app plakt en dat een ai-feature noemt.
#hoe zag dit eruit voor een series b-fintech?
een series b-fintech kwam bij ons met een klantgerichte ai-assistent gebouwd in Lovable. die beantwoordde vragen in een demo. naar productie kon hij niet. geen streaming, geen manier om kwaliteit te meten, geen audittrail voor een gereguleerd product.
- streaming: antwoorden worden token voor token weergegeven, zodat de gebruiker een antwoord ziet verschijnen in plaats van een laadspinner.
- eval-suite: een vaste reeks echte vragen draait bij elke promptwijziging, zodat de kwaliteit niet stilletjes terugzakt als iemand de systeemprompt bewerkt.
- auditlogging: elk antwoord wordt vastgelegd met de invoer, zodat een gereguleerde fintech kan bewijzen wat een klant is verteld en wanneer.
- in-product-ux: de assistent antwoordt binnen de transactieweergave die de gebruiker al open had, niet in een apart chattabblad.
we hebben het in 5 weken uitgerold naar 100% van de gebruikers. supporttickets voor die feature daalden 60% na de lancering, omdat gebruikers het antwoord in het product kregen in plaats van een ticket in te dienen.
het prototype bewees dat mensen het wilden. de productiebuild is wat ze het bleef gebruiken. de daling van 60% in tickets is het deel waar onze cfo om gaf.
#hoe kader je zo'n build af?
we voeren het uit via de build-service: vaste scope, vaste prijs, en de code is van jou vanaf dag één. je behoudt het prototype dat je al hebt gemaakt in v0, Bolt of Lovable als beginpunt. wij brengen het de rest van de weg naar een feature in jouw product.
als je het patroon voor jouw team wilt, legt de pagina ai voor product uit waar ai zijn plek verdient binnen een product, en de consultancy-praktijk is waar deze builds verlopen. wil je bewijs zien vóór je toezegt. zie het werk.