Many SaaS products include usage-based features, such as build minutes, bandwidth, API calls and forms. One of the main challenges is how to monetize such features.
Traditionally, SaaS vendors aim for maximal recurring and predictable revenue, which translates to encouraging customers for increasing their in-advance commitment of their SaaS subscription.
Customers, on the other hand, aim to pay for the value that they receive, and in usage-based features this is commonly associated with actual usage of the product. Of course, customers too want a clear and predictable bill, which especially in B2B SaaS is essential for budget allocation.
A good monetization strategy satisfies both vendor and customer requirements, however finding the balance requires ongoing iteration.
What makes SaaS pricing & packaging a success? 4-rules of pricing:
- The model is tied very well to customer value perception
- Recommended: Customer can also generally find it easy (or at least reasonably possible) to observe, understand and control - The model supports the business growth objectives and unit economy
- Recommended: The company should also be able to track, bill, recognize and forecast revenue in a sustainable manner - The model begins with positioning - answering the question who are we selling to (ICP, segment) what?
- The model has a clear value metric/s (billable metric) that does not break all across the customer LTV:
- Acquiring new customers of that segment/s
- Retaining existing customers of that segment/s
- Expanding existing customers of that segment/s
We’ve researched dozens of leading SaaS vendors and summarized the common best-practices.
Table of Content:
1. Definitions
→ 1.1 Metering
→ 1.2 Limits
→ 2.1 Overage charges
→ 2.2 True-ups
→ 2.3 Top-ups
→ 3.1 Transparency
→ 3.2 Alerts & notifications
→ 3.3 Budget cap
4. Monetization of usage-based features using Stigg
→ 4.1 Built-in metering and aggregation infrastructure
→ 4.2 No-code entitlement management and enforcement
→ 4.3 Flexible pricing engine
→ 4.4 Alerts & notifications
→ 4.5 See it in action
Definitions
Metering
A foundational building block for usage-based features is the ability to measure customers’ actual consumption of the feature. In some cases, this measurement is simple, for example: how many seats a customer is currently using; however, in cases where consumption is done in high throughput, based on aggregation of multiple data sources, or automatically resets every certain period (i.e. monthly active users, daily sessions, etc.), such measurement can become complex.
Moreover, in products that include multiple usage-based features, from an engineering perspective it doesn’t make sense to reinvent the wheel and build dedicated metering capabilities for each feature. Consequently, having a robust usage metering infrastructure is essential.
After measuring feature usage, how can I translate it to actual revenue?
Limits
In order to package and price in a way that is optimizing acquisition, retention and expansion, one of the most common best-practices is to define feature limits (or caps). Feature limits serve as a vehicle for optimization of the customer journey, from a prospect or visitor to an optimal LTV paying customer.
Imbalance can take place by two of the extremes: zero limits or too many limits. Zero limits give away the farm and hurt expansion strategies. Too many limits obfuscate the value of your product, and may lead to frustrated customers.
Limit enforcement logic can be “soft” or “hard.”
Hard limits
Hard limits prevent customers from additional consumption when they reach the defined limit. Simply put, when customers attempt to use more of the feature, they’re denied or blocked.
To gain additional access, customers need to explicitly upgrade to a higher plan or purchase add-ons. In both cases customers pay for additional access.
Hard limits are essential when no customer payment methods have been captured and when no contractual business terms have been set up, such as when implementing a freemium pricing model or free trials. They become even more critical when feature usage is tightly coupled with vendor costs, as is the case in cloud and compute costs.
Without hard limits in place, non-paying customers can abuse features of the SaaS platform either on purpose or by mistake, triggering SaaS vendors on a chase after customers to collect payment for their usage.
A recent example at Netlify, caused backlash in the SaaS community, resulting in an official apology of top leadership, and a commitment to implement hard limits in order to prevent future cases from taking place.
A significant disadvantage for implementing hard limits is that preventing additional consumption of your product’s features may have business implications for customers (for example: causing a website to become offline or email notifications to no longer be sent), which can have a negative impact especially for paying customers. In such use-cases, alternative tools must be put in place.
Soft limits
When soft limits are implemented, customers know what’s their current usage and allowed usage limit, but no enforcement takes place when they exceed it - consumption of additional usage simply passes through. In many cases, customers are not even aware that their defined limits are soft.
In a sense, soft limits serve as “psychological barriers” for customers from going over their limit.
Soft limits are commonly implemented in order to prevent business disruptions to paying customers, as is the case in sales-led offerings and enterprise plans. In such cases when customers get close to the defined limit, reach it or even exceed it, an account executive, customer success or sales rep reaches out to them and leverages this opportunity for discussions about increased commitment and contract expansion. Doing so, requires account teams to closely monitor customer usage in order to be able to react quickly to customers’ usage behavior.
In many cases, billing for excessive usage is waived when customers agree to an increased commitment.
Soft limits allow customers to consume more of a specific feature, but what if as a vendor I want to automatically charge customers for excess usage?
Monetizing excess usage
Overage charges
Overage charges are additional fees that customers pay when they exceed the defined allowance (limit) that’s included as part of their in-advanced commitment.
In many cases, overage charges are more expensive than the price per unit that’s included in the plan fee, and are intended to encourage customers to increase their in-advance commitment the more that they go over the original committed limit.
Some SaaS vendors, such as Sentry, refer to these charges as “on-demand usage”, since “overage charges” give the connotation that customers are “penalized” for increased usage; however, the intent is actually the inverse - the higher the usage, the more value that customers get from the product.
Common overage pricing models
During our research we’ve identified common overage pricing models throughout the self-service SaaS landscape:
Flat fee for every additional unit - for example, Clerk charges $0.02 for every MAU that exceeds customers initial commitment
Flat fee for every additional block of units - for example, Segment charges $10 for every 1,000 visitors calls beyond customers' initial monthly allowance.
When tiered pricing is implemented, a different overage fee per unit depending on the tier that customers committed to in-advance 🤯. A good example is MixPanel, where the overage price per additional event decreases, the higher the number of events that customers commit to in advance.
.gif)
Overage billing periods
Overage charges are billed in arrears based on the usage that exceeded the customers’ original commitment.
According to our research, in products that are offered via self-service, overage charges are commonly billed on a monthly basis, even when customers subscribe to annual contracts. This is especially common when customers are billed for cloud and compute usage. This makes sense since SaaS vendors prefer to reduce the time that provisioned resources are left unpaid, and customers prefer to pay for small charges throughout the year instead of receiving a huge bill upon their annual renewal.
The practice in sales-led and enterprise use-cases is in many times different, similarly to the soft-limit use-case, overage charges are leveraged by account executives, customer success and sales reps as triggers for expansion and increased in-advanced commitments.
One of the main challenges with existing billing solutions, such as Stripe, is that subscription billing periods are commonly tied to the contract length. This means that the billing period of annual subscriptions is once a year. Consequently, implementing a monthly overage billing period requires SaaS vendors to do the heavy lifting on their own and build recurring scheduled tasks and chron jobs for generating invoices on a cadence that’s separate from the subscription billing period in the billing provider.
Overage charges are commonly applied to features with usage that resets every certain period, such as monthly active users (MAUs) and monthly bandwidth. In cases where feature usage persists, additional pricing models can be applied.
True-ups
When feature usage represents provisioned resources that persist, such as seats, some SaaS vendors don’t charge for overage during the commitment period. Instead, customers true-up at renewal based on their usage in the last commitment period. This means that customers will pay the full price for excessive usage in the next renewal period, as opposed to a prorated price during the current commitment period.
For example: GitLab offers an annual true-up process:
The main benefit of true-ups is there are no additional fees during the current commitment period. All additional fees are added in the following commitment period, which is helpful in budget planning and allocation.
Top-ups
In products with multiple billable metrics it can be challenging for customers to fully grasp and estimate the amount that they’ll pay for using the product.
One solution for this challenge is to monetize product access using credits. Customers commonly pay up-front for a certain amount of credits, and purchased credits are deducted based on customers' usage of the different product features. In recurring subscriptions customers usually receive a certain amount of credits at the beginning of each billing period.
In the simplest implementation, once a customers’ credit balance reaches 0 additional consumption is prevented. This behavior is similar to implementation of hard limits and suffers from the same drawbacks of this approach, with the risk of disrupting business processes that are based on this feature.
Customers can explicitly purchase additional credits, which is an action known as a “top-up”, but in order to further reduce the risk of any business disruption, many SaaS vendors often implement automatic top-ups.
The main difference between top-ups and overage charges, is that customers pay for top-ups at the time of refill, and overages are paid at the end of each billing period.
Example - CircleCI
CircleCI implements such automatic top-up strategy:
Example - OpenAI
OpenAI recently switched from a pay-as-you-go billing to prepaid credits to help protect the OpenAI API platform from bad actors who may abuse pay-as-you-go billing and waste valuable resources that could otherwise go to high-trust users. OpenAI also claims that this change will also help developers know what they are committing to upfront which can provide more predictability for budgeting and spend management.
Over the past month customers received the following email:
“We’re reaching out to share that we will be updating how we bill for your OpenAI Account starting March 8, 2024. Instead of receiving a bill at the end of the month, you will need to pre-purchase credits to use the API.
Action required: To continue using the API, please add credits to your account by visiting the billing page. It’s important to purchase credits by March 8, 2024 to avoid API requests being interrupted for your application—if your account does not have sufficient credits on this date, API requests will temporarily fail for your application until credits are purchased. If you recently purchased credits, no additional action is required.
Please note that this change only applies to your OpenAI API account. It does not affect ChatGPT Plus or Team subscriptions.”
Luckily, OpenAI gives customers the option whether to stop API requests when the credits are exhausted, or enable an automatic recharge (top-up):
Keeping customers happy
Whether you’re implementing hard limits or allowing customers to exceed the limits of their initial commitment, providing top-notch customer experience is key in ensuring customer satisfaction. This will not only prevent churn, but also assist with conversion and expansion.
The implementation of only a few basic guardrails can go a long way.
Transparency
Ensuring that customers clearly understand what they are paying for is a basic skill set as a service provider. Specifically, when customers are billed for additional charges beyond their initial commitment, this becomes more critical.
One method to achieve such transparency is to show customers their current usage with respect to their plan limits, as well provide an indication for any additional charges.
In customers’ invoices, overage charges are commonly reflected as separate line items.
Alerts & notifications
Notifying customers about changes to their product experience and billing is extremely helpful in aligning customer expectations and preventing unpleasant surprises.
A common practice is to notify customers before, when and after they reach their plan limits. Ideally, customers would be notified multiple times before enforcement or additional fees are applied, giving them an opportunity to act. For example, customers can be notified when they reach 50%, 80% and 100% of their feature usage, as well a certain percentage afterwards. Such notifications can help drive conversions, expansions and increased commitments
Allowing customers to customize their alert and notification policy provides them with maximum control.
In addition to customer-facing alerts and notifications, notifying internal stakeholders such as account executives, customer success and sales reps is also helpful in reaching business success. Account teams can proactively reach out to customers before, when and after they reach their plan limits and leverage these events for discussions about expansions and increased commitments; thereby increasing MRR and ARR.
Budget cap
When customers can be billed for excessive usage, a budget cap can be put in place to serve as a guardrail against huge unexpected expenses.
When this budget cap is reached hard limits can be leveraged to prevent additional usage consumption or provide a degraded experience.
Without such mechanism, customers can end up with a surprisingly high monthly bill, as was recently shared by a Vercel customer:
Different SaaS vendors implement different flavors of this mechanism.
Zapier implemented a default policy, which sets the maximum cap to be a derivative of customer’s in-advanced commitment and allows customers to opt in to it, allowing customers control whether they want to immediately stop consumption when their plan limit is reached, or whether they also allow some additional fees for excessive usage.
GitHub allows each of its customers to define their own spending limits for GitHub actions.
Similarly to alerts & notifications, granting customers full control over the budget cap delegates the responsibility to them, with the downside of introducing additional complexity to your product.
In any case, if customers can be charged additional fees beyond their in-advance commitment, we highly recommend that a budget cap mechanism will be provided to customers and enabled by default to reduce the risk of any unpleasant surprises.
Monetization of usage-based features using Stigg
As we can see, monetization of usage-based features is complex. Luckily, Stigg reduces this complexity to a minimum.
Stigg is a headless pricing and packaging platform, which includes all of the capabilities required to monetize your usage-based features with ease.
Built-in metering and aggregation infrastructure
Leverage a highly scalable metering pipeline to report calculated feature usage to Stigg, or even fully delegate usage aggregation and calculation by reporting raw events to Stigg.
No-code entitlement management and enforcement
Stigg’s battle-tested SDKs and APIs allow low-latency entitlement checks and access enforcement. Update package entitlements, feature limits and access enforcement (soft / hard limits) using no-code.
Flexible pricing engine
From complex overage pricing models to true-ups, Stigg supports it all.
Report usage to Stigg and let Stigg do the heavy lifting of limiting access or charging for excessive usage.
Change dollar amounts and even complete pricing models using no-code, and leverage the Stigg platform to grandfather existing subscriptions or migrate them to the most up-to-date price book to roll out pricing and packaging changes out to your entire customer base.
Alerts & notifications
Notify customers and internal account teams when customers’ feature usage exceeds per-defined thresholds.
Integrate Stigg with third-party solutions to notify users inside your product or via any customer-facing and internal communication tools.
Customize these thresholds using no-code.
See it in action
✨Sign up to Stigg today!✨
