I wish it were an isolated instance. For one google storage product we found 2 pricing pages with 2 different billing models and a Google rep who added a 3rd billing model into the mix.
Billing models have become a new competitive frontier and lead funnel strategy in Saas. All but the most cursory usage has become "Enterprise" and begets a sales call.
This is an ad that gets posted around a lot of places.
> To solve this problem at scale, we've adopted a radical approach: we're building an open-source billing API for product-led SaaS. Our API and architecture are open, so that you can embed, fork and customize them as much as your pricing and internal processes require.
One model not mentioned in the article either solely, or in addition to those pricing models, is the per-user based model as well. Working in a medium-sized organization, this adds a billing/contracting barrier to growing usage of a good service.
Example - you want to try out a service, you sign a contract that has some cost $X, up to 5 users. It goes well, you want to double usage of the feature, but you now need to pay $2*X + $Y in order to expand to 15 users, which really only encompasses a few choice teams.
Thanks! We cover all types of SaaS companies' billing. We often say that if you can track it, we can bill it! We cover subscriptions, hybrid, pay-as-you-go, and per-seat pricing models.
We believe that the future of billing is hybrid - a mix of all the above. We've seen many missed revenue opportunities from companies that weren't able to price overage on top of a per-seat or pure subscription pricing (often because it was too hard to build, either internally or with existing vendors)
Finally, im glad I’m not alone. When we were building SuperCMMS, we already had a few companies ready to pay us. So we needed a billing system from the get go. While we use Stripe, we still had to wrangle a lot of stuff (like taxes), since we wanted to integrating other payment gateways in future. To save time we decided to have “only a single plan - all features included”.
Now comes the unexpected part. People kept asking us why we have only a single plan. Maybe all of us are so used to multiple pricing plans on saas products. So we had to explain ourselves in the pricing FAQ’s.
As a user of external services to build my own SaaS, I am actually forced to prefer the per-use billing model. So much so that I have signed up for only 1 service that bills monthly (and because they are priced way below the competition's monthly charge), and 4 that have a usage-based billing model.
What the usage-based pricing model does, it helps you capture startup customers early on when they are pre-revenue, then you get to keep them as they grow.
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.
I'm not going to join the willy-waving but I truly did spend a lot of time building a completely custom billing system! Lots of monthly subscriptions, per-unit billing, pricing changes, tax changes.
We added complexity as the business grew, and it was an integrated part of the hosting service that we sold.
I'm not saying it's for every company and every product, but for a bootstrapped British company in 2004 it wasn't even a question, there was nothing to buy.
That experience might colour my opinion that it's easier than it appears, or that you can get away with a lot less than SaaS billing solutions provide.
When you don't understand the complexity of billing (revenue ops, top management or marketing), you often end up adding more and more complexity, and engineering teams have no choice. They have to build new billing features
That billing model makes it very easy to find out what the operational cost of a particular product/service/team is costing the business and I think it's one of the advantages that GCP has, personally.
I used to work in GCP. The billing report UI in the billing account section shows per SKU usage. While detailed breakdown can be a nontrivial monster. Some customer may just launch thousands of VMs or data processing jobs per day.
I honestly have no idea how SaaS billing isn't so buggy customers leave. Those data pipelines can be pretty complicated with lots of nuances around the data, and hand-wavy consequences for getting it wrong.
I have to agree, I prefer google cloud billing. Particularly for api rate limited billing, even in the free tier I can see exactly how much each request is costing, by type, key, api, immediately after making the call.
It makes it very easy to test out a use case and determine how much it would actually cost (pricing charts can be a pretty rough estimate when use cases grow more complex).
And the hard stop, $300 free credit is exactly what I want when kicking tires / MVPing.
I imagine a lot of free tier usage fits into the developer testing / tire kicking. Going one step further than the docs, and making sure the api / SDK do as described.
B2B SaaS founder here, several years in: this article is right on point. Additionally, using Stripe Billing is not all it's cracked up to be, as it actually doesn't solve all my problems, while taking a chunk of revenue.
I've been building parts of a billing system myself over the years and I'm considering removing the remaining external parts, because I'm not happy with their limitations (Braintree's subscriptions are really limited, and absolutely nobody does correct invoicing for my situation (EU/Poland)).
Also, in a B2B SaaS you will end up with customers on totally different payment methods. Not every business has or wants to use a credit card. So you get annual billing with proforma invoices and the complexities involved with switching from invoiced billing to credit card billing and vice versa.
Billing models have become a new competitive frontier and lead funnel strategy in Saas. All but the most cursory usage has become "Enterprise" and begets a sales call.
reply