After seeing the benefits that usage-based pricing can enable for businesses across verticals and specialties, it begs the question “how to tell if usage-based pricing is right for my company”. It is not a one-size-fits-all approach, and there are some business models or solution types that may not lend themselves particularly well to the usage-based approach. Of course we at Amberflo see the potential for much of the world to transition to usage-based pricing.

The first line of questioning should be around the nature of the solution itself? How far removed is the use of the solution from the costs of providing service?

‍

Infrastructure Platforms

This relates to how far the solution is abstracted from backend infrastructure. The closer to infrastructure it is, the more naturally a utility-based model fits; for a storage or compute solution, it makes intuitive sense to the customer and provider to charge for the use of each respective service. Customers can align their usage sensibly with the cost and value realized, and the vendor can apply a value-add markup for the service to cover the cost of providing service and produce the necessary margin to drive profits. Companies like AWS, Snowflake, Datadog, and Sumo Logic are prime examples of these that successfully leverage usage-based pricing.

The next line of questioning should be around the typical size and variability of workloads and how that relates to customer value realization. When using a solution, does the size of the workload vary and scale or is it generally about the same each time? When the workload does scale, does it result in a commensurate change in value that customers realize from using the solution?

‍

Complex workloads as-a-service (real-time streaming, AI/ML-as-a-service, IPaaS, HPC)

Consider a high performance computing system and an AI/ML as-a-service type business; both solutions will handle variable-sized workloads with specific requirements. Some datasets are massive while others are relatively small, so the demand on the systems changes as a result. Some applications such as streaming impose additional requirements around the latency and provisioning of the system. Similar to the infrastructure-type solutions described above, customers in this category intuitively understand that the solution is costly to provide (this is why these types of solutions exist as-a-service – to mitigate the cost and delay of building and maintaining specialized systems in-house) and that the cost should scale with the workload. Analytics, compute-based solutions, and data streaming/communication applications are some examples in this category, characterized by a complex offering with high cost of providing service, that lend well to the usage-based paradigm. C3.ai is an excellent example of this approach with pricing based in part on the total model runtime each billing cycle.

Applications further up the stack, layers abstracted from core infrastructure components, can still be effectively monetized via a usage-based model. The most important practice to ensure success and customer satisfaction is to select charge vectors that are as closely aligned as possible with customer value, and that scale predictably in line with the customer’s usage growth.

What problems do users solve with the solution? What aspects of the solution are most closely aligned with the value that is realized? How does the solution’s usage change over time as the customer organization grows?

‍

SaaS Applications

For a CRM or marketing solution, charge vectors that align with the value might be the number of contacts and leads in the system, or the number of meetings booked/logged. In a healthy business, more strong leads should lead to more sales, so it only follows that the customer would pay more as they earn more from using the solution.

Similarly, cybersecurity applications are beginning to include usage-based elements in their pricing based on vectors such as the amount of data and network traffic scanned, or the number of threats detected. As the benefit to the customer increases from using the solution, the customer should feel comfortable paying in proportion to that value. For SaaS applications where this relationship is easy to draw out and readily visible to customers, usage-based pricing offers the most fair and transparent pricing option.

‍

API-based solutions

Applications and services that are API-based make for a particularly natural fit with usage-based pricing. Meters can be easily associated with each API endpoint to track the activity, processing time, and payload size of each call, to enable total visibility into system usage. Communication tools, data sharing or file sharing applications, and many other classes of modern web applications fall into this category, with easily-identified charge vectors such as number of API calls, number of messages/data transfers, size and processing time for API calls, to name a few.

‍

Keys to remember

Essentially, if the product is itself a cloud solution built on a cloud platform that is priced on a usage basis, then the product can also be priced on a usage basis aligned with the costs of providing service plus some additional markup for the value added to create profits. This can become difficult to execute in practice, so the following key aspects become important:

‍

• Solution usage scales with the value customers realize from use. (i.e. the more a user consumes the product, the more value or benefit they realize)
• Solution usage scales with the growth of the vendor. In other words, the product is well-suited to “land-and-expand.”
• Solution aligns with PLG fundamentals. (i.e. A messaging tool - a user sends a message to a teammate with a messaging tool; the teammate needs to adopt the tool to view and send messages.)
• Solution value can be naturally communicated in terms of resource consumption. (i.e. A cloud storage solution would naturally price based on the amount of data stored plus some markup for the value added. As another example an ML solution would increase in value/performance with the amount of data/training time it was given.)

‍

Hopefully this framework provides a solid framework to weigh the characteristics of the business and product and how they fit together to create fair, transparent, viable usage-based pricing that benefits both customers and the vendor.