Introduction
A typical billing system with usage based pricing would entail the following components:
- Event Sources
Various application or infrastructure components which emit events that correspond to the customer’s account activity. - UBP Tool
The tool which consumes the said events and pricing configurations to compute the invoice amount for all the customers. - Collection System
Generates the invoice for the customers based on the data from the UBP tool and initiates the mechanism to collect the bill from the customers. - Account State Manager
Manages the billing state of the customer’s account based on the bill status or limit breach(in the case of prepaid payment models), which can be used to feature gate the account.
While building tooling to implement usage-based pricing, there are multiple challenges you need to be aware of. The technical complexities in building a metering and pricing engine that is accurate is not a trivial task and here we look at some of them.
The usual suspects
- Scalable: It should be able to handle the sum of the peak load of all the services in the application, as events from all services should be tracked by this single service.
- Customizable: Each customer target group or even individual customers will have their own desired billing items and pricing.
- Configurable: The above-mentioned customization should be doable from the tool’s UI with low/no code configurations. If such changes involve a code deployment cycle, it delays the deal closure and creates a dependency on the development team for sales.
- Robust: Tracking usage events should not hinder the application flow. Therefore, this tool should be highly available and have very low latency.
- Reliable: Teams should be extremely careful when building a system that handles monetary values. Any unexpected behavior would result in actual financial loss.
Can you identify Keyser Soze?
You start by saying I know what I want and I can build this metering and pricing system in two weeks. That two weeks then become two months and eventually lead into a never-ending vortex of complicated features that you spend millions of dollars maintaining and 2 pizza teams managing. You realize you should have never started on this path but now you have all this sunk cost and cannot justify a buy vs. build internally. Guess what - you still can and that is why you should outsource internal tooling for pricing. Just a few initial set of things to consider, this list is by no means exhaustive and that’s why we call this a Keyser Soze - an internal UBP tool is something that will always be this elusive dream that you never can seem to build completely and forget about it.
Also Read: Togai - Our story
By the way, we had faced all these issues when building our previous product - Hypto and you can read the anecdotes personally from us or a SaaS founder we spoke to.
1. Once and only once
Events from various sources should be tracked once and only once. The ingestion component should be highly available and fault-tolerant. Strong idempotency is a mandatory requirement for this tool. There will be various event types from different event sources. Each of these will have it's own set of attributes that denote the uniqueness of the events. The tool should process a huge volume of events, accounting for their uniqueness across the set of events within that billing cycle at a very low latency.
2. One-off invoices
The tool should have provisions to apply one-off changes to invoices for various reasons, ranging from closing a deal to avoiding customer churn.
Anecdote: We have a long-time vendor for whom we recently got some credits from an external source. The credits were given to us in the middle of the month. Naturally, we were expecting that month’s invoice would use up the credits. But the billing system was so rigid that they could not accommodate this change and the credits were to be applied on the subsequent month’s invoice. Since we were tightly coupled with the vendor’s offering, we had to continue with their service. But this won’t be the case always and you need to handle it 🙂
Not all products are well established to handle disgruntled customers, especially in a high growth phase.
3. Customer acquisition initiatives
There would be various initiatives taken by the business development team, some of which might have an impact on the invoices of existing customers as well. There should be provisions to handle such strategic initiatives.
Anecdote: In one of the initial avatars of Hypto, we introduced a referral program. We made the required changes in the billing module to account for the referral rewards. After launching the program, we realised that we had to make a few tweaks to the rewards, like rewarding the new customer, randomizing the reward amount, rewarding the referrer only if the referee becomes an active customer, and so on. To accomplish the above mentioned tweaks, our rewards module in our billing system had to undergo various revamps.
4. Just in time changes
There is no saying when deals would be closed or when a customer would come with a requirement to change the pricing model. If such activities go through at the last moment of the billing cycle, the tool should be able to recompute the invoice on the fly.
Anecdote: We spoke to a founder who ran a marketing campaign during the Indian festival of Diwali. They rewarded their top customers based on the number of transactions and applied a discount on that day’s charges. This is one such scenario where they needed to know the top customers only at the very last moment. Since they were unable to automate it, they had to manually process invoices for their customers for that campaign.
5. Access control & approvals
The UI of the tool which is used by business development team should have proper access control and approval mechanisms. The approval should also have UI components for it. The lack of it might lead to hindrance in predictability of cash flow and importantly difficulty in reaching the revenue operations team’s goals.
Does this really require an anecdote 😛 ? There are subscription billing solutions providing fine grained access controls, so we can safely assume that requirement is valid here too. But implementing it for a usage based pricing solution is a whole new challenge.
6. Account for bugs or outages in event sources
The occurrence of bugs or outages in other services cannot be prevented or even predicted. All we can do is account for and build our solution. this is easier said than done. Depending on the volume of data and the time lag after which the events are sent, the quantum of rework would vary. Setting up systems to do this without the current infrastructure taking a toll is an enormously complex task.
7. Geographic expansion
For business growth, expanding the product’s reach to the global market is inevitable. It comes with its own complications for the UBP tool like, supporting new currencies, handling currency conversions, managing parallel pricing models for each plan, integrating with relevant bill collection services etc.
Anecdote: Few years back, I had integrated a billing solution into my then product. Due to a lack of bandwidth, we stuck with just the one. I can still recall various instances where the expected currency support was not with the vendor or the currency conversion was not as expected or flexible.
8. Reporting & Projections
Reporting is an integral need for any tool that handles money. Various teams would want it for their decision making. The product team would expect reports to analyse the impact of the features that they build. The business development team’s reports will focus on the performance of their sub teams. Revenue operations teams would want reports to compare their goals with actual results and also to generate projections for the future.
Anecdote: I have personally taken various reports from the invoices that we generated for a multitude of reasons:
- Understand the cash flow
- Metrics to be given to investors
- Tax corrections and filling
9. Another service to manage
Running a service would require you to build, provision, manage, optimize and secure the application and the infrastructure. It requires a dedicated team of well-seasoned engineers to run a service that addresses the above mentioned challenges. I am sure any SaaS founder can relate to this.
Are you making trade-offs while solving your customers’ problems?
The problems mentioned were just an appetizer to solving the problems around pricing infrastructure. But one thing is clear - while they can be solved using many strategies, every one of those would require companies to build complex and expensive systems. It won’t be just a one-time action and it would require continuous management. For any organisation to invest time, effort, and funds in a solution that is not core to its vision is not ideal.
We are here to solve this pricing infrastructure problem for you. At Togai, we have taken it upon ourselves to build a low code usage-based pricing platform for companies to observe, measure, and compute revenue metrics from your product usage data without developer effort. Looking to implement a usage-based pricing model, drop a note and we will be in touch right away.
