Forbruksmåling og prisfastsettelse: Teknikk kontra økonomi

Innledning

Brukbasert og hybrid prissetting er sjelden statisk. Når prissettingslogikken er hardkodet, blir hver eneste justering av et nivå eller en kredittkvote til en supportsak. Det er tidkrevende for økonomiavdelingen og frustrerende for utviklerne. Så hvem bør ha ansvaret for bruksmåling og prissettingen som bygger på den? La oss finne ut av det.

Hvorfor prisendringer nå skjer hyppig

Prisfastsettelse er ikke lenger en beslutning man tar én gang for alle. SaaS & AI Pricing Report fra konsulentselskapet hy og OMR Reviews, som siterer data fra Growth Unhinged, viser at tre av fire amerikanske programvareselskaper endret prisene sine det siste året. Det er mye bevegelse.

Modellene endrer seg også. I hy sin undersøkelse blant 180 programvareselskaper bruker 37 % allerede bruksbaserte modeller, og 59 % kombinerer mer enn én prismetrik, for eksempel fakturering per bruker sammen med API-volum. Legg til kreditter, gjennomfør eksperimenter, juster pakkene, og endring blir normen snarere enn unntaket.

Hvordan prislogikken ender opp med å bli eid av utviklingsavdelingen

Det skjer vanligvis ved en tilfeldighet. I begynnelsen hardkoder en utvikler en måleparameter: teller API-anropene, bruker en sats og sender totalbeløpet til fakturaen. Det fungerer, så ingen stiller spørsmål ved det.

Så utvikler prisingen seg. Et nytt nivå, en gratis kvote eller en annen sats for overforbruk betyr at noen oppretter en supportbillett, venter på en sprintplass og håper at utgivelsen ikke forstyrrer faktureringen. Ledetiden blir lengre, og hver utgivelse medfører en viss risiko. Økonomiavdelingen ender opp med å vente i en kø den ikke har kontroll over.

Hybridmodeller forverrer dette. Jo flere komponenter en pris består av, jo flere steder kan en endring gjemme seg i koden.

Kostnaden ved prissetting styrt av utviklingsavdelingen

Kostnadene er reelle, selv uten et regneark som beviser dem.

• Treg lansering: En prisidé kan ligge i ukevis bak produktutviklingen.
• Feil: Logikk som er begravd i koden er vanskelig for økonomiavdelingen å lese, så feil har en tendens til å dukke opp på fakturaene.
• Blinde flekker i økonomiavdelingen: Hvis økonomiavdelingen ikke kan se hvordan et tall er beregnet, tar det lengre tid å løse tvister.
• Alternativkostnad: Utviklerne bruker tid på å vedlikeholde faktureringskoden i stedet for å utvikle produktet.

Her er min oppfatning: Hvis en prisendring krever en kodedistribusjon, beveger prisingen seg i takt med utgivelseskalenderen, ikke i takt med markedet

Hva finansavdelingen bør ha ansvaret for, og hva utviklingsavdelingen bør ha ansvaret for

Ansvaret er ikke enten-eller. Del det opp etter type beslutning.

Teknikkavdelingen har ansvaret for hendelsesinstrumentering, datapipelines og nøyaktigheten av bruksdata ved kilden.

Økonomi og produktavdelingen har ansvaret for definisjon av måleparametere, prisnivåer, pakkeløsninger og kreditter.

Her er en enkel test: Hvis endringen handler om hva som registreres, hører den til utviklingsavdelingen. Hvis den handler om hvordan registrert bruk omgjøres til penger, hører den til økonomi- og produktavdelingen. For eksempel er det en prisbeslutning å bestemme at en plan skal omfatte 1 500 API-anrop i stedet for 1 000. Å sørge for at hvert anrop logges nøyaktig én gang, er en oppgave for utviklingsavdelingen.

Styring av prisendringer

Å overlate kontrollen uten sikkerhetsbarrierer inviterer til kaos. Dette er generelle beste praksis, ikke knyttet til noe bestemt verktøy:

• Godkjenninger: Krev navngitt godkjenning fra økonomiavdelingen og produktavdelingen før en endring settes i drift.
• Testing: Forhåndsvis effekten på reelle bruksdata før lansering.
• Versjonering: Sørg for at hver priskonfigurasjon versjoneres, slik at du kan sammenligne versjoner eller rulle tilbake.
• Ikrafttredelsesdatoer: Definer når en endring trer i kraft og hvordan bruk som allerede er registrert midt i syklusen skal behandles.
• Revisjonsspor: Registrer hvem som endret hva, og når.

Tenk på det som en kodegjennomgang for prissetting. Ingen sender ut kode uten at et par ekstra øyne har sjekket den, og priser fortjener samme omhu.

Forutsetninger for finansledet prissetting

Finansavdelingen kan ikke ta ansvar for noe den ikke kan stole på. Tre grunnleggende elementer kommer først.

Rene bruksdata. Dupliserte eller manglende hendelser undergraver enhver pris du fastsetter på grunnlag av dem.

Enige definisjoner av måleparametere. Hvis produktavdelingen definerer en «aktiv bruker» på én måte og finansavdelingen på en annen, vil fakturaene dine avgjøre striden for deg – og ikke på en hyggelig måte.

Pålitelige kilder. Bruksdata ligger vanligvis i et datalager, bak en API eller i filer. Velg ett registreringssystem for hver måleparameter og hold deg til det.

Spørsmål du bør stille før du flytter ansvaret for prissetting

Få finansdirektøren, produktlederen og utviklingslederen samlet i ett rom og gå gjennom følgende:

1. Hvilke prisendringer gjennomførte vi i fjor, og hvor lang tid tok det å implementere hver av dem?
2. Har hver fakturerbar måleenhet én avtalt definisjon?
3. Kan økonomiavdelingen spore hvordan et forbrukstall ble til en fakturalinje?
4. Hvem godkjenner en endring, og hvordan tester vi den før den tas i bruk?
5. Hvor lagres bruksdataene, og hvem er ansvarlig for at de er korrekte?

Hvis du ikke kan svare på to eller tre av disse, er det utgangspunktet ditt.

Endre prisingen uten å bygge om målesystemet

Det er her verktøy kan være til hjelp. Ifølge Zenskars side om bruksmåling kan team definere fakturerbare måleparametere i klart språk og la AI skrive aggregeringslogikken, eller skrive tilpasset SQL for kompleks logikk. Bruksdata kan hentes fra kilder som Postgres, Athena og MySQL, sendes via et API eller lastes opp som en CSV-fil. Den samme måleparameteren kan gjenbrukes på tvers av produkter, kontrakter og linjeposter.

Det som er viktig for eierskapet, er at programvare for bruksbasert fakturering bør tillate at nivåer, overskridelser og faktureringsfrekvens kan endres uavhengig av bruken. Faktureringslogikken kan også endres midt i syklusen uten å forstyrre datapipelineen. En enkelt måleparameter kan danne grunnlag for ulike prismodeller på tvers av kontrakter, slik at målingen forblir stabil mens prisingen utvikler seg.

Konklusjon

Den sunneste modellen er en delt modell. Utviklingsavdelingen sørger for at bruksdataene er nøyaktige og flyter jevnt. Økonomi- og produktavdelingene bestemmer hva disse dataene er verdt innenfor et klart styringsrammeverk. Hvilken prisendring står på utviklingsavdelingens venteliste akkurat nå?

Viktige poeng:

• Hardkodede priser gjør at hver justering av nivåer eller kreditt blir en supportsak for utviklerne.
• Del ansvaret etter beslutningstype: teknikkavdelingen har ansvar for innsamling og nøyaktighet av bruksdata, mens økonomiavdelingen og produktavdelingen har ansvar for definisjoner av måleparametere, prisnivåer, pakkeløsninger og kreditter.
• Sett først opp sikkerhetsbarrierer: godkjenninger, testing, versjonering, ikrafttredelsesdatoer og et revisjonsspor.
• Finansledet prissetting krever rene bruksdata, avtalte definisjoner av måleparametere og ett registreringssystem per måleparameter.
• Bruk de fem spørsmålene før overlevering for å finne utgangspunktet ditt.
• Velg verktøy som gjør det mulig å endre prisingen uten å måtte bygge om målesystemet.