Entitlement and Compliance Management

More on Token Based License Models

by: Cris Wendt

 

As briefly described in the previous blog, a flexible license model that is gaining some traction in the market is a token license model.  This model is very effective for software publishers who have a wide portfolio of software where the usage patterns for individual software applications are difficult to predict.  This situation often occurs in technical markets, where the portfolio of software is used in a design flow, or to conduct a software experiment.  Users may not be able to predict how much software to purchase at the beginning of the purchase cycle as usage may be dependent upon the challenges faced in a particular design.   For example, in electronic design, a particular design may require more simulation software than previous designs have required.  

 

From the perspective of the software producer, it’s also an effective way to fortress a market position against point-tool competitors.  The token license model makes it financially easy for the customer to utilize the entire portfolio of software, and not try to buy all the software required for every part of a design flow.

 

Expiring Concurrent Tokens

The simplest form of token license model is implemented as a variant of a floating license model.   With the typical floating license model, each time a particular software product or title is run, it checks-out a license key from a license server for the duration of operation.   For example “Software A” will request a particular license key associated with “Software A” from a license server whenever it runs.  If the license server has licenses available, the software is granted a license to run.  The software will return the license to the server when the software is exited.  Similarly, “Software B” will request a particular license key associated with “Software B” from the license server whenever it runs.

 

When deployed as a token license, the software publisher creates a generic license key “token” instead of a license key associated with each product – the idea being that products don’t check out product specific licenses, but rather, checkout one or more generic tokens – the amount of which is weighed toward the list price of the product.   With this model, the customer downloads the software for a suite of products from a publisher’s portfolio, and then purchases a number of tokens that enable the software.

 

For example, let’s say I download the software for Product A and Product B, and buy 4 tokens.  The way the tokens have been designed, “Product A” checks out 3 tokens when it runs (and returns the tokens when the task is completed), whereas “Product B” may check out 2 tokens when it runs (and then returns them when done).  

 

With 4 tokens, I can concurrently run 1 copy of Product A (with 1 token un-used), or 2 copies of Product B.  However, if I purchase, say, 6 tokens, I could concurrently run 2 copies of Product A, 3 copies of Product B, or, 1 copy of Product A, and 1 copy of Product B (with 1 token unused).

 

Tokens are typically implemented as a subscription license, which expires at the end of a term such as a year.  This provides the software publisher with some revenue upside as a result of offering this increased flexibility.

 

Consumptive Tokens:

A pure-play consumptive token, like a gumball machine, is a “use it up” model.  In this model, when Product A runs, it checks out 3 tokens which are then consumed and then no longer available. This type of license model applies best when licensing software that is transaction-oriented and the software publisher wants to charge based upon the total number of transactions.

 

 What has been your experience with token license models? How are they impacting your business? Do they represent a growth strategy?

 

Next Week – More of the Nuances of the Token License Model

 

Flexible License Models– Which One is Right For You?

In the previous blogs, we discussed subscription based licensing which combines the right-to-use along with access to software updates for typically a yearly fee. This week’s blog looks at a few examples of Usage Based Models.

 

All of the commonly usage-based license models will have five important elements that are often “throttled” to achieve different business results:

 

1) The breadth of software access (some or all products)

2) The term (or combination of terms) over which the license can be used or is applicable

3) Maintenance/support inclusion

4) Payment terms (upfront, or in arrears after usage occurs)

5) And associated business policies to govern acquisition. 

 

Most usage-based license models have some built-in pricing premium to account for the increased value, the flexibility of usage provides to the user.

 

Below is a sampling of some common usage models that we have helped our customers deploy:

 

Term Licenses: Licenses are available in a variety of pre-configured terms and price-points, such as 3-year, 2-year, 1-year, 6-month, 3-month, 1-month, etc.  This allows the customer to establish a budget and purchase products when needed.   Some frequently used products can be purchased for the longer terms such as 3-year, whereas sometimes products may only be required for 1-month to meet seasonal or peak-usage demands.  Term licenses are often sold with caveats or business conditions, such as licenses sold with a term less than a year can only be purchased when the same software license for 1 year or more has been purchased (because they are sold as “overdraft protection”), or whether or not maintenance is included (as one way to control the revenue recognition effects).

 

Remix:  The customer has access to an identified set of software for a term such as a year, but the customer can change the quantities or some percentage of the software periodically (e.g., 25% of the list price value can be changed quarterly) to phase out software that isn’t being used and replace it with software that is in high demand.   Extreme care must be given to revenue recognition affects when allowing customers to access software over the term of the license that were not available at the time the remix license arrangement is initially constructed.  Maintenance is typically included.  This is used often in the Electronic Design Automation (EDA) industry.

 

Token:  There are many variants of tokens, but in general a token is a granular unit of measure, either in dollars (to represent cost), or activity (e.g. 1 transaction) that can be applied across multiple products in the product portfolio.  The customer will typically buy “X” number of tokens, which will then be counted and “consumed” as the software is used.  Tokens are typically purchased in advance of usage and counted down until exhausted. For example, an hour of using Product A may consume 1 token, whereas using an hour of Product B may consume 2 tokens.   Typically, maintenance is included.  Tokens are used by various companies in the design and engineering markets, including Silvaco, Accelrys, Aspen Technology, and others.

 

Workbench: A defined set of software is licensed as a unit based upon the role of the user of the software (e.g. basic accountant, expert accountant, etc).  There is a billing event if any of the software is used during the course of a period (e.g., a quarter).  Since the software is sold based upon a user’s role, there shouldn’t be a huge amount of usage variance among different types of users, but some variance is tolerated and built into the license model and associated price structure.  Maintenance is typically included with the license.  Wind River has employed such an approach.

  

Debit Card: This is not so much a license model as it is a financial arrangement and fulfillment mechanism to deploy pre-defined term licenses or tokens.  With a debit card, the customer pre-pays a dollar or token amount, and then draws-down against the dollar amount the software as it is needed, in the quantity and timeframe required. There may be business rules such as the minimum value of the “deal”, and the timeframe over which the software must be deployed, as part of the T’s and C’s.  Sometimes the dollars are also called “tokens”.  Maintenance is typically provided along with the software provided in the debit card.  Cadence Design systems employs such a system called EDA-on-Tap.

 

Acresso Global Consulting Services has developed a tool that can help you determine if a usage-based model is appropriate for you. The results will help facilitate a discussion on which of the different flexible models may apply best for you. If you would like to have access to the tool, please let us know!

 

Tell me about the models you are using?

If you are an enterprise, what models are most attractive to you financially and for your business?

 

Next week:  More on the token license models.

Beyond Subscription Licensing – Flexible License Models

In the previous blogs, we discussed the addition of a subscription license model as an alternative method to license and sell your products.  The subscription license model, which combines the right-to-use along with the access to software updates for (typically) a yearly fee, can help you penetrate new markets by making your software more attractive to customers who prefer a lower start-up fee or who may need to account for the software from an expense budget.

 

However, the subscription license model is really only the tip of the iceberg when it comes to selling your software using a different license model.  The goal of selling your software with a new license model is to make it easier for your customers to do business with you, allowing them to buy software in a way that makes sense for their businesses. 

 

Balancing Usage Flexibility with Financial Predictability

 

The ideal flexible model is the “pure” pay-per-use license model.  This involves licensing and pricing software based upon the amount of software that is used, as measured (or metered) by some metric that represents meaningful usage data for a particular product (e.g. minutes of usage, number of transactions, number of TB of managed storage, number of documents processed).   This is similar to how we pay for utilities such as water or electricity – the more we use, the more we are invoiced at the end of the billing period.  In many ways it seems like an ideal model. 

 

Our experience with customers has shown that pure pay-per-use license models are not frequently deployed by software publishers, largely due to the lack of financial predictability of such a model. Usage can vary wildly, and therefore, so can the associated license fees.  Both the producers and consumers have little visibility to the financial impact on their organization.   It’s this lack of predictability that has largely prevented the proliferation of pure pay-per-use license models.

 

When and Where Usage-Based License Models Resonate

 

What we see frequently is that software producers sell software with a license model that balances some amount of usage flexibility with reasonable financial predictability, for example a term license model may offer a variety of pre-configured license terms and price-points, ranging from 1 month to 3 years.  This allows the customer to establish a budget and purchase products based on need and usage patterns.   In our next blog we will dive deeper into additional hybrid models that combine usage flexibility with financial predictability, but before doing so, it’s important to realize that usage based license models won’t apply to all software sold in all markets, but they do tend to resonate when one or more of the following factors exist. We see these quite frequently in the technical vertical B2B markets such as Electronic Design Automation, Mechanical CAD, Software Development, Oil & Gas Exploration, and Life Sciences & Medical Research: 

 

· The “buyer” is a large customer of the software producer with a sizable annual budget.

· There is a wide portfolio of software or complex enterprise software offered by the producer that the consumer of software may require, but where the forecasting of exactly when/where the software is used may not be well understood at the time of the purchase.

· The software is expensive to procure, typically costing tens of thousands to hundreds of thousands of dollars for a single software title.

· Where a market is maturing and the software producer is looking to protect a market position against point tool competitors by making it financially enticing for the customer to buy an entire suite of software.

· The software producer is trying to enter a market and create an advantage by lowering the barrier of entry to acquire and use the product.

· The software license is purchased within the context of a project expense budget.

· “New” computer environments are employed to run the software, including SOA/web-services, grid computing, SaaS, or virtualized computing.

 

Usage based license models probably don’t make a lot of sense in the B2c situation, where the software producer is selling inexpensive (or low value) desktop software to consumers.

 

When it comes to usage based  licensing, has your company adopted such an approach? And if so, what kinds of license models have you rolled out? Let us know!

 

Next Blog: Which of these usage based models is right for you -- term licenses, remix, consumptive token, or debit card?

Myths and Legends – Subscription Pricing, Revenue Recognition & “The Dip”

The Perpetual Software License Model as an Addiction

 

Almost all software companies that sell software with a perpetual license are addicted to the end-of-quarter “hockey stick” that drives the CFO to drinking.  The hockey stick is the folksy description for how the revenue profile of a software company might look on a quarterly basis if plotted over time:  The sales of software licenses tend to be slow early in the quarter, then escalate rapidly during the last week of the quarter when 70 – 80% of the licenses are “booked”.  An accounting process known as “revenue recognition” allows the software company to allocate all license fees associated with the sale or bookings of the perpetual license to be recognized as revenue during the quarter during which the license is sold and delivered.  The problem is, the executives don’t know if they are going to “make the numbers” until the last day of the quarter. 

 

I Want to Go to Heaven, but I Don’t Want to Die to Get There

 

Executives often think, “There must be a better way – how about the subscription license model?”  However, any mention of the subscription license model and the common response tends to be: “we can’t do that! We are a public company and can’t handle the revenue dip”.  

 

Such a statement reveals the fear that the revenue recognition process associated with selling subscription licenses will have a disastrous transition effect – the revenue associated with the sale of the software license affects the P/L statement for several quarters over the lifetime of the subscription license.  In effect, the hockey stick gets flattened.  The positive for company management is that revenue becomes more predictable in subsequent quarters after the initial sale. But there will be a revenue reduction or “revenue dip” in the quarter during which the subscription license was sold.   In the steady state business model of a company that sells subscription licenses, there isn’t a problem as there isn’t a transition.  In fact, the CFO’s job can be simplified as the revenue for subsequent quarters becomes more predictable based upon the sales bookings of previous quarters. 

 

While many of the statements in this paragraph are factual, they don’t lead to the truth behind what happens when companies adopt subscription license models.   Subscription licenses don’t lead to a corporate-wide revenue dip when they are rolled-out.  Furthermore, subscription license models aren’t best used to fix sales behavior or revenue recognition problems. They should be used to open up new market opportunities.

 

So, let’s dig a little deeper…..

 

What Really Happens – Establishing a List Price for the Subscription License

 

In previous postings we described the subscription license model and the value it brings. Let’s now start with how a company might price the subscription license model to understand the situation more fully.  It seems on the surface that trying to compare the pricing of a subscription license model to a perpetual license model is like comparing the pricing of apples and water! 

 

However, software license “assets” tend to be viewed as having a useful lifetime, not unlike a physical asset such as a computer.  It is this perceived useful lifetime that forms the basis for valuing and pricing a subscription license.

 

Most companies that buy software licenses view software has having a 3 – 5 year lifetime. So let’s assume for the sake of an example that a particular customer values the software as having a useful life of 4 years.  If the perpetual license for this software is sold for $100, and there are $20 of additional annual license maintenance fees, then after 4 years (ignoring the time value of money), the customer has invested $180.  If 4 years is the perceived lifetime of the software, then the annual value must be about $45 ($180 / 4).   This example is very close to what happens in real life, even though pricing is a much more nuanced and complex topic. 

 

Clearly, if the customer purchases the subscription license rather than the perpetual license, then the software publisher only receives $45 for the first year of license fees, rather than the $120 they might otherwise (assuming no discounts).  If the relationship remains steady, then the software publisher actually makes more money in the long run.  This is very much the financial arrangement present in leasing assets.

 

What Really Happens – Revenue Recognition

 

In a nutshell, because the subscription license combines the software license and the delivery of ongoing software updates in a single offering, the revenue associated with the subscription license has to be recognized in a smooth way (monthly or quarterly) over the term of the license to reflect the ongoing delivery of new value in the maintenance releases. 

 

If we take the example from the previous section, in a subscription model, the $45 that would have been paid for the annual license must be “recognized” as occurring in either $11.25 quarterly increments or $3.75 in monthly increments. 

 

It is true that quarterly revenue for a company would be significantly reduced quarter over quarter if in Q1 all of the users purchased a perpetual license, and then in quarter 2, all users purchased a subscription license.  However, in reality, this is never what happens.  Usually, revenue increases when a company introduces a subscription license model.

 

What Really Happens – Subscription License Models as a Way to Increase Revenue

 

The market reality that we have seen in many market segments is that the subscription license model is offered as an alternative to address market needs not met by the perpetual license model.   It becomes another choice and not a wholesale change to another license model.

 

In this context, the subscription license model is offered to address unmet market needs.  Several years ago at a SoftSummit conference in Santa Clara, I asked how many attendees offered a subscription license model for their softgware.  About  1/3 of the room raised their hands.   When I asked those 1/3 how many had a revenue dip when they offered the subscription license model, all of them lowered their hands.  When I asked how many had increased their revenue when they offered the subscription revenue, 2/3 of the original 1/3 raised their hand. 

 

While this wasn’t scientific, it was illuminating.

 

The Unspoken Lever – Sales Compensation

 

If you do have a business objective to sell either the subscription license model or perpetual license model as your primary license model, be sure that your sales compensation program is aligned with your objective.  For example, if your goal is to sell more subscription licenses, don’t compensate your sales force solely on recognized revenue because they’ll be incented to sell more perpetual licenses.  On the other hand, if you compensate the sale of a subscription license model at a higher  percentage of bookings than for a sale on the perpetual license model, you may get different behavior.

 

The Subscription License Model can be a powerful addition to your product offering, be sure not to sell it short!

 

Are you tired of the hockey stick model?

 

Have any of you tried offering a subscription model at your company?  Why or why not? What has been the impact?  Let me know..

  

Next – Beyond Subscription Licensing: Establish Market Leadership With Even More Flexible License Models