Design your pricing and tools so you can adapt them later
arnon.dk
arnon.dk
Any idea that the CEO/business folk come up with should be implementable. You never want your tech limitations to be stopping you implementing a pricing scheme.
In that light, you want to be able to set any product to any price any time. You might want to let existing customers keep the old price. You want to be able to give existing customers one-off credits or charges, or discounts for a given number of months.
You want to be able to do the same for other features. For example, credit a customer a certain number of gb's or minutes. Or a group of customers.
You need to be able to do 'if then' pricing. eg. If you have more than 8 synced devices, you automatically get 99 more gb's.
You need to be able to do pricing depending on other customers. Eg. "if you refer 3 friends, and they all verify their account, you get a credit of $10, but it must be spent within 3 months"
You need to be able to 'undo' mistakes (ie. retract an invoice), but you also need to be able to re-issue a now-corrected invoice. The rebilling might need to use the pricing/discount structure present at the time of the original invoice, or it might need to use the current pricing structure.
There is no simple way to achieve all of this. You will end up with a mess. Just embrace it and move on.
All of this was being handled by the billing dept using a combination of the accounting software, spreadsheets, and manual effort (ie: insane). No one actually realized we had this many SKUs until we started technical requirements gathering.
What was happening was sales had some freedom to write terms, and so write terms they did. Things like "price per month is $x as long as there are y things after 6 months, otherwise the price is $z", "$x for the first 1000 things, $z for the next 5000, etc" or "$x per quarter in advance with a minimum of $y", exactly as stated in the post above. Billing in advance was one of the worst: it required manual adjustment afterwards to reconcile with reality, while dealing with minimums and date-limited exceptions.
On top of that, there were 6 different ways of even counting "things monitored" since it could vary, including: peak distinct per month, peak concurrent per month, # at the end of billing cycle (sometimes calendar month, sometimes anniversary day). And for very old plans, it could just be a fixed # written in the contract (which was also a max enforced in software).
Any one or two of these isn't a huge deal, but it was the combinations that was killer, especially since it was very much a long-tail: most of the SKUs only had a small number of customers, and many had 1 (though some of these were the biggest customers). To automate billing, we'd have to implement and test each, of course.
Billing found this tedious but just accepted this as the way things were. Sales just did what they'd always done. C-suite was happy we were growing. The meeting where we presented the 80 SKUs to the CEO and CFO was definitely an interesting one - they were ultimately responsible for approving all the deals that caused this mess, but were also who asked us to automate billing. The entire project was put on hold to first migrate down to a much smaller number of plans, and that's when my involvement stopped (It was deemed more cost effective to continue billing manually than to divert the dev team to spend the time on this). I don't know how far along they got.
My take-away was to at least think about automating billing early, just to avoid this explosion of SKUs problem.
When a customer comes along that needs really bespoke billing, you go write a few lines of python to implement it. "bill us only on the full moon" becomes very possible.
Make a few library functions for common plans/special offers, and the maintenance burden becomes manageable.
Agreed that you should be thinking about this, though it might be fine not to do anything about it. I think this is analogous to tech debt (at risk of opening another can of worms).
If you don’t know you have debt, you are doing something very wrong. On the other hand, if you consciously decide that short-term growth is what you need, some debt can be appropriate; just don’t forget to pay it down before it compounds out of control.
When I'm helping someone with their pricing structure, I look for two things:
- is it structured to find the ceiling (the maximum any individual customer will pay)
- is it structured to find the right price for each individual customer
We might settle on a fixed price for any number of reasons, but we shouldn't start there, and turning every combination of customer and price into a SKU is usually unnecessary.
I don't see why you want to avoid grandparenting. If the pricing model [2] is versioned and immutable, then keeping customers on their existing Customer Schedule [3] and then using specific migrations to move customers to new schedules makes sense and is easier than either not doing anything, or trying to track customer specific discounts and the accounting related to that.
Citation needed? In my experience it's very probable your startup goes out of business before this is ever a concern.
Building around future pricing seems like premature optimization for me.
That said, I've been in the situation where there were 50+ "billing plans" and who knows how many custom plans in order to support some lighthouse customers... It was not a fun experience and the move to an entitlements system was painful. If you start from the idea of entitlements/feature flags/etc separate from the billing logic, you can save yourself a ton of heartache later.
Once it was in place, we moved everyone into normal, supported situations.
One could argue the opposite of your assertion: startups may fail because they dont change their pricing and packages.
Here’s a citation on underpricing: https://www.ycombinator.com/library/7M-most-startups-are-und...
Startups have extremely little information to guide their pricing and packaging decisions, and often find right away that they've just picked the wrong way to monetize.
An optimal solution makes it easy to build a flexible system, so that it can change rapidly as new information becomes available.
It didn't seem to fit as well with smaller businesses and startups for whatever reason.
The global behemoth is vast and authoritarian, so the model was simply not up for discussion and customers largely didn't have alternatives. The smaller companies were constantly discussing ("negotiating") models, and customers had alternatives, but would a "This is what we sell, this is how it's priced" model have worked if anyone had committed to it? We never found out.
The core concept still works :)
If you just keep your initial billing logic very simple you can change it when needed as you discover what direction you want to take your business into. Having customers on legacy SKUs is only mildly annoying, and it’s not hard to segment all accounts on creation date, for instance, if you want different billing logic for legacy accounts. But you can do that after you’ve figured out what works with some experiments.
It also gets super messy after a couple years of pricing iterations. Eventually your plan distribution doesn’t reflect feature access which doesn’t necessarily reflect feature usage. Future changes to optimize packaging only have limited impact because it’s so hard to tie back who has each entitlement and why.
IMO it’s super important to document the WHY every time a customer’s entitlements are separated from their plan (especially if an account mgr will ever be involved in a renewal). Also periodically undoing extra unused entitlements helps to keeping things clean.