Forbrugsmåling og prisfastsættelse: Teknik kontra økonomi

Indledning

Forbrugsbaserede og hybride prisstrukturer er sjældent statiske. Når prisberegningslogikken er fastkodet, bliver hver eneste justering af et prisniveau eller en kreditramme til en supportanmodning. Det er tidskrævende for økonomiafdelingen og frustrerende for udviklerne. Så hvem skal have ansvaret for forbrugsmåling og den prisstruktur, der bygger på den? Lad os få det på det rene.

Hvorfor prisændringer nu er hyppige

Prisfastsættelse er ikke længere en beslutning, man træffer én gang for alle. SaaS & AI Pricing Report fra konsulentfirmaet hy og OMR Reviews, der citerer data fra Growth Unhinged, viser, at tre ud af fire amerikanske softwarevirksomheder har ændret deres priser i løbet af det seneste år. Det er en stor udvikling.

Modellerne er også under forandring. I hy’s undersøgelse blandt 180 softwarevirksomheder bruger 37 % allerede forbrugsbaserede modeller, og 59 % kombinerer mere end én prismåling, såsom fakturering pr. bruger sammen med API-volumen. Tilføj kreditter, gennemfør eksperimenter, juster pakkerne, og forandring bliver normen snarere end undtagelsen.

Hvordan prislogikken ender med at blive ejet af udviklerne

Det sker som regel ved et uheld. I starten hardkoder en udvikler en målemetode: tæl API-kald, anvend en sats, send det samlede beløb til fakturaen. Det virker, så ingen stiller spørgsmålstegn ved det.

Derefter udvikler prissætningen sig. Et nyt prisniveau, en gratis kvote eller en anden sats for forbrug ud over kvoten betyder, at nogen indsender en ticket, venter på en plads i et sprint og håber, at udgivelsen ikke forstyrrer faktureringen. Gennemløbstiden forlænges, og hver udgivelse medfører en vis risiko. Økonomiafdelingen ender med at vente i en kø, den ikke har kontrol over.

Hybridmodeller forværrer dette. Jo flere komponenter en pris består af, jo flere steder kan en ændring gemme sig i koden.

Omkostningerne ved prisfastsættelse, der varetages af udviklerne

Omkostningerne er reelle, selv uden et regneark til at bevise dem.

• Langsomme lanceringer: En prisidé kan ligge i ugevis bagud i forhold til produktudviklingen.
• Fejl: Logik, der er gemt i koden, er svær for økonomiafdelingen at læse, så fejl har en tendens til at dukke op på fakturaerne.
• Blinde vinkler i finansafdelingen: Hvis finansafdelingen ikke kan se, hvordan et tal er beregnet, tager det længere tid at løse tvister.
• Alternativomkostninger: Ingeniører vedligeholder faktureringskode i stedet for at udvikle produktet.

Her er min holdning: Hvis en prisændring kræver en kodeudrulning, bevæger din prisfastsættelse sig i takt med din udgivelseskalender, ikke i takt med dit marked

Hvad finansafdelingen bør have ansvaret for, og hvad udviklingsafdelingen bør have ansvaret for

Ansvaret er ikke enten-eller. Opdel det efter beslutningstypen.

Teknikafdelingen har ansvaret for hændelsesinstrumentering, datapipelines og nøjagtigheden af brugsdata ved kilden.

Finans og produkt har ansvaret for definitioner af målepunkter, prisniveauer, pakker og kreditter.

Her er en simpel test. Hvis ændringen handler om, hvad der registreres, hører den under teknik. Hvis den handler om, hvordan den registrerede brug omsættes til penge, hører den under økonomi og produktudvikling. For eksempel er beslutningen om, at et abonnement skal omfatte 1.500 API-kald i stedet for 1.000, en prisbeslutning. At sikre, at hvert kald logges præcis én gang, er en teknisk opgave.

Styring af prisændringer

At overdrage kontrollen uden sikkerhedsforanstaltninger inviterer til kaos. Dette er generelle bedste praksis, der ikke er knyttet til et bestemt værktøj:

• Godkendelser: Kræv en navngiven godkendelse fra økonomiafdelingen og produktteamet, før en ændring sættes i drift.
• Test: Se en forhåndsvisning af effekten på reelle brugsdata, før ændringen går live.
• Versionsstyring: Sørg for, at hver priskonfiguration har en version, så du kan sammenligne versioner eller rulle tilbage.
• Ikrafttrædelsesdatoer: Definer, hvornår en ændring træder i kraft, og hvordan forbrug, der allerede er registreret midt i perioden, skal behandles.
• Revisionsspor: Registrer, hvem der har ændret hvad og hvornår.

Tænk på det som en kodegennemgang for prisfastsættelse. Ingen udgiver kode uden et ekstra par øjne, og priser fortjener den samme omhu.

Forudsætninger for finansstyret prisfastsættelse

Finansafdelingen kan ikke tage ansvar for noget, den ikke kan stole på. Tre grundpiller kommer først.

Rene brugsdata. Duplikerede eller manglende hændelser underminerer enhver pris, du fastsætter på baggrund af dem.

Aftalte definitioner af måleparametre. Hvis produktafdelingen definerer en "aktiv bruger" på én måde og finansafdelingen på en anden, vil jeres fakturaer afgøre uenigheden for jer – og ikke på en venlig måde.

Pålidelige kilder. Brugsdata findes typisk i et datalager, bag en API eller i filer. Vælg ét registreringssystem for hver måleparameter, og hold dig til det.

Spørgsmål, du skal stille, før du flytter ansvaret for prisfastsættelsen

Saml CFO’en, produktchefen og teknikchefen i ét rum, og gennemgå følgende:

1. Hvilke prisændringer gennemførte vi sidste år, og hvor lang tid tog det at implementere hver enkelt?
2. Har hver fakturerbar måleenhed én aftalt definition?
3. Kan økonomiafdelingen spore, hvordan et forbrugstal blev til en fakturalinje?
4. Hvem godkender en ændring, og hvordan tester vi den, før den sættes i drift?
5. Hvor opbevares forbrugsdataene, og hvem er ansvarlig for deres nøjagtighed?

Hvis I ikke kan besvare to eller tre af disse spørgsmål, er det jeres udgangspunkt.

Ændring af prissætning uden at genopbygge måling

Det er her, værktøjer kan hjælpe. Ifølge Zenskars side om forbrugsmåling kan teams definere fakturerbare måleparametre i klart sprog og lade AI skrive aggregeringslogikken eller skrive brugerdefineret SQL til kompleks logik. Forbrugsdata kan hentes fra kilder som Postgres, Athena og MySQL, sendes via en API eller uploades som en CSV-fil. Den samme måleparameter kan genbruges på tværs af produkter, kontrakter og regnskabsposter.

Det, der er vigtigt for ejerskabet, er, at software til forbrugsbaseret fakturering skal gøre det muligt at ændre prisniveauer, overskridelser og faktureringshyppighed uafhængigt af forbruget. Faktureringslogikken kan også ændres midt i en cyklus uden at forstyrre datapipeline. En enkelt måleparameter kan danne grundlag for forskellige prismodeller på tværs af kontrakter, hvilket holder målingen stabil, mens prissætningen udvikler sig.

Konklusion

Den sundeste model er en delt model. Teknikafdelingen sørger for, at forbrugsdataene er nøjagtige og flyder frit. Økonomi- og produktafdelingerne ejer værdien af disse data inden for en klar styringsramme. Hvilken prisændring står der lige nu på din tekniske venteliste?

Vigtige pointer:

• Hårdkodede priser gør, at hver eneste justering af prisniveauer eller kreditter bliver til en supportanmodning til udviklerne.
• Opdel ansvaret efter beslutningstype: teknikafdelingen står for indsamling og nøjagtighed af forbrugsdata, mens økonomiafdelingen og produktudviklingen står for definitioner af måleparametre, prisniveauer, pakkeløsninger og kreditter.
• Indfør først sikkerhedsforanstaltninger: godkendelser, test, versionsstyring, ikrafttrædelsesdatoer og et revisionsspor.
• Finansstyret prisfastsættelse kræver rene brugsdata, aftalte definitioner af måleparametre og ét registreringssystem pr. måleparameter.
• Brug de fem spørgsmål før overdragelsen til at finde dit udgangspunkt.
• Vælg værktøjer, der gør det muligt at ændre priserne uden at skulle genopbygge målesystemet.