I ungefär femton år var standardmodellen för B2B-mjukvara enkel: räkna licenserna, multiplicera med ett belopp, skicka fakturan. Den fungerade eftersom värdeenheten var en människa som öppnade en app. Loggade människan in levererades värde. Gjorde hon inte det hände inte särskilt mycket åt något håll.
AI har brutit den ekvationen. Människorna finns kvar, men de utför inte längre merparten av arbetet. En enskild kund kan trigga miljontals inferensanrop i en vecka, köra agenter över natten medan teamet sover eller lämna över ett helt arbetsflöde till något som inte behöver någon inloggning alls. Det kan du inte fakturera rättvist per licens, och marknaden vet det.
Värdeenheten har flyttat
Fråga vilken grundare som helst som bygger en AI-produkt i dag vad de faktiskt säljer, och du får en annan lista än du hade fått för två år sedan. Bearbetade tokens. Tolkade dokument. Genomförda agentkörningar. Lösta ärenden. Minuter av transkribering. Lyckade klassificeringar. Det här är inte närmevärden för värde – det är värdet.
Den förskjutningen får konsekvenser för prissättningen:
- Förbrukningen är ojämn och svår att förutse, så platta paket antingen läcker marginal eller skräms bort kunder.
- Kostnaden för sålda varor är verklig och rörlig. En licens kostar leverantören inget extra. En miljon tokens gör det.
- Kunderna vill se vad de betalar för, på samma detaljnivå som de förbrukar det.
- Avtal paketerar i allt högre grad åtaganden, överförbrukning, credits och förbetalda pooler i ett och samma avtal.
Merparten av all faktureringsinfrastruktur konstruerades aldrig för något av detta. Den konstruerades för att skicka samma faktura varje månad med en aning annorlunda radtext.
Åtkomstbaserat, användningsbaserat, utfallsbaserat
Det hjälper att se prissättning som ett spektrum snarare än ett antingen–eller. I ena änden finns åtkomst: du betalar för att släppas in. I mitten finns ren användning: du betalar per token, per anrop, per körning. I den andra änden finns utfall: du betalar när jobbet är gjort, ärendet löst, intäkten tillskriven.
Nästan inget AI-SaaS-bolag lever på en enda punkt i det spektrumet. Samma kund vill ofta ha en förutsägbar grundavgift, en pott inkluderad användning, mätt överförbrukning ovanpå det och en separat utfallskopplad bonus för de mest värdefulla åtgärderna. I Plocks data är den här hybridformen med stor marginal den vanligaste strukturen våra kunder landar i – ett prenumerationsgolv med användning staplad ovanpå.
Att designa modellerna är inte det svåra. Att köra dem korrekt, månad efter månad, utan att ett driftteam lappar kalkylblad, är det.
Vad en modern faktureringsstack faktiskt måste klara
Om prissättningen har flyttat från ”vem har en licens” till ”vad hände, hur mycket av det och när”, måste faktureringssystemet följa med. I praktiken betyder det att tre saker måste lösas tillsammans, inte var för sig.
Samla in användning medan den sker
Traditionella prenumerationsverktyg kör ett skript vid månadens slut och hoppas att siffrorna stämmer. Den takten passar illa för AI-produkter, där en topp på en tisdag redan kan vara kvartalets viktigaste kommersiella händelse. Plock gör tvärtom: användningen hämtas löpande från kundens egna produktdata, formas till namngivna mätvärden och registreras i takt med att händelserna kommer in. När någon frågar finns siffran redan.
Det är samma tänk du ser på vår Charging-sida – produktdata i realtid, direkt från källan, i stället för en nattlig batch.
Modellera priser så som produkten faktiskt fungerar
Den andra delen är flexibilitet i själva prismodellen. Ett prispaket i Plock kan vara fast eller förbrukningsbaserat, faktureras per enhet eller i trappsteg, med nivåer som är graderade, volymbaserade eller av bulktyp. Varje nivå har sin egen enhetspris, fasta avgift och användningsgräns. Det är inte en lista med pristrick – det är det ordförråd du behöver för att beskriva exempelvis: de första 100 000 tokens gratis, nästa 900 000 till ett pris, allt däröver till ett annat, med en plattformsavgift ovanpå.
Om din prismodell inte kan beskrivas i ditt faktureringssystem finns den inte. Då bor den i ett kalkylblad, och kalkylblad förlorar.
När prissättningen faktiskt kan modelleras i det system som debiterar kunden förändras två saker. Experiment slutar vara skrämmande, för du kan se utfallet av en prisändring mot verklig historisk användning innan du släpper den. Och avtalsförhandlingar slutar producera unika snöflingor som ingen kan fakturera utan manuellt handpåläggande.
Gör användning till en signal, inte bara en debitering
Den sista delen är den som de flesta faktureringsleverantörer fortfarande missar. Användningsdata är inte bara råvaran för fakturor – den är den tidigaste och renaste signalen om vad som händer inne i kontot. En kund som bränner sin inkluderade pott redan dag tio är antingen en churn-risk eller en självklar upsell, och skillnaden spelar roll. I Plock matar samma användningsdata som ligger till grund för fakturan också kundhälsa, expansion och signaldetektering. En pipeline, en sanning, använd av ekonomi och success-teamet parallellt.
Så ser det ut i praktiken
För team som bygger AI-funktioner är den praktiska slutsatsen den här. Om du fortfarande skruvar fast användningsprissättning ovanpå ett licensbaserat verktyg kommer du snabbt att känna skarvarna: avstämningar som glider, diskussioner om vilken export som är rätt, ett månadsbokslut som tar en vecka. Om du i stället utgår från insamling av användning i realtid och modellerar priserna ovanpå den försvinner mycket av avstämningen, för huvudboken var redan rätt den 3:e.
Inget av detta tar bort de svåra kommersiella frågorna. Du måste fortfarande bestämma vad som ska mätas, vad som ska paketeras, vad som ska ges bort och hur du pratar om det. Men infrastrukturen slutar vara flaskhalsen, och prissamtalet flyttar tillbaka dit det hör hemma – mellan dig och din kund.
Om du funderar över hur din AI-produkt borde prissättas, eller vill forma om en åtkomstbaserad modell till något användningsmedvetet, vill vi gärna höra om det. Läs mer på vår sida om Charging, eller hör av dig för en genomgång på era egna data.