Hoe je AI-features in je SaaS prijst zonder later te moeten verbouwen

Elke gids over AI-prijzen geeft je hetzelfde menu. Per seat. Per credit. Per token. Per resultaat. Kies er een, zegt het artikel, en je margeprobleem is opgelost.

Het menu is niet het moeilijke deel. Een prijsmodel is een belofte over wat je kunt meten, en de meeste SaaS-producten kunnen die belofte niet waarmaken. Je kunt op maandag besluiten om per opgelost ticket te factureren, en op dinsdag ontdekken dat niets in je codebase weet welke klant welke modelaanroep heeft veroorzaakt, wat die aanroep kostte, of hoe je hem stopt wanneer een account op hol slaat. De prijspagina verander je in een middag. Het systeem eronder kost een kwartaal.

De bruikbare vraag is dus niet welk van de 5 modellen het beste is. Het is welke modellen je product op dit moment mag hebben, en wat je zou moeten bouwen om de andere te ontsluiten.

Dit is geschreven voor oprichters, CTO's en productleiders bij B2B SaaS-bedrijven die al betalende klanten hebben, en die nu AI bouwen op een product dat geprijsd werd toen een extra request nog niets kostte. Als je nog voor de lancering zit en een getal zoekt voor een pitchdeck, is dit meer detail dan je nodig hebt.

In dit artikel leer je waarom AI de prijsaannames breekt waarop je product is gebouwd, welke 4 capaciteiten bepalen welke prijsmodellen daadwerkelijk voor je beschikbaar zijn, wat elk van de 5 gangbare modellen van je code eist, een uitgewerkt voorbeeld met echte cijfers, en in welke volgorde je het bouwt zodat je dit maar een keer hoeft te doen.

‍

Belangrijkste punten

• Je prijsmodel is een architectuurbeslissing. Je kunt alleen factureren voor wat je product kan meten, toewijzen, afdwingen en uitleggen.

• Brutomarges op AI-producten liggen rond 53% in 2026, tegenover 80% tot 90% voor klassieke SaaS. De oude rekensom met vaste tarieven gaat dus niet meer op.

• Het gevaarlijke scenario is niet een hoge rekening. Het is een trage, onzichtbare margedaling die je aan geen enkele specifieke klant kunt toeschrijven.

• Bouw eerst 4 capaciteiten: kostentoewijzing per aanroep, meting per tenant en per feature, handhaving op het moment van het request, en margetelemetrie die je kunt bevragen.

• Elk prijsmodel heeft een technische voorwaarde. Prijzen op basis van resultaat vraagt alle 4 de capaciteiten plus een afgesproken definitie van het resultaat.

• Begin op de trede die je code al aankan, lever hem op, en klim daarna verder. Een gemeten model dat je niet kunt afdwingen is slechter dan een vast plan dat je wel aankunt.

• Limieten horen in het request-pad, niet op de factuur. Overschrijding die je aan het eind van de maand ontdekt is verlies dat je al hebt genomen.

‍

Waarom AI-features het prijsmodel breken waarop je SaaS is gebouwd

Klassieke SaaS-prijzen rusten op een stille aanname: de marginale kosten om nog een gebruiker, of nog een actie, te bedienen zijn vrijwel nul. Die aanname is precies wat prijzen per seat laat werken.

AI haalt die aanname weg. Elke samenvatting, elke extractie, elke agent-run heeft echte rekenkosten die op je factuur belanden, of de klant de output nu nuttig vond of niet. De economie keert om. Je power users, de mensen waar je hele retentieverhaal op steunt, worden je duurste accounts.

De cijfers bevestigen dat op categorieniveau. Het 2026 State of AI-rapport van ICONIQ zet de gemiddelde brutomarge op AI-producten op 45% in 2025, oplopend naar een verwachte 53% in 2026 en 59% in 2027. Bessemer verwoordt hetzelfde gat botter in de AI pricing and monetization playbook van februari 2026: 50% tot 60% brutomarge voor AI-bedrijven tegenover 80% tot 90% voor traditionele software. Die marges verbeteren naarmate routing en caching volwassen worden, maar ze gaan niet terug naar 90%.

En dit is het deel waar teams op stuklopen. De schade komt niet binnen als een schokkende factuur. Ze komt binnen als drift. Je gemengde brutomarge zakt het ene kwartaal 2 punten en het volgende 3. Niemand kan de oorzaak aanwijzen, omdat een vast plan per seat elk account bewust tot een gemiddelde samenvoegt. Tegen de tijd dat iemand vraagt welke klanten verlieslatend zijn, heb je een jaar aan contracten geprijsd op rekenwerk dat niet meer klopt.

De teams die hier goed mee omgaan zijn niet de teams die het slimste model kozen. Het zijn de teams die binnen 30 seconden kunnen antwoorden welke accounts onder water staan en hoe diep.

‍

De echte beperking is wat je product kan meten, niet welk model je het liefst wilt

Prijsadvies behandelt modelkeuze meestal als een strategische oefening. Bestudeer de waardemaatstaf van de klant, breng prijs en waarde op een lijn, en kies daarnaar.

Een prijsmodel is een reeks beweringen die je systeem moet kunnen onderbouwen. Reken je per credit, dan beweer je dat je credits nauwkeurig kunt tellen, per tenant, vrijwel realtime, en dat je het volgende request weigert wanneer het saldo op nul staat. Reken je per resultaat, dan beweer je dat je het resultaat kunt detecteren, kunt bewijzen dat het gebeurd is, en die telling kunt verdedigen wanneer een klant de factuur betwist. Niets daarvan is een prijsbeslissing. Het is allemaal engineering.

Het patroon dat we steeds terugzien in AI-projecten ziet er zo uit. Een team kiest voor credits. Klinkt eenvoudig genoeg, een teller en een saldo. Dan begint de inventarisatie. Modelaanroepen blijken vanuit 6 verschillende plekken te komen: de webapp, twee achtergrondworkers, een webhook-handler, een interne beheertool en een nachtelijke batchjob die iemand 2 jaar geleden schreef. Drie daarvan hebben helemaal geen gebruiker of tenant aan het request gekoppeld, omdat niets verderop dat nodig had toen ze geschreven werden. Kosten zijn niet aan een account toe te wijzen omdat de informatie nooit zo ver werd meegedragen. Wat op een prijswijziging leek wordt een refactor over de helft van je services.

Dat is het hele inzicht. Je kunt alleen factureren voor wat je kunt meten, toewijzen, afdwingen en uitleggen. Vier werkwoorden, en elk prijsmodel heeft een deel daarvan nodig.

• Meten: je kent de token- of rekenkosten van een afzonderlijke bewerking.

• Toewijzen: je kunt die kosten koppelen aan een specifieke tenant, gebruiker en feature.

• Afdwingen: je kunt het volgende request weigeren of afknijpen wanneer een limiet bereikt is.

• Uitleggen: je kunt een klant een specificatie per regel tonen die hij accepteert.

Mis er een, en een prijsmodel dat er op een slide prima uitzag wordt onfactureerbaar, niet afdwingbaar of onverdedigbaar in een verlenggesprek.

‍

De 4 capaciteiten die je prijsopties bepalen

Dit zijn de concrete dingen om te bouwen. Geen daarvan is exotisch, en ze zijn allemaal veel goedkoper toe te voegen voordat een AI-feature live gaat dan wanneer 600 accounts hem al gebruiken.

1. Kostentoewijzing op elke modelaanroep

Elke aanroep naar een model zou moeten teruggeven, en opslaan, wat hij kostte. Geen schatting die je maandelijks uit de factuur van je provider afleidt, maar de werkelijke inputtokens, outputtokens, modelnaam en berekende kosten, vastgelegd op het moment van de aanroep, samen met de tenant-id, gebruikers-id, featurenaam en request-id.

Dit klinkt vanzelfsprekend en het ontbreekt heel vaak. Teams loggen dat een aanroep plaatsvond en of hij slaagde. Ze loggen niet wat hij kostte, omdat in de prototypefase niemand op de rekening lette. Dit achteraf inbouwen is de meest waardevolle werkdag in de hele exercitie, en het is meestal een wrapper om je modelclient plus een tabel.

Het detail dat telt: wijs toe op het punt van de aanroep, niet op het punt van de gebruikersactie. Een enkele gebruikersactie kan uitwaaieren naar 9 modelaanroepen verspreid over een retry, een herrangschikkingsstap en een validatieronde. Registreer je alleen de gebruikersactie, dan onderschat je de echte kosten met een factor die je pas ontdekt wanneer de factuur van je provider het niet met je eens is.

2. Meting per tenant en per feature

Toewijzing geeft je regels. Meting maakt van die regels een lopend saldo waarop je kunt handelen: dit account heeft zoveel eenheden van deze feature verbruikt in de huidige factuurperiode.

Twee beslissingen bepalen alles daarna. Kies eerst een eenheid die de klant begrijpt. Tokens zijn de verkeerde eenheid om te tonen, omdat geen enkele koper aanvoelt wat 40.000 tokens betekent of zijn eigen verbruik kan voorspellen. Een verwerkt document, een opgelost ticket, een gegenereerd rapport, een uitgeschreven gesprek: dat zijn eenheden waarop een klant kan begroten. Meet intern in tokens, factureer in werkeenheden.

Meet ten tweede per feature, niet alleen per account. Een accounttotaal vertelt je dat een account duur is. Een uitsplitsing per feature vertelt je dat de AI-clausulesamenvatting 80% van de kosten veroorzaakt terwijl hij 10% van het gebruik oplevert, en dat is de zin die daadwerkelijk een roadmap verandert.

3. Handhaving op het moment van het request

Hier stoppen de meeste implementaties te vroeg, en dit is degene die geld kost. Een limiet die je pas controleert wanneer je de factuur opmaakt is geen limiet. Het is een rapport van een verlies dat je al genomen hebt.

Handhaving betekent dat de controle in het request-pad gebeurt, voor de modelaanroep, en dat hij kan weigeren.

Het vraagt ook dat je in producttermen beslist wat er bij de limiet gebeurt. Harde stop met een duidelijke melding. Terugvallen op een goedkoper model. In de wachtrij tot de volgende periode. Automatisch een nieuw blok kopen als de klant daarvoor gekozen heeft. Allemaal redelijk. Stilletjes doorgaan en de kosten opeten is de enige die dat niet is, en het is precies wat er gebeurt wanneer niemand de keuze maakt.

De moeite waard om vanaf het begin in te ontwerpen: de klant moet zijn eigen limiet onder die van jou kunnen zetten. Kopers accepteren verbruiksgebonden prijzen veel makkelijker wanneer zij het plafond bepalen, want hun echte angst is niet de prijs per eenheid, het is een onbegrensde rekening.

4. Margetelemetrie die je kunt bevragen

De laatste capaciteit is voor jou, niet voor de klant. Je moet zonder dataproject kunnen beantwoorden welke accounts deze maand verlieslatend zijn, welke features de gemengde marge omlaag trekken, en hoe de kosten per werkeenheid zich ontwikkelen terwijl je modellen en prompts aanpast.

De praktische versie is een enkele view die verbruikskosten koppelt aan contractomzet per account per maand, met een klein dashboard erbovenop. Kosten per werkeenheid verdienen in de tijd bijzondere aandacht, want dat is het getal dat je vertelt of je engineeringwerk aan caching, routing en promptlengte echt loont, of dat je kosten alleen hebt verplaatst.

Wil je het bredere kostenplaatje hieronder, dan behandelt onze analyse van wat het echt kost om een AI-agent te draaien de componenten die in deze cijfers terugkomen.

‍

Werk je dit uit voor je eigen product? Onze SaaS AI Blueprint loopt dezelfde architectuur- en kostenbeslissingen langs als een checklist die je mee kunt nemen naar je engineeringteam.

‍

De 5 AI-prijsmodellen en wat elk model van je code eist

Met de capaciteiten in beeld wordt de vergelijking van modellen een stuk minder abstract. Elke regel hieronder is een echte voorwaarde, geen voorkeur.

Inbegrepen in het pakket

De AI-feature hoort gewoon bij het pakket, zonder aparte kosten. Het is de snelste route naar de markt en de juiste keuze wanneer de feature een retentiemiddel of een concurrentievinkje is in plaats van een omzetregel, en wanneer het verbruik echt licht en voorspelbaar is.

Het vraagt het minst: toewijzing en telemetrie, zodat je kunt zien wat het je kost. Het draagt het meeste risico, want je hebt geen enkel mechanisme om een account te stoppen dat besluit de feature over zijn hele archief los te laten. Neem het alleen op met een stille interne limiet en een melding wanneer een account daaroverheen gaat.

Seat plus AI-module

Een vaste maandelijkse opslag per seat voor toegang tot de AI-features. Commercieel is dit het makkelijkst te verkopen, omdat het de voorspelbaarheid behoudt waarvoor je kopers al tekenden, en omdat je de prijs kunt verhogen zonder het prijsmodel opnieuw te onderhandelen.

De economie werkt alleen als het verbruik per seat redelijk dicht bij elkaar ligt. Wanneer je zwaarste 5% van de seats 30 keer de mediaan verbruikt, is een vaste opslag een vast tarief geprijsd op de mediaan dat door de staart wordt opgegeten.

Credits of een verbruikspot

Klanten kopen een blok eenheden, in het pakket of daarbovenop, en verbruiken die. Dit is met reden de populairste middenweg: de klant krijgt een begrensd, voorspelbaar getal, en jij krijgt verbruik dat de kosten volgt.

Het vraagt alle 4 de capaciteiten, en het vraagt een credit die staat voor iets wat een koper begrijpt. De meest gemaakte fout is een credit definiëren als een aantal tokens, waarmee je de klant een eenheid geeft die hij niet kan voorspellen. Definieer 1 credit als 1 verwerkt document en de adoptie wordt meteen makkelijker.

Gemeten verbruik

Betalen voor precies wat je verbruikt, achteraf gefactureerd.

De wrijving is commercieel, niet technisch. Inkoopafdelingen houden niet van onbegrensde regels, en een variabele factuur maakt ook jouw omzet moeilijker te voorspellen. In de praktijk werkt vrijwel niemand met pure meting. ICONIQ vond dat bedrijven gemiddeld 1,7 prijsmodellen combineren, en dat verbruiksgebonden prijzen in 6 maanden stegen van 35% naar 42% van de bedrijven. De gebruikelijke vorm is een vaste basis plus gemeten meerverbruik, en daarom is hybride het standaardantwoord geworden.

Op basis van resultaat

Je rekent per resultaat: een opgelost ticket, een gekwalificeerde lead, een succesvol verwerkte claim. Het is het overtuigendste verhaal dat je een koper kunt vertellen, want hij betaalt voor het ding dat hij wilde in plaats van voor de rekenkracht die het produceerde. ICONIQ laat de adoptie stijgen van 18% naar 23%, dus het is echt en het groeit, al is het nog een minderheid.

Het is ook veruit het veeleisendst. Je hebt alle 4 de capaciteiten nodig, plus betrouwbare detectie van het resultaat, plus een definitie van succes die een geschil overleeft. Wanneer een ticket wordt opgelost en 2 dagen later heropend, heb je de vergoeding dan verdiend? Die vraag heeft een antwoord nodig in het contract voordat ze er een nodig heeft in de code, en fout gaan betekent dat elke factuur een onderhandeling wordt.

‍

Een uitgewerkt voorbeeld: een AI-assistent prijzen voor een B2B SaaS

Cijfers maken dit concreet. Neem een SaaS voor contractbeheer met 600 klantaccounts op een pakket van $79 per seat, gemiddeld 7 seats per account, dus ongeveer $553 maandomzet per account. De kosten om te bedienen lagen voor AI rond $55 per account, een comfortabele brutomarge van 90%.

Ze voegen een AI-clausulesamenvatting toe. Elke samenvatting stuurt ongeveer 12.000 inputtokens en geeft ongeveer 900 outputtokens terug. Tegen ongeveer de huidige tarieven voor middenklassemodellen is dat rond 5 cent per samenvatting, alles meegerekend.

Dan verschijnt de verbruiksverdeling, en die is niet normaal. Het mediane account draait 40 samenvattingen per maand, wat $2 kost. De marge gaat van 90% naar 89,6%, onzichtbaar. De bovenste 5% van de accounts draait ongeveer 1.900 samenvattingen per maand. Dat is $95 aan rekenkosten bovenop $55 aan bestaande kosten, tegenover $553 omzet, dus dat account is stilletjes van 90% naar 73% marge gegaan. Een handvol accounts draait 6.000 of meer, tegen ruwweg $300 aan rekenkosten, waarmee ze rond 36% uitkomen.

Over de hele klantenbasis gemengd daalt de gerapporteerde brutomarge ongeveer 4 punten. Op een vast pakket is er nergens een factuurregel die zegt waarom, en geen mechanisme dat het had tegengehouden.

Prijs het nu met de capaciteiten op hun plek. Neem 50 samenvattingen per account per maand op in het bestaande pakket, wat ongeveer $2,50 kost en de mediane gebruiker volledig dekt, zodat de meeste klanten geen verandering en geen nieuwe wrijving zien. Daarboven reken je $0,15 per samenvatting, ruwweg 3 keer de kosten, en laat je elke klant zijn eigen maandplafond zetten met een verstandige standaardwaarde.

Het zware account dat de marge sloopte levert nu 1.850 factureerbare samenvattingen op tegen $0,15, dus $277,50 extra omzet tegenover $95 kosten. Het enige verschil is dat het systeem kon tellen, toewijzen en stoppen.

Let op wat dat mogelijk maakte. Geen slim prijsmodel. Een grootboek, een saldo en een controle in het request-pad.

‍

De prijsladder: begin waar je code staat en klim omhoog

Je hoeft niet meteen bij het meest geavanceerde model uit te komen, en dat proberen loopt meestal slecht af. Een gemeten model dat je niet kunt afdwingen is echt slechter dan een vast pakket dat je wel aankunt, want het wekt bij de klant de verwachting van variabele facturatie zonder de machinerie om eerlijk te factureren of doorgeschoten verbruik te stoppen.

Een verstandige opbouw ziet er zo uit. Lever de feature inbegrepen in het pakket, met toewijzing en telemetrie die vanaf dag 1 draaien en een stille interne limiet. Kijk 60 tot 90 dagen naar echt verbruik, want je aannames over de verdeling kloppen niet en in de staart zit het geld. Zodra je data hebt, introduceer je een module of een inbegrepen tegoed met een zichtbare, afgedwongen fair-use-limiet. Wanneer de spreiding in verbruik het rechtvaardigt, ga je naar credits of een vaste basis plus meerverbruik, geprijsd vanuit je waargenomen kosten per werkeenheid in plaats van een schatting. Pas daarna overweeg je prijzen op resultaat, en alleen waar het resultaat ondubbelzinnig en machinaal vast te stellen is.

Elke trede vereist dat de trede eronder werkt. Dat is het nuttige aan denken in een ladder in plaats van een menu: het vertelt je wat je hierna moet bouwen, en het weerhoudt je ervan je publiekelijk vast te leggen op een model dat je systeem nog niet kan waarmaken.

‍

Hoe wij de meetlaag aanpakken

Wanneer wij AI-features in een bestaand product bouwen, gaat de meetlaag erin voordat de feature live gaat, niet erna. In de praktijk betekent dat een dunne wrapper om elke modelclient die kosten vastlegt met volledige tenant- en featurecontext, een verbruiksgrootboek met een gecachet lopend saldo, een beleidscontrole in het request-pad die kan weigeren of terugschakelen, en een margeoverzicht dat finance kan openen zonder engineering om een query te vragen.

Het is normaal gesproken een klein deel van de totale bouw, en het is het deel dat bepaalt of het prijsgesprek 6 maanden later een strategiediscussie is of een herbouw.

Dit is een vast onderdeel van hoe wij SaaS-ontwikkeling inrichten wanneer AI in het product zit. Het prijsmodel is een commerciële beslissing, en die is van jou. Onze taak is zorgen dat het systeem het model kan dragen waar je op uitkomt, en het volgende model daarna.

‍

5 fouten die het meeste kosten

• Prijzen vanuit je eigen tokenkosten in plaats van vanuit klantwaarde. Kosten bepalen je ondergrens, niet je prijs. Een samenvatting die een jurist 20 minuten bespaart is geen 5 cent waard omdat hij jou 5 cent kostte.

• Tokens tonen als factuureenheid. Kopers kunnen tokens niet voorspellen, dus ze weigeren het model of kopen een keer te veel in en vertrekken. Factureer in werkeenheden en houd tokens intern.

• De limiet behandelen als factuurregel in plaats van als controle tijdens uitvoering. Wordt de limiet niet in het request-pad afgedwongen, dan is het geen limiet.

• Lanceren zonder toewijzing omdat de feature "maar een pilot" is. Pilots worden de prijsbasis. Meet vanaf dag 1, wanneer het een dag kost in plaats van een kwartaal.

• De staart van de verbruiksverdeling negeren. Gemiddelden verbergen precies de accounts die ertoe doen. Reken op het 95e percentiel, want daar zitten zowel je margerisico als je uitbreidingsomzet.

‍

Waar je dit kwartaal begint

De verschuiving die de moeite waard is, gaat van AI-prijzen behandelen als een spreadsheetoefening naar AI-prijzen behandelen als een productcapaciteit. Kies het model dat je systeem vandaag kan waarmaken, meet fatsoenlijk, kijk een kwartaal naar echt verbruik, en klim de ladder op wanneer de data dat zegt. Zo voorkom je dat je twee keer herprijst en dat de tweede keer als een ongeplande refactor binnenkomt.

Helpt het om de bouwkant op papier te hebben, dan zet de SaaS AI Blueprint de architectuur- en kostenbeslissingen op een rij die je moet maken voordat een AI-feature live gaat, in de volgorde waarin ze langskomen.

En als je dit afweegt tegen een lopende roadmap en een tweede mening wilt over op welke trede je eigenlijk staat, plan dan een gratis gesprek met ons team. We kijken naar hoe je AI-features vandaag gemeten worden en wat er nodig is om het prijsmodel te dragen dat je wilt.