Consumption-based (a.k.a. Usage-based) Model - The Future of SaaS!

The software as a service (#saas) industry is undergoing a significant change. We’ve seen an evolution from #perpetual to #subscription and finally to a #consumption-based model. This shift's defining characteristic is the industry’s approach to selling models.

At large, Salesforce pushed the #subscriptionmodel, while Amazon Web Services (AWS) pushed the #consumptionmodel in the industry. Salesforce also started rolling out a controlled consumption-based model in specific clouds, e.g., charging by community logins rather than named users. From a financial perspective, there may need to be a clear line of sight on the revenue stream; revenue forecast accuracy could be a challenge. It also requires product support audit and metering capabilities when a service is provisioned or de-provisioned. The product should also provide customer self-service capabilities, service scale, and flex capacity.

On the other hand, customers also want to avoid tying themselves to the perpetual or a single-tenant model, which requires them to support, maintain and upgrade their software. Additionally, they need to plan for downtime while upgrading and keep their fingers crossed that it will go as planned, or they may take the revenue-impacting system downtime while being at the vendor's mercy to fix the issue. From a cash-flow perspective, a multi-tenant consumption-based model may also work better for customers; they don’t need to invest significant dollars upfront, and expenses grow as revenue grows.

When a consumption-based model is enabled correctly, it also solves many operational challenges like seasonality, during which customers need to use more for a short time, contract amendments, and time-to-enable additional services. Overall, it helps reduce the bottom line and reduce friction for customers to use more products and services, eventually increasing revenue for the company.?

There are three primary consumption-based models -

1. PayGo ‘with’ commit - PayGo with commit is generally a pre-paid model (annually or quarterly); the customer pays at the negotiated commit amount, and monthly usage is trued-up to the annual commit. The commit level is decided based on the customer’s sizing exercise; a higher commit level may lead to a higher discount. If a customer consumes more products/services compared to the annual commitment, they pay more based on negotiated pricing, and if they consume less, they still pay the committed amount. Customers may renegotiate the lower commitment level for fewer discounts if they feel their usage will continue to be lower. I helped enable this model in a previous company and called it ‘Choice.’
2. PayGo ‘without’ commit - PayGo without commit is generally a post-paid model; the customer pays based on the product/service usage at a list price. The more customer uses the service, the more they will pay. In this model, customers have more flexibility and may switch services as they find a better and cheaper option; hence, they are less preferred from a business perspective. Pacific gas and electric (PGE) is a comparative example; we use more utilities and pay more. The only difference is that customers don’t have much flexibility to select another utility provider as there may not be many options, and not easy to switch. In this model, the business may also charge the customer startup fees to reduce customer churn.
3. PayGo ‘without’ commit + Platform Fees - This model is similar to the PayGo without commit model except for adding platform fees related to tenant enablement. It is generally a fixed annual cost based on the size of the tenant. A few businesses already use this model today.

What is the correct model for your business?

Well, it depends. There is no one size fits all approach; a company should consider factors like product maturity, line of business, customer preference, tenant enablement cost, and market conditions before choosing a specific consumption-based model. Product maturity is a minimum requirement to support a consumption-based model to help with auditing capabilities to track who enabled what products or services and metering capabilities if it is purely a usage-based model. Often, customers may have a specific preference, and depending on market size, a company needs to support these models for current or new customers. The company doesn’t need to charge platform fees if a tenant's cost is not high. Or, they can add that to the usage.

Finally, while building business systems’ quoting, billing, and revenue capabilities, we must ensure scalability and flexibility to enable the consumption model later as the business evolves. Highly recommend discussing the appropriate model with your business partners before building quoting, billing, and revenue capabilities to build the consumption model iteratively later.

What do you think?