Introducing a new license management solution to your back office can bring tremendous value to your business. But without proper planning, the transition from legacy system to new solution can easily go awry.
How long will it take to get up and running? Without a doubt, this is the question I get asked the most as a software licensing solution consultant. Instead of simply giving you the obvious answer nobody wants to hear (yes that answer is “well, it depends”) I will simply answer the question.
The software protection business has matured at a slow pace over the past decade. The industry has gotten better at developing improved customer experiences through more sophisticated web portals and web services, but ultimately the model’s foundation relies on license file transfer between the vendor and the end customer.
The improvements in the area of cleaner customer experiences through web services has allowed some vendors to minimize a fair amount of the friction this style of license enforcement has introduced into the traditional delivery and deployment model.
As an engineering and product management team tasked with designing license enforcement into your products, you have many decisions around how your products will interact with the licensing code. Here’s a proven technique that will help you control how licensing gets implemented across your product lines while making the product teams’ lives easier at the same time: build an abstraction layer.
This question recently appeared on Quora, and I thought it would benefit our readers to hear the answer.
“What is standard practice for when companies want to “switch seats” in a SaaS licensing context? I run an early-stage SaaS company and we sell on a per-seat basis. Occasionally I’ll get a request to switch a seat from one user to another. Sometimes this is because someone left a company and in other cases it’s because a user isn’t very active and they want to switch to someone who will be more active. What is standard practice here for this? Obviously we’d prefer that a new seat license be purchased rather than transferring a license but we also want to try to be flexible given that we’re a start-up”
This question reaches outside of the SaaS domain and applies to many per-user or named-user license models in the traditional on-premise environments.
This is a juicy question was posed on Quora (http://b.qr.ae/HmF392). I was intrigued by a couple of the responses and added my own. Here is my view…
The answer is …
My last blog discussed building a business case for implementing a software license enforcement system. A key component of the case should be a plan to minimize negative impact on the customer base. This article offers a handful of practices designed to help you ease your customer roll-out. While not every practice can apply to all cases and to all business, each should provide some food for thought.
This is a multi-part blog where we’ll look at the business case around a license enforcement system from many different angles. This article will begin the discussion surrounding the initial business case for initiating a license enforcement project. Follow-on blogs will focus on measuring the return on the investment of a licensing system after implementation.
Does the following story sound familiar?
“Hello, it’s Steve in Product Management.”
“Hi Steve, it’s Ian in Sales. I’m looking at the price book and there’s a different license part number for every version of the product. I see dozens of them. My customer wants to use various versions of the product across teams. Can I just put the latest version on the quote and tell them they can use the licenses with older versions too?”
“I’m not sure. You will have to ask Legal.”
“I need to get this quote out now. Why is it like this?”
“I’m not sure about that either. You’ll have to ask Operations.”
Including product versions as attributes of your license part numbers may seem like the obvious right thing to do. In many cases it works perfectly well. But before going down that path, you should think through a few factors.
In my last blog entry (Show Me The Money, Part 1) we looked at a number of factors that play into software revenue recognition when a vendor (ISV) introduces electronic license enforcement into their product lines. Part 1 focused on the principles and mechanics behind giving customers access to the software upon order execution so that the ISV may recognize revenue. Part 1 concluded by bringing another key element into the revenue recognition equation: time. Time can affect revenue recognition in a number of ways: