How to build Usage-Based Pricing models

In the first part of this series, we discuss the concept of metering as a developer artifact and our vision that meters should track usage and resource consumption both internally (Cost Meters: track backend resources consumed providing the solution to customers) and externally (Usage Pricing Meters: track which customers consumed how much of what resources/functions at what time), and the benefits that strategy provides.

So now that the meters are in place tracking usage and consumption, what comes next? Usage-Based Pricing (UBP) plans are multidimensional and more complex than their simpler subscription-based counterparts, so many customers transitioning to the model struggle to know where to begin (and which product dimensions or features to charge on). One of the most important differences between usage-based and seat-based plans is that usage-based plans are constantly iterative as the solution evolves and grows with time.

Successful usage-based solutions typically follow a land-and-expand model where they are applied to solve a specific problem at first; upon successfully demonstrating value in that area it spurs the users to apply it to other problems, becoming stickier, and growing adoption (and billable usage) to drive large profits in the long-term. Since the goal of this model is to drive adoption over time rather than immediately maximize revenue collected, the pricing at first should be very accessible or even free until strong value has been demonstrated. AWS pioneered this model with Free Tiers for its services, and it’s why here at Amberflo we commit to a Forever Free Tier for both our Metering and Billing Clouds. As the value of the solution becomes clear through its use, adoption grows organically within the customer organization. At this point with the usage surpassing the free tier thresholds, revenue begins to be collected according to the pricing vectors that are defined. But of all the customer-facing meters, how to identify which meters are best to bill on?

‍

Selecting the Pricing Meters

In the first post of this series, we recommend you meter as many dimensions and parts of your solution as possible and obtain as much granular usage data as possible. This foundation will help drive not just pricing and billing, but will also enable sales, marketing, product development, and finance teams with valuable and actionable insights. The next step is, from these superset of usage instrumentation meters, which meters to select to price (or charge) on?

‍

PaaS/IaaS Vendors

One option is to simply price each service or capability (let’s call them product items for simplicity) on an a la carte basis - that is, simply set a separate rate for each product item, aggregate the total usage of each, and charge accordingly. This is simple and certainly transparent, but best-suited for mid-to-large footprint PaaS and IaaS vendors with product items that become fundamentally entrenched with their customers’ technology stacks (e.g. instance types and hours, storage, etc.).

‍

SaaS (applications) Vendors

On the other hand, for SaaS vendors a more common approach is to select a limited number of meters that are most closely aligned with customer value realization to charge on. These product items tend to map directly to domain specific features (such as number and type of assets created, number of transactions, types of transaction, etc.). Additionally, hybrid plans are an option here. Hybrid plans are where there is a monthly fixed recurring charge (e.g. $100 per month) and includes a certain amount (or quantity) of usage of various product items. But the plan allows for overage consumption (without blocking the user) and operates as a usage-based plan thereafter.

At Amberflo we recommend our customers implement the metering pipeline before developing their usage-based pricing plans; the metering data provides the insights needed to identify the most-used meters and the ability to model and develop usage-based pricing plans and backtest them against live customer data (see our post on Price Modeling).

Simply put, the meters chosen to bill against should correspond to the product items (capabilities/solution usage) that are most closely aligned with the value realized by customers. That is to say, the meters should correspond to actions the users are taking in the solution to solve their intended problems.

‍

Storage Solutions (Database, Data Warehouse, etc.)

For a database-as-a-service company, some example pricing vectors could likely be data volume stored, the number of read and write operations, and number of queries, similar to how cloud providers price their storage solutions.

‍

Compute Solutions (Clusters, Instance Types, etc.)

For a compute-based solution such as one built on AWS EC2 or Lambda, some example pricing vectors might be the amount of data processed, the number of clusters or cluster hours, and the instance types used. Outcome-based elements may be layered on top; for example in the case of an analytics tool built on the above infrastructure, a potential pricing vector could be the number of queries or the number of reports created using the tool, or the number of sessions.

‍

API Based (APIs, ETL, Microservices, Transactions, etc.)

For API-based solutions, which is emerging as one of the dominant and most popular Usage-Based pricing model, some pricing vectors could be the number of API calls, unique calls, amount of payload or data transferred. This approach offers more flexibility than simply pricing on a per user basis and enables more rapid adoption for a microservices based solution. For API-based solutions this approach of count and data volume is common and generally very tightly aligned with the value/use case of the solution.

‍

IOT and Industry Verticals (Finance, Banking, Automotive, Telecom, etc.)

Usage-based pricing for an enterprise IoT implementation would be generally similar to infrastructure-as-a-service (IaaS) pricing - based on the number of endpoints, the amount of data collected and processed by the network, the number of transactions or calls processed. Increasingly, the model is expanding to include outcome-based pricing as well, for example with pricing per anomaly/issue detected on a factory line or within an industrial asset.

Cybersecurity solutions are increasingly leveraging this model, such as pricing based on the number of threats identified/neutralized or the number of emails screened for malware. This outcome-based approach is well-suited for other vertical applications, typically in conjunction with some element relating to resource consumption such as data volumes, compute, or number of endpoints/VMs.

‍

SaaS Applications (Hybrid - Fixed + Usage-Based)

For an email marketing solution, suitable pricing vectors may be the number of contacts in the system like Hubspot does (using blocks of 1000) or the number of campaigns created with the solution. In each of these cases, the core purpose of the solution is directly tied to its cost - it makes complete sense when using a database solution to pay for the exact amount of data and compute used to service each workload. Similarly, it is totally transparent and sensible that a marketer might pay for each campaign that is executed, and that the cost of storing and reaching a group of contacts would scale as the size of that group increases. In a SaaS context it often makes sense to implement some hybrid model composed of a regular fixed cost and usage-based components. This is the most common approach on the market today, and can be used to guide customers through specific journeys (such as beginning to use a solution for email marketing but growing with the help of the customer success to leverage the content management system and CRM capabilities as well), as the variable fixed cost can enable additional functionality or modules of the solution.

We recommend that vendors start with a smaller set of pricing meters. Remember that the customer-facing meters are a subset of the total number of usage instrumentation meters across your stack - then the billing meters should be a subset of the customer-facing meters, as shown below.

‍

‍

Iteration and Evolution are Key

As stated above, the goal with any usage-based plan is to partner and grow with customers over the long-term rather than to maximize profits collected in the short term. One of the key advantages that usage-based pricing benefits from is the necessity of granular, accurate, deduplicated meter data that can be leveraged to inform pricing decisions. With clear visibility into the meters that are most commonly used, product teams can clearly identify the meters most closely aligned with the customers’ perception of value (i.e. What are the customers using to solve the problems that are core to the use case for my solution?). As we’ve said before, this is a partnership between vendors and customers, so if there is any uncertainty when analyzing the meter data, communication between the vendor and customer should be open such that a quick conversation about the use case and outcomes would clear up the confusion.

As usage grows and changes and more meter data becomes available, product and customer success teams should regularly monitor to be sure that usage and the billing meters remain aligned. When necessary, new pricing plans or product items should be implemented. Since there are no lock-ins or long-term contracts in a usage-based model, changing product item pricing or modifying the set of billing meters does not necessitate renegotiating contracts with customers. A usage-based billing solution should have full life-cycle management to create and test new pricing plans, as well as deprecate and clone old plans. It should support promotions and rewards to streamline any modifications to pricing plans without unfairly impacting existing customers (i.e. we are adding an additional pricing meter to our plans for new customers, for existing customers we are crediting them 12 months free usage of this product item before we begin charging them for it). See Amberflo Billing Cloud for more details.

Pricing in a multivariate, usage-based context is never a finished product. Pricing should be informed by how the product is being used and delivering value, so having the visibility and data to inform pricing changes and the agility (both on business and IT sides) to implement these changes is absolutely essential to any successful usage-based business.