The Fine Art of Token Licensing

The Token License Model (as a variant to the floating license model) is a great way to provide flexibility to your customers.  By selling tokens that can be used to invoke multiple products, you provide a lot of flexibility to users who can’t always accurately predict what to purchase.

Implementation & Planning Considerations:

Using tokens as a mechanism to control access to products requires some careful thought and planning.  Typically, the Token License Model is implemented in conjunction with a license manager technology, and operates something like this:  before a product operates, it makes a request to check-out or consume tokens (non-product specific license keys) from the license manager.  Based upon the availability of tokens in the pool at the moment of the action (determined by how many tokens were originally sold to the pool less how many tokens are consumed at that moment), the request is either granted or denied.   While the implementation of this token license model is easily accomplished in the software when a license manager is present, there are some important policies that need to be established before an implementation begins:

• How many tokens do I need for each product when it operates? 
  That is, how is a token calibrated to list price?  What is the sufficient granularity of value for a token?  Is it $500 per token? $1,000 per token?
• How do I handle list price changes to software?
  If a product is designed to consume 5 tokens when it runs, what happens when the price of the product changes, especially if the software is already installed in the field?   Suppose the new list price warrants that 6 tokens are consumed for each invocation but customers are licensed for a version that checks out 5 tokens.
• How do I measure the usage of actual products when tokens are consumed?
  License managers typically record all license key request activity in a usage log for subsequent asset management and usage profile analysis.  In a non-token license model, a particular product will consume a license key that is specific to a particular product.  That way when the usage log is inspected, the usage attributed to a particular product can be understood by looking at the number of times specifically-named license keys are consumed.  When generic tokens are checked out, however, all usage is attributed to a generic token. It’s impossible to understand which particular product consumed the token.

All of these issues can be easily addressed in a design phase, but they must be carefully considered during the planning and implementation phases.

The Temptation of the Token

One of the more seductive aspects of a token is the capability to allow customers to access future products that were not available at the time the original sale was made.  For example, at the time of the sale, it’s easy to tell customers that a new, desirable product will be available in 6 months, and that it will automatically operate with the token system.

While such an assertion is appealing, there is a potentially serious downside:  Some or all of the revenue associated with the agreement may be deferred until the new technology is available.   The topic of revenue recognition was discussed in some of the earlier blogs in this series under Subscription licensing.

It’s very important to define and bound the parameters of future technology access whenever customers are provided with a flexible model like token licensing and to carefully consider the impact of revenue recognition.

Token Licensing – are you thinking of adopting such a license model?  What are your challenges with token licensing models?