IMPORTED FROM SKOOL
Original Post was posted by Emil Hjortflod on Sep '24
Hi All,
We are working on a price model based on a platform fee and a metric. Basically introducing the platform fee to keep the metrics price low.
We find ourselves struggling though to find out how to determine the platform fee dependent on the size of company.
What is your experience determining a platform fee. Could we use a secondary metric, or any other ideas?
All the best 
Carsten Kunkel • Sep '24
I worked on a similar model for a reg reporting solution. The clients had independent of size the same business requirement (JTBD): Enable compliance with the specific regulation they need to adhere to.
We used the volume (# of records) as metric to scale the price. This was modeled to have decreasing per unit costs using tiers like
up to 100K records: 10 cents/record
over 100K and up to 500K: 7 cents/record
over 500K and up to 1M: 6 cents/record
…
The challenge was to price the platform fee that i… See more
0
Reply
Carsten Kunkel • Sep '24
re 1: sounds like the clients look at your solution as a necessity for which they are willing to pay a base fee and not as a business enabler that helps them grow their business. I would suggest a model like this:
Packages differentiate in complexity of possible flows:
0
Reply
Ulrik Lehrskov-Schmidt • Sep '24
Hi
If you have a 3-tier model (as opposed to a single core ‘platform’-tier) then you should probably add a flat fee to each tier and just scale from there with your metric.
E.g. no need to BOTH scale the platform fee AND via a primary pricing metric.
Generally I advice setting the flat fee(s) based on the minimum $-value you want from a customer.
So if you want a minimum ACV oc $2k… then flat fee for smallest package is $2k.
Example:
Simple: $2k/mth + $0.1/signature
Complex: $5k/mth + $… See more
0
Reply
Emil Hjortflod • Sep '24
Thank you Ulrik.
How is your experience both scaling the platform fee and the Metric price when changing between packages?
0
Reply
Ulrik Lehrskov-Schmidt • Sep '24
You can have larger flat fees on higher product tiers than lower.
However: the metric unit price can both increase or decrease
Example 1:
Tier 1: $100 Flat + $10/user
Tier 2: $500 Flat + $5/user
= This creates an ‘optimum’, where the price is lower on tier 2 (here at 80 users). Buyer will focus on price to avoid objectively wrong decision.
Works well if you really want to promote slow volume expansion.
Example 2:
Tier 1: $100 Flat + $10/user
Tier 2: $500 Flat + $15/user
= Higher price for … See more
2
Reply
Mucio Batista • 20d
Great discussion! For customers who are accustomed to paying per user, how would you effectively advocate for a shift to a platform fee model combined with charge per units? What key arguments would best support this change? I’m asking because it gives the impression that nothing is included in the platform fee.
0
Reply
Ulrik Lehrskov-Schmidt • 14d
: you can put some core functionality in the platform : e.g. the database architecture, security, compliance, roles and permissions etc. (but save some for the Enterprise tier!).
= the core ‘plumbing’ of the solution, but not the actual JTBD-driving features.
I’ve never seen real push back on a platform if it has at least some functionality content.
0
Reply