At Loop Crypto, most clients come to us with the question of how to accept crypto payments as a business. While we love talking about how to accept crypto payments, we figured we’d go back to first principles and talk about pricing models. As you start thinking about implementing a crypto payment solution, it’s important to consider all the pricing levers available to your business. This will ensure you are maximizing the revenue potential of your product and aligning its value creation with your pricing model. In this guide, we focus specifically on pricing models for Software-as-a-Service, or SaaS, businesses.
You can, of course, also use Loop to invoice for one-time crypto payments; however, this blog will be most relevant for subscription businesses that are collecting recurring crypto payments. You can find more details about using Loop for one-time payments here. And if you’re experimenting with your pricing model, Loop’s flexibility is ideal for any of the models we discuss below.
Before we get into pricing models, first a word on pricing strategies. There is a slight distinction between the concepts of “pricing strategy” and “pricing model.” Terms like “cost-based pricing” or “value-based pricing” are related to the concept of “pricing strategy.” It’s the general approach or philosophy that a business takes toward pricing its product.
For software businesses, this is a critical concept to grasp. While it may cost Salesforce very little to provision its services to its clients, it can still charge thousands of dollars per month for a subscription because of the value it provides to end users. For household staple goods like peanut butter or a loaf of bread, it may be harder to price on a pure value basis. Goods that are more commoditized tend to be priced based on what it costs to produce them plus a small margin. There’s less room for strategic creativity on the pricing front.
With that brief aside on pricing strategy out of the way, we turn our attention to “pricing models” or the actual mechanism for charging end customers. CloudZero sums the distinction up nicely writing, “...the pricing strategy describes the ‘why’ while the pricing model describes the ‘how.’” Let’s get into the how!
There are a number of permutations of SaaS pricing models. For simplicity purposes, we’ll talk about subscriptions on a monthly basis, but of course, a subscription cadence can also be daily, weekly, quarterly, or annually as well. At the highest level, we like to break down SaaS pricing models into two buckets: fixed and variable. Fixed rate subscriptions are those where the amount does not change month-to-month. Variable rate models are the opposite. There is some metric (usage, seats, etc.) that drives the final price the customer pays each month.
As the graphic above shows, there are more variable rate models than fixed. These models are not exclusive. It is certainly feasible, and potentially savvy, to build a hybrid model that combines fixed and variable. Before getting too complex though, let’s summarize each model.
With flat rate pricing models, you charge one price for your product. That’s it. For that one price, each customer receives the full feature set of your product. The benefit of this model is that it is easy to implement and explain to end customers. The downside is that you could be leaving significant value on the table.
Not all buyers value your product the same or need the exact same configuration of your product. Each buyer may have a different willingness to pay and part of the challenge of landing on a pricing model is figuring out how to capture the most value while keeping your customers happy. If my customer values my product at $100 but I only charge $50, I am leaving a lot of value on the table. This leads us to our next model.
If you’ve purchased any software product, you’ve likely run across this tiered model. In the simplest iteration, there are good, better, and best options presented to a client. The data insights platform Nansen is a prime example of this. If you head to their pricing page, you’ll see a handful of tiers. The richer the offering, the higher the monthly subscription price. The beauty of this model is that it allows your customers to price differentiate on their own and select the tier that best fits their needs.
Three to four tiers is typically the sweet spot to keep the pricing comprehensible to the end user. Having too many tiers can quickly become confusing.
The downside with the tiered model is that you could again be leaving value on the table. For example, there may be a feature included within one or all of the tiers that provides a ton of value to a customer that is not captured with this straightforward model.
Usage-based or metered pricing is a model whereby you charge customers based on how much they use the product. This could be the number of API calls, on-chain events, notifications, tickets, etc. The usage metric will correspond to your unique business and likely relate to your cost basis. For example, if your Amazon Web Services (AWS) bill goes up with user interactions on your platform, you’ll likely want your pricing to correspond with that.
The great part about usage-based pricing is that it is fairly directly tied to the value customers are receiving from your product. If they use the product, they presumably are receiving value and should be content to pay for that. The downside of course is that you need that usage. The revenue upside can be quite substantial with usage-based models, but customer activation and consistent usage become key.
Implementing a robust tracking or metering system can be an investment of time upfront to be aware of. It is also important to think through how this metering system will work alongside your payment gateways for fiat and crypto.
Per-seat pricing is charging based on the number of users or licenses for the product. Data analytics tools like Tableau and Messari’s enterprise plan are good examples of businesses employing this model. Slack uses a slight variation on this model charging for ‘active’ seats.
Like the flat tiered model, this pricing scheme is easy to understand and implement. The challenge is showcasing how additional seats add value. This is certainly easier for collaboration tools.
Finally, there is feature-based pricing. You can think of this as the buffet model. Your customers select the features they need and are then charged a specific amount for that feature set. As your customers add or drop features, their price can change month over month.
This model offers a lot of flexibility and can help you capture a customer’s full willingness to pay for the specific features they need. Be cautious about having too many feature options though and creating complexity for the customer. The last thing you want is a confused customer who does not understand what they’re paying for.
While all these pricing models have been explained one by one, in reality, they are often blended creating hybrid pricing models. For example, you may have a flat tiered model where the tiers are based on distinct feature sets. A flat tier model is often commonly paired with a usage add-on fee. There are lots of options to experiment with.
If you’re experimenting with pricing and looking to implement crypto payments, let us know. We work with a range of web3 subscription businesses that have implemented SaaS pricing with crypto payments.
If you’re looking to go deeper on pricing, here are a few additional resources:
Loop Crypto makes it simple to collect and pay in crypto by allowing companies to turn on autopay and schedule payments. Built by web3 veterans, Loop unlocks payment automation to reduce customer churn and eliminate time-consuming payment collection and follow-up. By connecting on-chain and off-chain data, Loop streamlines invoice reconciliation, accounting, and fits seamlessly into your financial stack.
Loop crypto is programmable payments.
Stay in the Loop.