4 ms·
I once worked to automate billing for a on-prem-ported-to-"SaaS" product, and though it had a seemingly simple billing model ("pay $ per thing monitored per mon
by gregmac 4y ago
I once worked to automate billing for a on-prem-ported-to-"SaaS" product, and though it had a seemingly simple billing model ("pay $ per thing monitored per month", with $ negotiated per-customer) the reality turned out to be we had about distinct 80 SKUs. This was one of those products where the pricing page said just "$call_us".
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.
- londons_explore 4y agoOne solution to this is "monthly bill amount = {per-client python program}". 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.
- theptip 4y ago> My take-away was to at least think about automating billing early, just to avoid this explosion of SKUs problem. 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.