Usage-based pricing tar bort en bekväm fiktion: att intäkterna kommer i en prydlig månadstakt bara för att produkten säljs som en prenumeration. Så snart förbrukningen kommer in i samtalet förhandlar sälj- och ekonomiteam om två olika saker samtidigt. Köparen vill ha en förutsägbar siffra till sin CFO, enkel att budgetera med. Säljaren vill ha uppsida när det växer. Avtalet måste rymma båda.
Det finns två väl upptrampade former för det avtalet. En förbetald credit-pott som räknas ner i takt med att kunden förbrukar. När kunden når botten kan den inte förbruka tjänsten längre. Vanligt för AI- och API-tjänster. Den andra formen är ett förbetalt åtagande, där användningen avräknas mot en åtagen förbrukning vid varje periods slut. Överskrider kunden åtagandet debiteras den för överförbrukningen. På ett säljblad ser de snarlika ut, men de landar mycket olika i ett faktureringssystem – och ännu mer olika i en säljpipeline.
Två burndowns, samma avsikt
Båda modellerna försöker ge köparen en fast botten och säljaren ett verkligt tak. Skillnaden ligger i risk och tillväxt.
En förbetald credit-burndown ber kunden fondera ett saldo i förväg. Användningshändelser förbrukar saldot under perioden, och påfyllningar sker när potten är tömd. Påfyllningen är ett aktivt kundbeslut, och säljaren kan lämna intäkter på bordet fram till dess. Intäktsredovisningen fördelar förskottet över förbrukningskurvan. Kassan kommer in tidigt. Köparen bär risken för oanvänt saldo; säljaren erbjuder ett bättre pris som kompensation.
Ett förbetalt åtagande med överförbrukning är jämnare och garanterar säljaren tillväxt och NRR. Kunden åtar sig en minsta förbrukning över en period, betalar åtagandet i förväg, förbrukar löpande och faktureras för eventuell överförbrukning när perioden tar slut. Den åtagna kassan kommer in tidigt, överförbrukningen sent. Köparen bär risken att betala för något den inte använt; säljaren bär kreditrisken för överförbrukningen. Desto större åtagande, desto större rabatt får kunden.
Bland våra användare och deras kunder märker vi att modellen med förbetalt åtagande är genomgående mer omtyckt. Vilken form som är rätt beror på inköpsavdelningens preferenser, kundprofilen och hur säkra båda parter är på användningsprognosen.
Avtalet är inte bara ett finansiellt dokument. Det är den första användningsdatamodell ett ekonomiteam någonsin ser om en kund.
Så formar Plock commit-sidan
På commit-sidan har Plock ett förstklassigt begrepp inbyggt i själva prenumerationen. Varje prenumeration kan bära ett minimiåtagande – antingen som en uttalad bottennivå eller inbakat i första nivån av din prismodell som en fast åtagen volym. Fakturamotorn förstår det direkt: när periodens förbrukning landar under den åtagna volymen sluter Plock automatiskt glappet på fakturan – antingen med en egen rad för minimiåtagandet eller helt enkelt genom att inkludera den fasta avgiften i första nivån.
Själva förbrukningen syns i produkten. På en given prenumeration kan ekonomi se:
- Den åtagna bottennivån för varje faktureringsperiod, som också ligger till grund för MRR.
- Uppmätt användning i takt med att den ackumuleras, timme för timme, mot den bottennivån
- Om perioden är på väg att bränna igenom åtagandet eller hamna under
- Den fakturarad som skapas om kunden stannar under bottennivån
Eftersom åtaganden kan sättas oberoende på varje rad i en prenumeration via offertbyggaren kan ett och samma avtal bära ett åtagande på en produkt och ren överförbrukning på en annan. Det spelar roll för kunder som vill förankra sig i en huvudprodukt men köpa valfri kapacitet vid sidan av.
När perioden är slut vet fakturamotorn om periodens förbrukning landade över den åtagna volymen, och Plock skapar en egen fakturarad för överförbrukningen.
Schemalagda ändringar och justeringar under perioden
Förbetalda åtaganden överlever sällan ett helt år utan omförhandling. Plock låter sälj och ekonomi schemalägga en ny bottennivå eller priströskel som börjar gälla ett bestämt framtida datum, och justerar den aktuella periodens faktura för eventuellt glapp. Ändringen slår in automatiskt vid gränsen, och prenumerationshistoriken sparar både det gamla och det nya värdet. Customer success-teamet behöver inte komma ihåg någon manuell uppdatering.
Så formar Plock credit-sidan
På credit-sidan behandlar Plock credits som fakturaliknande objekt. När en förbetald pott behöver justeras skapar Plock en parad kreditfaktura som speglar originalet – varje rad negeras och de två posterna länkas till varandra. Samma rörmokeri som skapar en debitering kan reversera den, vilket håller huvudboken konsekvent.
För ett affärsflöde med förbetalda credits rekommenderar vi att modellera det förbetalda saldot som en fast avgift som faktureras i förskott, med en matchande förbrukningsbaserad produkt vid sidan av. Plock stöder redan både förskotts- och efterskottsfakturering på prenumerationsnivå, och delbetalningsfunktionen i en offert gör att ett stort förskottsköp kan delas upp i en faktura vid signering och efterföljande uttag. Överförbrukning utöver åtagandet landar på samma prenumeration i efterskott, vilket innebär att kunden får ett fakturaflöde och inte två avtalsdokument att stämma av. Intäktsredovisningen för både förskott och efterskott är automatiserad och synkad med din huvudbok.
Eftersom Plock fakturerar löpande i stället för att köra ett enda skript vid månadens slut behöver överförbrukning inte bli en överraskning vid periodens slut. Användningen bearbetas i takt med att den kommer in, och det återstående saldot speglar verkligheten inom timmar i stället för dagar.
Var HubSpots affärslivscykel kommer in
Avtalet skrivs i HubSpot innan det finns i Plock, och Plock är byggt kring det faktumet. En Plock-offert är kopplad till en HubSpot-affär, och plattformen håller affärsvärde och rader i takt med offerten medan säljaren itererar. Säljaren ser den verkliga affärsekonomin på HubSpot-posten, inte en gammal uppskattning.
När affären markeras som vunnen avfyras en webhook och Plock förvandlar offerten till en aktiv prenumeration – med rätt prispaket, rätt bottennivå, rätt faktureringstakt och rätt fakturaintervall. Överlämningen från CRM till fakturering är ingen CSV-fil. Den är ett tillståndsbyte.
Samma pipeline är det som gör båda avtalsformerna hanterbara i stor skala:
- En offert med åtagande landar i HubSpot med en förbrukningsbaserad rad och en åtagandemarkering. Vid stängning skapar Plock prenumerationen med den överenskomna bottennivån och börjar följa förbrukningen mot den volymen.
- Expansion under perioden offereras i HubSpot, synkas tillbaka som rader och läggs på prenumerationen som en schemalagd ändring från det överenskomna datumet.
Vilken form för vilken kund
En snabb sammanfattning som brukar hålla:
- Inköpsavdelningar på större bolag med årsbudgetar, förutsägbar förbrukning och en preferens för investeringsliknande köp föredrar oftast förbetalda åtaganden.
- Växande kunder med rörliga adoptionskurvor och motvilja mot oanvända licenser föredrar oftast förbetalda credits.
- De flesta Plock-kunder kör förbetalda åtaganden, eftersom deras köpare gör det.
Plattformen tvingar inte fram något val.
Avslutande tanke
Värdet i en bra avtalsmodell är tråkig konsekvens. En offert som godkänns i HubSpot blir den prenumeration som fakturerar kunden, den bokföringspost ekonomi stänger mot och den rapport CFO:n läser. När åtagandet ändras under perioden får varje efterföljande system veta det i samma stund. Det är hållningen Plock är byggt för, oavsett om burndown räknas nedåt från ett förbetalt saldo eller uppåt från en förbetald bottennivå.
Om du skissar på ditt första användningsbaserade avtal eller gör om ett gammalt går sidan om Charging igenom hur delarna hänger samman, och teamet ser gärna på just ert affärsflöde under ett kort samtal.