Verbruiksmeting en prijsstelling: techniek versus financiën

Inleiding

Prijsstelling op basis van gebruik en hybride prijsstelling is zelden statisch. Wanneer de prijslogica hard gecodeerd is, leidt elke aanpassing aan een tariefniveau of een kredietlimiet tot een technisch supportticket. Dat is traag voor de financiële afdeling en frustrerend voor ontwikkelaars. Wie moet er dan verantwoordelijk zijn voor het meten van het gebruik en de daarop gebaseerde prijsstelling? Laten we dat eens op een rijtje zetten.

Waarom prijswijzigingen tegenwoordig zo vaak voorkomen

Prijsstelling is niet langer een beslissing die je eenmaal neemt en vervolgens vergeet. Het SaaS & AI Pricing Report van adviesbureau hy en OMR Reviews, dat gegevens van Growth Unhinged aanhaalt, stelt dat drie op de vier Amerikaanse softwarebedrijven hun prijsstelling het afgelopen jaar hebben gewijzigd. Dat is een flinke verandering.

Ook de modellen verschuiven. Uit het onderzoek van hy onder 180 softwarebedrijven blijkt dat 37% al gebruikgebaseerde modellen hanteert en 59% meer dan één prijsmaatstaf combineert, zoals facturering per gebruiker in combinatie met API-volume. Voeg daar credits aan toe, voer experimenten uit, pas pakketten aan, en verandering wordt de norm in plaats van de uitzondering.

Hoe de prijslogica uiteindelijk in handen komt van de technische afdeling

Meestal gebeurt het per ongeluk. In het begin programmeert een ontwikkelaar een maatstaf vast: tel de API-aanroepen, pas een tarief toe, stuur het totaal naar de factuur. Het werkt, dus niemand stelt het ter discussie.

Vervolgens evolueert de prijsstelling. Een nieuw tariefniveau, een gratis quotum of een ander tarief voor overschrijding betekent dat iemand een ticket indient, wacht op een plek in de sprint en hoopt dat de release de facturering niet verstoort. De doorlooptijd wordt langer en elke release brengt enig risico met zich mee. De financiële afdeling komt uiteindelijk terecht in een wachtrij waarover zij geen controle heeft.

Hybride modellen maken dit nog erger. Hoe meer componenten een prijs heeft, hoe meer plekken er in de code zijn waar een wijziging zich kan verbergen.

De kosten van door engineering beheerde prijsstelling

De kosten zijn reëel, zelfs zonder een spreadsheet om ze aan te tonen.

• Trage implementaties: een prijsidee kan wekenlang achterblijven bij het productwerk.
• Fouten: Logica die diep in de code verborgen zit, is moeilijk te doorgronden voor de financiële afdeling, waardoor er vaak fouten op facturen terechtkomen.
• Blinde vlekken bij de financiële afdeling: als de financiële afdeling niet kan zien hoe een bedrag is berekend, duurt het langer om geschillen op te lossen.
• Opportuniteitskosten: Ontwikkelaars onderhouden facturatiecode in plaats van het product te bouwen.

Dit is mijn visie: als een prijswijziging een code-implementatie vereist, verloopt je prijsstelling volgens het tempo van je releasekalender, niet volgens het tempo van je markt

Wat de financiële afdeling zou moeten beheren en wat de technische afdeling zou moeten beheren

Verantwoordelijkheid is geen kwestie van het een of het ander. Verdeel het op basis van het soort beslissing.

De technische afdeling is verantwoordelijk voor het meten van gebeurtenissen, datapijplijnen en de nauwkeurigheid van gebruiksgegevens bij de bron.

Financiën en Product zijn verantwoordelijk voor de definities van de statistieken, de prijsniveaus, de pakketten en de tegoeden.

Hier is een eenvoudige test. Als de wijziging betrekking heeft op wat er wordt vastgelegd, valt deze onder engineering. Als het gaat om hoe vastgelegde gebruiksgegevens worden omgezet in geld, valt deze onder Finance en Product. Bijvoorbeeld: beslissen dat een abonnement 1.500 API-aanroepen bevat in plaats van 1.000 is een prijsbeslissing. Ervoor zorgen dat elke aanroep precies één keer wordt geregistreerd, is een engineeringtaak.

Beheer van prijswijzigingen

Controle overdragen zonder vangrails leidt tot chaos. Dit zijn algemene best practices, die niet aan een specifieke tool zijn gebonden:

• Goedkeuringen: Vraag om een specifieke goedkeuring van zowel de financiële afdeling als het productteam voordat een wijziging live gaat.
• Testen: Bekijk vooraf het effect op echte gebruiksgegevens voordat de wijziging live gaat.
• Versiebeheer: Houd elke prijsconfiguratie in verschillende versies bij, zodat je versies kunt vergelijken of terugdraaien.
• Ingangsdata: Bepaal wanneer een wijziging van kracht wordt en hoe er wordt omgegaan met gebruik dat halverwege de cyclus al is geregistreerd.
• Audittrail: Leg vast wie wat heeft gewijzigd en wanneer.

Zie het als een codereview voor prijsstelling. Niemand brengt code uit zonder dat een tweede paar ogen ernaar heeft gekeken, en prijzen verdienen dezelfde zorg.

Vereisten voor door de financiële afdeling geleide prijsstelling

Financiën kan geen verantwoordelijkheid nemen voor iets wat het niet kan vertrouwen. Drie pijlers staan voorop.

Schone gebruiksgegevens. Dubbele of ontbrekende gebeurtenissen ondermijnen elke prijs die je daarop baseert.

Overeengekomen definities van statistieken. Als de productafdeling een ‘actieve gebruiker’ op de ene manier definieert en de financiële afdeling op een andere, zullen je facturen het geschil voor je beslechten – en niet op een vriendelijke manier.

Betrouwbare bronnen. Gebruiksgegevens worden doorgaans opgeslagen in een datawarehouse, achter een API of in bestanden. Kies voor elke maatstaf één referentiesysteem en houd je daaraan.

Vragen die je moet stellen voordat je de verantwoordelijkheid voor de prijsstelling overdraagt

Breng de CFO, de productleider en de technisch leider bij elkaar en neem de volgende punten door:

1. Welke prijswijzigingen hebben we vorig jaar doorgevoerd en hoe lang duurde het voordat elke wijziging in werking trad?
2. Heeft elke factureerbare maatstaf één overeengekomen definitie?
3. Kan de financiële afdeling nagaan hoe een verbruikscijfer tot een factuurregel is gekomen?
4. Wie keurt een wijziging goed en hoe testen we deze voordat deze live gaat?
5. Waar worden de gebruiksgegevens opgeslagen en wie is verantwoordelijk voor de nauwkeurigheid ervan?

Als je twee of drie van deze vragen niet kunt beantwoorden, is dat je uitgangspunt.

Prijzen aanpassen zonder de meetmethodiek opnieuw op te bouwen

Hier kunnen tools helpen. Volgens de pagina ‘Usage Metering’ van Zenskar kunnen teams factureerbare statistieken in gewone taal definiëren en AI de aggregatielogica laten schrijven, of aangepaste SQL schrijven voor complexe logica. Gebruiksgegevens kunnen worden opgehaald uit bronnen zoals Postgres, Athena en MySQL, via een API worden doorgegeven of als CSV-bestand worden geüpload. Dezelfde statistiek kan worden hergebruikt voor verschillende producten, contracten en posten.

Wat belangrijk is voor het beheer, is dat software voor verbruiksgebaseerde facturering het mogelijk moet maken om tariefniveaus, overschrijdingen en de factureringsfrequentie onafhankelijk van het verbruik aan te passen. De factureringslogica kan ook halverwege de cyclus worden aangepast zonder de datapijplijn te verstoren. Eén enkele statistiek kan verschillende prijsmodellen voor verschillende contracten aansturen, waardoor de meting stabiel blijft terwijl de prijsstelling evolueert.

Conclusie

Het gezondste model is een gedeeld model. Engineering zorgt ervoor dat gebruiksgegevens nauwkeurig zijn en blijven stromen. Financiën en Product bepalen binnen een duidelijk bestuurskader wat die gegevens waard zijn. Welke prijswijziging staat er op dit moment op de engineering-wachtlijst?

Belangrijkste punten:

• Vastgelegde prijzen zorgen ervoor dat elke aanpassing van een tariefniveau of tegoed een technische supportaanvraag wordt.
• Verdeel de verantwoordelijkheid per beslissingstype: de technische afdeling is verantwoordelijk voor het vastleggen en de nauwkeurigheid van de gebruiksgegevens, terwijl de financiële afdeling en de productafdeling verantwoordelijk zijn voor de definities van de statistieken, de prijsniveaus, de pakketten en de tegoeden.
• Zorg eerst voor de nodige waarborgen: goedkeuringen, testen, versiebeheer, ingangsdata en een audittrail.
• Prijsbepaling onder leiding van de financiële afdeling vereist schone gebruiksgegevens, overeengekomen definities van statistieken en één systeem per statistiek.
• Gebruik de vijf vragen vóór de overdracht om je startpunt te bepalen.
• Kies tools waarmee de prijsstelling kan worden aangepast zonder dat de meetprocessen opnieuw moeten worden opgezet.