Is the consumption charging model the best way for SaaS?
Times are at least uncertain, and for many companies, they’re getting increasingly tough. Little wonder then that many firms are looking for ways to trim their sails, cut costs ideally without either losing staff or dropping standards, and find a way through an economic and increasingly geopolitical minefield. One way that companies are using to cut their costs is switching to the consumption charging model for SaaS. But does it work? Does it save companies money? And if so, quite how does it operate?
We spoke to Chris Federspiel, CEO and founder of Blackthorn.io, a payments app on the Salesforce AppExchange, which has had some experience of the shift to the consumption charging model, to get our questions answered.
The upside of the consumption charging model.
What advantage does the consumption charging model bring over existing models like per user, or per unit of time? What’s the selling point of the consumption charging model particularly?
There are two answers to that – one for the customer and one for the company. Overall, the downside of a usage-based model is that the company doesn’t get the money upfront necessarily. The upside for the customer is they only pay for what they use.
Now, in the Salesforce world, people are used to buying on a per user basis. But we have an events app, and similar apps have historically charged by registration. We give people the option to charge by registration or by user – and usually, they’re adamant about one or the other. The problem when you charge by user is that you have different user personas.
So in the case of our events app, you might have 20 people making events, but up to 500 people who need to do something with the event data, so there isn’t the same value for them. But from a technical perspective, we can’t actually meter the different uses people are making of the app, so it’s a lot easier to use a per registration model. Then there are different permissions you can assign to people, where if it’s just by registration, everybody can have all the permissions, and you don’t run into that complexity issue.
So a lot of usage-based companies don’t have this user problem. AWS for instance has no user limits. Whereas with our usage-based stuff, we still try to charge an annual contract based upon assumptive usage. If someone says “I think I’m going to use a million widgets, API calls, tickets sold, credit card transactions processed and the like,” we’ll charge them for 800,000 widgets, and we’ll bill that on whatever the payment frequency is.
And then we’ll eventually bill for any extra they’ve used – so if they actually use a million, we’ll bill for the additional 200,000.
That means as we see them getting closer to their initial limit, we can contact them to say “Hey, you’re about to exceed what you’ve got.” And then we’ll bill it up front.
Now, I have a friend that runs an enterprise team at AWS, and usage is baked into their contracts. They’ll say “You’re using this much time of compute against these 17 services. We’re going to bill you for this and then here’s your overage.”
The benefit of pre-buying is that usually your usage rate goes down. So if you’re usually getting billed 10 bucks, and you’re prepaying for a year, maybe you’re overage then goes to 9 bucks. So for the customer, it’s a lot better to never commit to anything and just pay by usage unless you’re trying to decrease the spend.
But if your business has been working pretty consistently for three years, you can judge what to pay and do it now.
And if, at the end of the contract, someone hasn’t consumed what they’ve paid for, they’re not going to renew. We try to build in some kind of fairness to the system, so if someone exceeds the contract, we won’t necessarily bill them just because it spiked. If you’re an organization that has three events a year and you expect 10,000 people, but you actually get 15,000, we’re not going to just all of a sudden cut you off. That would be a customer service nightmare.
So your company develops this measure of net revenue retention (NRR), which is where a customer starts off spending say 10 bucks on January 1st. Now, if they bought 3 bucks of stuff throughout the year, that’s 13 bucks at the end, meaning you ran 130% NRR with that customer.
When you go to market to sell, as a B2B SaaS company, you want to target your NRR at at least 120%. Big players like Snowflake will run 130, 135, 140 plus percent NRR. They’re basically tapping existing customers to go far beyond what their existing spend is, because that then proves to markets that there’s room for growth. You’re introducing either additional products, or people are getting so much value from you that they’re increasing their usage.
So for example, when we go to market to sell our company, we’re going to get a much higher multiple if our NRR is above 120%, rather than being 100%. And this is a major problem with SMB-focused companies, because their NRR doesn’t tend to get into this realm.
So it’s better because it can be simpler, slightly more flexible, and potentially, over time, cheaper? It’s complicated in practice by the nature of the business and the depths of the economics involved, but that sounds like what we’re saying, right?
The scaling boost.
There’s talk that a consumption charging model actually helps companies to scale more easily. Does it do that? And if so… how?
Well, it makes it easy because you don’t have to deal with salespeople.
Ah. That’s a very much more straightforward answer.
Yeah. In big organizations, if you have to go through some formal process, it’s a pain in the neck. You have to create a new contract, you need a new purchase order. You need all these…
Shenanigans, absolutely. We just rolled out this new functionality where you can just log in and add users, but even there, there are some technical limitations. If you’re using a true usage-based or consumption charging model, and you just start having more usage, it’s seamless, there’s no hurdle to get over before you can deal with that.
Right now, companies are dealing with inflationary, unfriendly economics, where costs are being cut, leading to cashflow problems.
Think about it. If you’re on a consumption charging model, whatever happens in your market pulls your costs with it. If you’re in some travel product business and Covid hits, travel stops, and where you may have been spending a million a year, now you’re spending just 100,000. You don’t have to do, or re-do anything to register that effect in your spending.
But for the company selling you the service, that’s a disaster. All of a sudden, 900,000 of their revenue from you is gone. They have to layoff people, otherwise their company’s going out of business. For us in that position, selling annual contracts has given us a protection. Sure, we got lucky, the products we sell haven’t seen any kind of usage changes. But for companies that do, that will really hurt your ability to employ people or ensure adoption.
So again, there’s a degree of relative simplicity, and it helps protect against upset, meaning it’s easier to scale?
For instance, there’s Cloudflare. They’re a company that people put in front of their website to do DDoS and hacking protection. But they have other services like load balancing, to help companies scale their apps or websites. And they pretty famously switched to a NRR-based model, and were really hurt because their revenue tanked while they did it, but it also really hurt investors, but they said “Look, we know this is going to be righteous, stick with us.” And it took a year, and then their revenue went way up, higher than it used to be.
So it takes a big hit for cash flow, and if there’s a way to balance contract with usage base, that really helps. And we’re trying to go with more usage-based, with this consumption charging model, but we’ll probably still end up doing contract mixed with usage, because it helps with cashflow, and it helps customers too. It finds a balance.
In Part 2 of this article, we’ll explore the potential of mixing the cashflow fuel, so that companies can both survive in the short-term, and thrive in the long.
30 November 2023
29 November 2023
28 November 2023