>>>>>> NOTE: For another blog post on usage billing, go here! <<<<<<
In this post we want to take a shot and classify a bit more what is referred to as Usage Billing. The short answer is the ability to bill for what a user has used over a given period of time. However, there exists many different strategies to bill for usage, and each of those may have variations. Let’s start with a few examples:
- Example of an electricity bill: A customer gets invoiced for what she consumed over a given period of time; the customer receives her statement and make the payment at the end of the period. The model may include various tiers that specify different prices based on period of time, or other criteria…
- Example of a bridge toll bill: A customer buys credits in advance, and those get consumed each time he crosses the bridge. The credits get refilled automatically when they drop below a certain limit (TopUp model used by FasTrack). Other variations could be to deny service when the credits drop to zero (prepaid cell phone minutes), …
- Example of a recurring cloud service model: A customer subscribes to a plan for a cloud service; the chosen plan offers limits on how much disk space is available. The customer pays for his subscription at the beginning of each period and as as long as he stays within the limits specified in the plan, this is just a pure recurring invoicing model. However, the model also needs to define what happens when the customer goes beyond the limits included in the plan. There could be many options, such as denial of service, automatic upgrade to a higher plan (with higher limits), …
Those examples are just a few of the many ways to charge based on usage. The number of possibilities is very large, because some of these models could be combined. For instance, in the case of the recurring cloud service model, one could easily imagine that if a user goes beyond the limits defined in the plan, then he gets charged for the extra capacity consumed using a different scheme such as the one defined in the electricity bill example. So the first question when implementing a generic usage billing system is to first define how much of these combinations it should support?
Also, looking at the most generic uses case, one could imagine that a vendor decides to specify different models for different things to bill for: For instance in the cloud example, the disk space could be charged using a recurring subscription that specifies a limit allowed within a month, but the bandwidth could be paid at the end of the period so as to charge for what was consumed. And of course, those usage models could also be coupled with recurring subscriptions (annual service subscription), fixed fees,…
Before digging too much into the set of all possibles combinations, it is important to classify the various use cases for usage. In the example shown above there are two main dimensions that stand out:
- Is the usage section specifying to be billed in advance or in arrear?
- Is the usage metric something that is consumed (units) or is it a rate (can go up and down during the period)?
The 2×2 matrix below summarized those two dimensions. Note that the diagram only focuses on the usage, but in addition to usage, plans could also define recurring and fixed price:
Some properties about those quadrants:
- Tiers: The in-arrear billing quadrants can be configured using tiers. Those tiers define the price that should be billed depending on the usage. Tiers cannot be used for in-advance billing because billing platform could not know in advance which one to pick.
- Limits: The capacity quadrants need to define limits which are checked against to provide some sort of enforcement. Those limits define the unit and conditions such as max allowed,…
- Blocks: The consumable quadrants need to define blocks, which define a unit of some sort, the size/price of the block.
In addition to those dimensions, the configuration also needs to specify varieties associated with each section:
- Capacity in advance:
- Specify auto-upgrade to higher plan if such plan exists
- Specify remedial action when user goes beyond limit
- Consumable in advance:
- Specify if credit should be automatically be purchased when they drop below a certain level
- Specify what happens to credits non used in a given period (rollover,…)
- Specify remedial action if credits expired
- Capacity in arrear:
- Specify high watermark
- Specify possible tiers with policy
- Consumable in arrear:
- Specify possible tiers with policy
It is important to understand that it is not in the vendor’s interest to come up with a complex usage model, because then that needs to be explained to the customers using the service. However, even if vendor’s usage model is not too complex, the set of possible configurations across vendors, each of them with their specific variations remain large and challenging to model/configure.
We would be happy to get feedbacks on usage patterns that seem to be missing from that post.
