Monetization models
Products can be traded in many different ways. Some of these ways can actually contribute to the value of the product, why it is interesting to explore these ways. In the old times, when merchandise was all about “things” that you could hold in your hand or at least see and touch, the process was simple. Agree on a value of the thing and exchange the thing against a sum of money. Done! Simple as that.
With the introduction of non-tangible things like Services or Software, that have a value, or performance which may change with time in a less predictable way, it becomes less obvious how these should be charged for. Typically business customers nowadays think that it is may be a good idea to not spend too much money before securing their own revenue streams. Hence they are increasingly interesting to find out if their expenditure can be moved from stacking up the balance sheet, to instead become an operational expenditure, that more closely matches the earned revenues.
Conversely, by changing their business models from the traditional CAPEX based payment models to OPEX based, vendors may find that this opens up for an an opportunity to gain new customers or upsell to old customers. With an OPEX based model the vendor also gets a steadier stream of revenues and becomes less dependent on the end of quarter revenue chases. Also valuation of businesses that adopts these new models have been seen to increase. So there are many good reasons to look into this!
In the IT industry the process of converting products, that relates to Software (SW) and Services, to cash is termed “monetization” of these products. The corresponding product offerings are often termed “XaaS” ( X as a Service) and are often offered on a subscription or usage based basis. Typical XaaS are Software as a Service (SaaS) or Platform as a Service (PaaS). “Platform” typically translates to infrastructure or Hardware (HW). However other terms like “Software Subscription” are also common.
There basically exists three monetization models
- Perpetual
- Subscription
- Usage based
The terminology is derived from a software license context. “Perpetual” comes from “perpetual SW license”, meaning that the licensee is provided a perpetual right to use (RTU) the licensed functionality. That is, he bought the RTU of the license for ever by paying a sum of money upfront. Subscription and Usage based models are just what it sounds like, paying on a regular basis for the right to use the licensed functionality with a fixed sum (subscription) or a sum that is related to the actual resource consumption (usage based).
For SW products all three models are in play, while for HW, “perpetual” is the norm but also “subscription” in form leasing and rental exists. “Usage based” charging for HW things has been very unusual (but there have been ideas around this, for example vendors of cargo trucks that would like to charge for extra motor power enabled upon request when the truck climbs up a long hill).
Within the IT segment the view on HW is largely changing now with the “cloud processing” paradigm. Here the perception of HW is changing from being seen as a device to becoming more of an infrastructure utility which also should be charged for like an utility, that is on usage. On the Services side, “perpetual” for services like support does not seem like a useful idea, they are typically charged for in a subscription model.
So we see that there are different fits for the different monetization models.
Characteristics
Let’s try to classify these monetization models and see what properties they exhibit. This is a useful exercise, since especially “subscription” and “usage based” models are often mixed up.
| Characteristic | Perpetual | Subscription | Usage based |
|---|---|---|---|
| Right To Use license scope | For ever1,2 | During subscription period | During contracted period |
| Financial | CAPEX | OPEX | OPEX |
| Cash flow / Billing | Upfront | Periodical | Periodical |
| System support required (for billing) | Low | Intermediate | High |
| Cost predictability | Predictive | Predictive | Un-predictive |
| Typical license flexibility3 | Fixed | Fixed/Floating | Floating |
1) There is a version of this model that could be termed “time-limited”. It has the same essential characteristics as a perpetual and only differs in that the license is not perpetual but has a defined end time. Therefore it also share some characteristics of a rental model.
2) Depending on the license flexibility (see below) “for ever” could also mean “until the device the license belongs to has been de-commissioned or otherwise ceased to function”. In other word the license RTU ceases when the associated device is scrapped.
3) Fixed licenses are locked to a certain device, while floating licenses are allocated from a pool of licenses when needed. Hence floating licenses can be re-used and re-allocated, giving them a higher value than the corresponding fixed license. All monetization models can have fixed or floating licenses, table shows how they typically are used.
From this characteristic we can learn that there is a natural evolution in the utilization of the monetization models that goes from left to right:
Perpetual -> Subscription -> Usage based
The reason for this evolution is that the the major objective is usually to transform a CAPEX model into an OPEX model, and going from a perpetual to a subscription model is the easier step since usage based billing requires more complex system support. On the other hand, the transition to a usage based model opens up for more flexible payment terms and hence a greater customer appeal.
Going from perpetual to subscription provides major advantages for both the customer and the vendor. The subscription OPEX character means that customer can more closely match their costs to their revenues, which is typically desirable. The predictive character of the costs/revenues is an advantage for both the customer and the vendor.
Going from a subscription model to a usage based model is beneficial when the usage is substantially “bursty”, i.e. has a high degree of on-off characteristics. There should also be a degree of un-predictability in the usage, since if the usage could be estimated, a subscription fee could be negotiated to cover this estimated usage. On the other hand, usage based charging has a very high customer appeal in that the customer only pays while using the actual functionality.
So while the value of changing from a perpetual to a subscription model is disruptive in going from a CAPEX to an OPEX model, the change from a subscription to a usage based is more incremental from this respect. But the gains in the flexibility of business models that can be utilized with usage based monetization models should not be under-estimated. Usually, when a vendor has implemented a subscription model, he starts to think “how do I make this a usage based model…”
As mentioned before, in hyperscale (cloud) operations usage based is the norm. Hyperscalers have usually built in the needed measurement capabilities and billing functionality into their infrastructure from the beginning.
Considerations when changing model
Vendor perspective
There are some major aspects to consider when deciding to change, or complement with a new monetization model. A vendor for example, may have different ideas on why and how to change from a perpetual to a subscription model.
In a simplistic view the vendor just takes his perpetual license price and calculate a new, per month or year subscription price, by dividing the perpetual price over a depreciation or pay-back time and adding an interest term to the subscription price. This is not very innovative, it is merely a way to find a another means of financing the purchase. Instead the vendor could then turn to a financial institute and have them finance the CAPEX cost for the customer with some kind of annuity solution.
One of the major opportunities in changing the monetization model is that the vendor may re-evaluate his business model and his offering to the market. A successful introduction of a new monetization model could for example open up new customer segments, or increase revenue in old. Below follow an example of such an adjusted business model.
Typically subscription offers tend to be all-inclusive. I.e. instead of selling lots of small items plus support and maintenance updates and possibly feature upgrades as well, the vendor sells a subscription package that cover all this. This package becomes a “living matter” that evolves during the subscription period and hence gives the customer an increasing value that motivates the subscription fee. A typical example would be a Microsoft Office 365 subscription. There are no alternatives there and as customer you’re happy because you don’t have to think of what is included or not. Because all is included. Would it be cheaper if you could cherry pick the functions you think you need? Probably not, because the package price is based on what people in general use anyway, and it doesn’t cost Microsoft more because they throw in what people not use for free…
If the vendor sells a mixture of hardware and software, he should probably consider the revenue distribution between these. Would it be possible to shift revenue from the hardware to the software? That could be a good idea for several reasons. Cheaper hardware lowers the threshold for the customer to start using the vendors solution. In a world were hardware prices follow Moores law in decline and may eventually be replaced anyway by some cloud infrastructure it is risky to bet too much on revenue from this hardware.
Lastly, a severe complexity that the vendor must manage when changing (or rather complementing with a new) monetization model is how to handle the models is parallel and avoid “cherry picking” between the models. If the new model is like in the first example, just a different financing model of the purchase, this is not a problem, the customer can just pick and chose what suits him best. But if the new model also brings large shifts in the business model, in how revenue streams are shifted etc., it may become a mess if these models are mixed. This must be considered throughout the transition project.
Customer perspective
From a customer perspective the option to buy a subscription instead of cashing out a much larger sum upfront should be a welcome alternative. But this of course depends on the type of customer and his situation. If the customer has a strong balance sheet and can invest in a perpetual model purchase, and know that he will use that solution for a long time, it may be more cost effective in the long run.
But in general the customer would like to match his expenditure with his expected revenues from the good he disposes. The reason for this could be budgetary, that CAPEX purchases are limited by rule, or that the customer don’t want to take the risk that the investment will not return as expected. Also if the subscription offer is simple and all-inclusive, the customer can direct his brain power to more rewarding tasks than negotiating all the items and services of the perpetual model with the vendor.
The customer should also consider the cost of capital saved when subscribing to a product rather than paying for it upfront. The net present value (NPV) of a series of future payments is lower than the sum of the payments, given a positive discount rate. However, this knowledge is only useful if the customer can compare between a perpetual (or time limited) upfront price and a subscription price.
Final words
There are many challenges when changing from a traditional perpetual CAPEX business model to a subscription or usage based OPEX model, but it is a potentially very rewarding move, both for the vendor and the customer.