Inzicht uit een recente pricing workshop
Maarten Laruelle Ik gaf onlangs een pricing workshop waar we op een inzicht stootten dat de richting van het hele project veranderde. Het bedrijf evalueerde user-based pricing, een model dat er op het eerste gezicht eenvoudig uitziet maar snel zijn beperkingen toont als je naar echte klantdata kijkt.
De situatie
Het bedrijf bediende twee verschillende klantsegmenten, en hun gebruikspatronen konden niet meer van elkaar verschillen.
Segment A had veel projecten met weinig assets per project. Deze klanten draaiden tientallen kleine projecten tegelijk. Elk project omvatte een handvol assets, maar het pure volume aan projecten betekende dat ze veel gebruikers nodig hadden met toegang tot het platform. Denk aan een consultancybureau dat talrijke klantprojecten tegelijk beheert.
Segment B had minder projecten met veel assets per project. Deze klanten hadden een kleiner aantal grootschalige projecten, elk met honderden of duizenden assets. Ze hadden minder gebruikers nodig in totaal, maar elke gebruiker werkte met significant meer data en vereiste meer platformcapaciteit. Denk aan een grote industriële operatie met een klein, gespecialiseerd team.
Het probleem met user-based pricing
Toen we user-based pricing modelleerden voor deze twee segmenten, werd de mismatch duidelijk.
Segment A zou significant meer betalen omdat ze veel gebruikers hadden, ook al was hun verbruik per gebruiker relatief laag. Het prijssignaal zou hen vertellen dat ze dure klanten zijn, wat niet klopte vanuit een cost-to-serve perspectief.
Segment B zou relatief weinig betalen omdat ze weinig gebruikers hadden, ook al was hun werkelijke platformgebruik (in termen van datavolume, verwerking en opslag) substantieel hoger. Ze zouden een koopje krijgen ten koste van Segment A.
Kort samengevat zou user-based pricing de lichte gebruikers te veel aanrekenen en de zware gebruikers te weinig. Dat is een recept voor churn in Segment A en marge-erosie in Segment B.
Het workshop-inzicht
Het kernpunt dat naar boven kwam was dit: de juiste pricing metric moet correleren met zowel de waarde die de klant ontvangt als de kost om hen te bedienen. User count correleerde met geen van beide in dit geval.
We verkenden verschillende alternatieven. Asset-based pricing sloot beter aan bij de waardeperceptie van Segment B maar voelde bestraffend voor Segment A, dat veel kleine projecten had met weinig assets elk. Project-based pricing resoneerde met Segment A maar ving de complexiteit en resource-intensiviteit van de grote projecten van Segment B niet. Een hybride model dat een basisbedrag combineerde met een gebruikscomponent gekoppeld aan asset-volume bleek de meest gebalanceerde aanpak. Het gaf Segment A een voorspelbare basiskost die hun projectmanagementwaarde weerspiegelde, terwijl de asset-gebaseerde component ervoor zorgde dat Segment B eerlijk betaalde voor hun intensief gebruik.
De bredere les
User-based pricing is populair omdat het makkelijk te begrijpen en makkelijk te implementeren is. Maar “makkelijk” is niet hetzelfde als “juist”. Voordat je je vastlegt op een pricing metric, modelleer die tegen je werkelijke klantsegmenten. Kijk wie te veel betaalt, wie te weinig betaalt, en of de metric de waarde weerspiegelt die je levert.
In dit geval bespaarde twee uur in een workshop met echte data het bedrijf van het lanceren van een pricing model dat hun meest loyale segment binnen een jaar had weggejaagd. Goed bestede tijd.
Nadenken over je pricing model? Boek een gesprek.