[telecuda]

Congrats! We built a usage-based telephony (voice & sms) billing system for our customers and appreciate the pain. Not to take anything away from your launch, but founders / product managers should carefully consider if usage-billing (even with a tool like Lago) is best for your business and customers.

We started as usage-based then learned a few years in (once we understood customer usage trends - key) that customers would gladly pay ~20% MORE per year for unlimited access because the customer wanted a predictable bill. We essentially rode the same trend of pay-as-you-go mobile to unlimited plans.

Later in our history we found investors (and our accountants) liked the predictability as well. It's easier to show "up and to the right" when not dealing with a few large customers varying down in usage in one quarter (even if the business was on the upswing).

One-size doesn't fit all -- usage billing has its place for sure -- just carefully weigh your model as it's a huge lift to flip it midstream.

[perlgeek]

I work at an IT service provider that also offers some cloud products.

Customers start out by wanting all the flexibility (for their devs, usually) to spin up their owner servers, and want used-based billing. It would be a waste to pay more, no?

Then their own book keeping department yells at them, because they use SAP, and every bill that differs from the contract or the previous month is sheer hell and requires 5 levels of approval / justification / whatever.

So the next iteration is that they buy a fixed contingent of "cloud points" per month so that the invoice remains constant, and there's reporting and/or a firm (but often unwritten) promise from the account manager that they'll notify the customer if/when they ever run the risk of exceeding their contingent.

In really big / inflexible companies, it really seems to be easier for the purchasing managers to justify higher but constant prices than variable prices. The inefficiency boggles the mind.

[kdeldycke]

> "cloud points" per month so that the invoice remains constant

So true. At one point Google Ads had a BillingCap enum in their APIs, used to set up "capped actuals", a scheme also known as "monthly with rollover". Something that I understood as selling monthly quotas of a consumable, or as you put it, "cloud points".

My notes points to: https://developers.google.com/ad-manager/api/reference/v2019... . But this URL is broken and I can't find any trace of "capped actuals" anywhere in Google's documentation. I guess it was probably rebranded/refactored into budgets/monthly spending limit/monthly invoicing/whatever.

At the end I think "points" is a better way to sell this feature. If this is generic enough, it can be an answer to airlines' miles and similar loyalty programs the retail industry is fond of.

[AnhTho_FR]

This is really what we've observed indeed! The companies catering to later stage companies prefer to offer prepaid credits to their end users, or annual plans paid in advance that includes some prepaid usage than a full, non predictable usage based pricing. I think in that case it's preferable for the end user, but also for the company, as their finance team can have more visibility on the upcoming revenue streams.

[nojs]

I'm interested how you handle suppliers that have usage-based pricing (which I imagine are the norm in the telephony space) if you can't pass this on to the customer. Do you offer your customers an unlimited plan, price it high and just hope they don't use so much that you go backwards?

[telecuda]

Great question. So yes, while our suppliers charge us for usage (and that made us initially think we should too!), our customers didn’t use the product any more or less once it became unlimited.

If you’re solving a problem that a typical customer experiences let’s say 3x per week (perhaps routing an inbound sales lead to a CRM), you could charge per use, or ask “If we made it unlimited, would they use it 5x per day? 10x per day?”

With many SaaS products, usage is self-limited by the customer’s actual need, not by a transaction cost. Same goes with most telephony use cases - a typical user will only make so many calls per day, making it relatively easy to arrive at an unlimited monthly price.

[AnhTho_FR]

I guess it was a question for telecuda, but I've worked 3y for telecommunications groups fresh out of business school and what you describe is pretty much the approach. Sometimes if it's a big group, they might have historical data and can make "informed guesses" but at the end of the day, this is it. And if the unlimited offer isn't viable (business wise), they just sunset it, and usually "grandfather" the offer.

[AnhTho_FR]

We 100% agree with you. Actually the first tagline of Lago was "billing for product led SaaS", the wording was a bit confusing, but our thoughts were:

(i) "pure usage based pricing" models (like Snowflake's) aren't going to be the main standard for SaaS, for the reasons you mentioned, the main being predictability (for the merchant and the end-user). Cash collection is also a big pain: if you collect cash after the consumption, the dispute rate can be high. (ii) However pricings will increasingly incorporate "usage dimensions" (monthly active rows, number of emails, GB used, etc) and this trend is spreading very fast (3 out of 5 SaaS according to the latest OpenView report). It can take many forms: Annual subscriptions including a monthly base usage and/or prepaid credits based on consumption, and/or an amount of payments processed, etc This is what we lived at Qonto.com and solved for, for 4 years, and you woudn't think of it at a "usage based player" though, we rather had "usage subscriptions" : https://qonto.com/fr/pricing All the possible combinations make the billing very hard to maintain and iterate on, and this is why we built Lago. All this to say, we 100% agree with you that not all companies should choose a "full usage based pricing" but find a balance or at least iterate between "subscriptions/fixed amount" and "usage based".

[TheJoeMan]

> It's easier to show "up and to the right"

I think it's funny how MBA's at the end of the day base their decisions on glancing at a chart. So now, the engineers are catching on to optimizing for that pretty chart.

I made a mistake by spitballing sales figures for a product and someone incorporated it into an ROI calc that was being judged to the decimal place.

[telecuda]

Agree. I never paid attention to it while building the business, but then later saw how much weight potential investors gave to predictability and how much customers wanted it too. Even my electric company gives me the option to pay a fixed monthly amount that grows by x% per month versus having to budget for variability.

[truetraveller]

Providing "unlimited" is a major competitive advantage. The hard part is predicting the average cost per customer. One can use historical metrics to help. The final price would then be set according to the average cost, taking into account profit + padding for outliers.

[telecuda]

I’m not suggesting it’s easy, but the trick is to play with pricing a lot in your early days while learning what those costs are. Start a little higher than you think you need - it’s easier to adjust down later than go up. Outliers can be caught with a small amount of code (hey, Slack me if a customer who I thought would use this thing once a day uses it 20 times so I can reach out to them to learn more about how they’re using my product).

[truetraveller]

Question: would you then put Unlimited* with an asterisk: "unlimited within reasonable bounds"? I would feel it unethical to claim unlimited as a blanket statement.

[AnhTho_FR]

We have seen it into the form of « fair usage ». Although I understand it from a merchant’s perceptive, I have not seen it well received by end users… yet.

[telecuda]

Yes, as AnhTho_FR said, some * notating “fair usage” or “unlimited for advertised use-cases” gives you a fallback in the event of a dispute. It ultimately depends on what you’re selling and who your customers are. If a customer is legitimately consuming way more than planned - so much that it’s not compensated by other customers who use it way less - then just reach out to them and talk person-to-person about why they love your product, what it accomplishes for them, and your situation on cost. A genuine customer will welcome that feedback. A customer trying to game your unlimited system should can be unwelcomed for renewal - you can fire a customer if need be!

[hdhrufjdi]

Unlimited except when it is too much is not unlimited.

Just set a limit then instead and don't market it as unlimited.

[codegeek]

I run a SAAS and whenever we try to implement usage based billing, it is a lot of work to educate the customer on how it will work. I think this is more of a business than technical problem. Like you said, usage based billing has its places (perhaps if you sell to technical/dev focussed products. e.g. Metered API) but if you work with customers that are more B2B and have to answer to their procurement/finance/accounting departments, fixed cost is always easier to sell. Even if that means they end up paying more overall.

[AnhTho_FR]

This really resonates with our observations. I think it's a "business" problem first (pricing) indeed and a technical one (once you've decided on pricing). Your insights are why're very bullish on "hybrid" pricings: usage subscriptions, fixed costs that can be overaged but with prepaid packages or prepaid credits. In that case, the end-user still gets the "we pay what we use", while there's predictability/peace of mind on the final bill (you can't exceed what you prepaid).