Förbrukningsmätning och prissättning: Teknik kontra ekonomi

Inledning

Användningsbaserad och hybridprissättning är sällan statisk. När prissättningslogiken är hårdkodad blir varje justering av en nivå eller en kreditkvot ett tekniskt ärende. Det är tidskrävande för ekonomiavdelningen och frustrerande för utvecklarna. Så vem ska ansvara för användningsmätningen och den prissättning som bygger på den? Låt oss reda ut det.

Varför prisändringar nu sker så ofta

Prissättning är inte längre ett beslut som man fattar en gång och sedan glömmer bort. Rapporten ”SaaS & AI Pricing Report” från konsultföretaget hy och OMR Reviews, som citerar data från Growth Unhinged, visar att tre av fyra amerikanska mjukvaruföretag ändrade sin prissättning under det senaste året. Det är en stor förändring.

Även prismodellerna förändras. I hy:s undersökning av 180 mjukvaruföretag använder redan 37 % användningsbaserade modeller, och 59 % kombinerar mer än ett prismått, till exempel fakturering per användare tillsammans med API-volym. Lägg till krediter, genomför experiment, justera paketeringen – och förändring blir normen snarare än undantaget.

Hur prissättningslogiken hamnar i händerna på teknikavdelningen

Det händer oftast av en slump. I början kodar en utvecklare in ett mått: räkna API-anropen, tillämpa en taxa, skicka summan till fakturan. Det fungerar, så ingen ifrågasätter det.

Sedan utvecklas prissättningen. En ny nivå, en gratis kvot eller en annan överskridningsavgift innebär att någon skapar ett ärende, väntar på en plats i sprinten och hoppas att releasen inte stör faktureringen. Ledtiden förlängs, och varje release medför en viss risk. Ekonomiavdelningen hamnar i en kö som den inte har kontroll över.

Hybridmodeller förvärrar detta. Ju fler komponenter ett pris består av, desto fler ställen kan en förändring gömma sig på i koden.

Kostnaden för prissättning som sköts av utvecklingsavdelningen

Kostnaderna är verkliga, även utan ett kalkylblad som bevisar dem.

• Långsamma lanseringar: En prissättningsidé kan ligga i veckor bakom produktarbetet.
• Fel: Logik som är gömd i koden är svår att tolka för ekonomiavdelningen, vilket gör att misstag ofta dyker upp på fakturorna.
• Blinda fläckar inom ekonomiavdelningen: Om ekonomiavdelningen inte kan se hur ett belopp har beräknats tar det längre tid att lösa tvister.
• Alternativkostnad: Teknikerna underhåller faktureringskoden istället för att utveckla produkten.

Här är min syn på saken: Om en prisändring kräver en koddistribution, rör sig din prissättning i samma takt som din releasekalender, inte i samma takt som din marknad

Vad ekonomiavdelningen bör ansvara för och vad teknikavdelningen bör ansvara för

Ansvaret är inte antingen-eller. Dela upp det efter typ av beslut.

Teknikavdelningen ansvarar för händelseinstrumentering, datapipelines och noggrannheten i användningsdata vid källan.

Ekonomi och produktavdelningen ansvarar för definitioner av mätvärden, prisnivåer, paketering och krediter.

Här är ett enkelt test. Om förändringen handlar om vad som registreras, hör den till teknikavdelningen. Om den handlar om hur den registrerade användningen omvandlas till pengar, hör den till ekonomi- och produktavdelningarna. Att till exempel besluta att ett abonnemang ska inkludera 1 500 API-anrop istället för 1 000 är ett prissättningsbeslut. Att se till att varje anrop loggas exakt en gång är ett tekniskt beslut.

Styrning av prisändringar

Att överlämna kontrollen utan skyddsräcken bäddar för kaos. Det här är generella bästa praxis, som inte är knutna till något specifikt verktyg:

• Godkännanden: Kräv namngivna godkännanden från ekonomiavdelningen och produktteamet innan en ändring tas i drift.
• Testning: Förhandsgranska effekten på verkliga användningsdata innan lansering.
• Versionshantering: Håll varje prissättningskonfiguration versionerad så att du kan jämföra versioner eller återgå till en tidigare version.
• Ikraftträdandedatum: Ange när en ändring träder i kraft och hur användning som redan registrerats under löpande period ska hanteras.
• Revisionsspår: Registrera vem som ändrade vad och när.

Tänk på det som en kodgranskning för prissättning. Ingen släpper ut kod utan att någon annan har granskat den, och prissättningen förtjänar samma omsorg.

Förutsättningar för finansledd prissättning

Ekonomiavdelningen kan inte ta ansvar för något den inte kan lita på. Tre grunder är avgörande.

Ren användningsdata. Dubbletter eller saknade händelser undergräver alla priser du sätter utifrån dem.

Överenskomna definitioner av mätvärden. Om produktavdelningen definierar en ”aktiv användare” på ett sätt och ekonomiavdelningen på ett annat, kommer era fakturor att avgöra tvisten åt er – och inte på ett vänligt sätt.

Tillförlitliga källor. Användningsdata finns vanligtvis i ett datalager, bakom ett API eller i filer. Välj ett enda registersystem för varje mätvärde och håll fast vid det.

Frågor att ställa innan du flyttar ansvaret för prissättningen

Samla CFO:n, produktchefen och teknikchefen i ett rum och gå igenom följande:

1. Vilka prisändringar genomförde vi förra året, och hur lång tid tog det att implementera var och en?
2. Har varje fakturerbar mätparameter en överenskommen definition?
3. Kan ekonomiavdelningen spåra hur en användningssiffra blev en fakturarad?
4. Vem godkänner en ändring, och hur testar vi den innan den tas i drift?
5. Var lagras användningsdata, och vem ansvarar för att de är korrekta?

Om ni inte kan svara på två eller tre av dessa frågor är det er utgångspunkt.

Ändra prissättningen utan att bygga om mätningen

Det är här verktyg kan hjälpa till. Enligt Zenskars sida om användningsmätning kan team definiera fakturerbara mätvärden i klartext och låta AI skriva aggregeringslogiken, eller skriva anpassad SQL för komplex logik. Användningsdata kan hämtas från källor som Postgres, Athena och MySQL, skickas via ett API eller laddas upp som en CSV-fil. Samma mätvärde kan återanvändas över olika produkter, avtal och poster.

Det som är viktigt för ägarskapet är att programvara för användningsbaserad fakturering bör tillåta att nivåer, överskridanden och faktureringsfrekvens ändras oberoende av användningen. Faktureringslogiken kan också modifieras mitt i cykeln utan att datapipeline störs. Ett enda mått kan driva olika prissättningsmodeller över olika avtal, vilket håller mätningen stabil medan prissättningen utvecklas.

Slutsats

Den sundaste modellen är en delad modell. Teknikavdelningen ser till att användningsdata är korrekta och flödar smidigt. Ekonomi- och produktavdelningarna ansvarar för vad dessa data är värda inom ramen för tydlig styrning. Vilken prisförändring står just nu på tur i er teknikkö?

Viktiga slutsatser:

• Hårdkodad prissättning gör att varje justering av nivåer eller krediter blir ett supportärende för teknikavdelningen.
• Dela upp ansvaret efter beslutstyp: teknikavdelningen ansvarar för insamling och riktighet av användningsdata, medan ekonomi- och produktavdelningarna ansvarar för definitioner av mått, prisnivåer, paketering och krediter.
• Sätt först upp skyddsräcken: godkännanden, testning, versionshantering, ikraftträdandedatum och en revisionsspår.
• Finansledd prissättning kräver korrekta användningsdata, överenskomna definitioner av mätvärden och ett enda registersystem per mätvärde.
• Använd de fem frågorna inför överlämningen för att hitta din utgångspunkt.
• Välj verktyg som gör det möjligt att ändra prissättningen utan att behöva bygga om mätningen.