Atomic Energy

So having gone through the above (see previous posts), there are basically two choices when it comes to implementing licensing schemes.

1. Sell the upgrade. Many sales systems, even fairly primitive ones, support this. You create a separate SKU for each major release, and possibly for each minor, and a separate license key scheme for each major release (but not minor). The licensing ensures that different minor releases within the major release will allow cross-upgrades (or downgrades). For the sales, you create a coupon that says, “if a return purchaser bought one of the following SKUs (all those in the previous major release), give them x% off for this SKU (all those in the latest major release). Note that some systems do have limitations with this. For example, esellerate can apply the coupon for everyone, one time, or one time by email. But what if a previous purchaser bought 3 copies? Well, then, you are out of luck.
2. Sell the plan. You need to manage your customer data set on your own. You then need to manage the customer interaction with the sales system, so that only appropriate users see the appropriate pages, either the regular SKU with an appropriate applied discount, or special discount SKUs. 

Inevitably, one will ask, can any sales system handle being so controlled from your Web store, such that it will only display appropriate pages to appropriate people? One does not want to have a new buyer get to the supposedly hidden pages and get the product for free! As the old saying goes, “security by obscurity is insecurity.” Here is a short summary of what I have found.

1. No open-source cart system manages this. Period. Zen-Cart, osCommerce, CubeCart, even the new Magento all fall short. Nor I have seen a commercial system that manages it.
2. The sales channel providers, like FastSpring, which combine sales management, reporting, up-sells/cross-sells and the like, but have the actual catalog per se on your page, are focused on letting you sell anything you want, provided the URL is correct. Needless to say, this is not something they offer. FastSpring is pretty impressive, but is not built for this. 
3. Surprisingly, the best solutions come from the least-featured providers. PayPal Website Payments Pro, Google Checkout XML API and Amazon FPS all are strong in this area because they allow your site to talk to their service, server-to-server, and will reject any transaction that your server has not approved. The downside to all of these is that accepting credit-card information means you must become PCI-DSS compliant, a not-insignificant effort. It is not very difficult, especially if you never store credit-card information, and almost all of the recommendations are good security practice, but a small ISV may simply not have the time to deal with it. I recently worked with a client on converting to PCI-DSS compliance. We did the analysis very quickly, but the conversion is taking time. 
4. The lower-end services of these Internet giants are less functional in this area, with one shining exception. Google Payments HTML API and Amazon Buy Now buttons both depend on data stored in the user’s browser to submit payment information. A user could easily change the information and get the cheaper or free prices, and even set up a Website to make it easier for others. The shining exception is PayPal, which is strong because of its weakness. Like the others, PayPal’s Payments Standard system is built around buttons that are configured and submitted from the user’s browser page. Because users can modify these and submit, thus cheating the ecommerce seller, there is an option to encrypt the buttons, thus allowing PayPal to authenticate that the values are valid. Put in other terms, PayPal’s need to resolve its weakness provides a strength in dealing with this issue. 

A number of providers also provide post-processing notification. FastSpring has Notification by POST to a Web site, PayPal has IPN. These can provide backstops, but they are not recommended for this purpose. Why? Because they only allow you to confirm or deny a sale after it is done, meaning the user thinks s/he is done and then gets told, sorry, no deal. This may even run afoul of consumer protection laws.

Conclusions:

1. For the short-run, if you need to boost sales by selling upgrades, sell upgrades to major versions, free updates to minor versions, and use whatever your sales channel will support.
2. For the long-run, get control of your customer data within your own databases, and provide authenticated Web API access. Wrap the data with a business logic layer, and then provide interfaces to your sales channel, so you can control how customer specials are managed.
3. If you need more complex structures, use PayPal or similar services until the mid-channels are mature enough to provide them.
4. Hopefully, at some point, the mid-channels like FastSpring will expand to provide these services.

In the previous post we discussed implementing Option A: Sell the Upgrade. Now we will address Sell the Plan. 

Sell the Plan has a lot of appeal for ISVs, especially when you start to sell to businesses, non-profits, or any group that budgets. The benefits are:

1. Predictable cash flow. The reality is that most individuals and organizations that have recurring charges simply keep on paying them. This creates more predictable cash flow for your ISV business.
2. Earlier revenue recognition: Let us assume that you release version 1.0 in Jan 2006 and 2.0 in Apr 2007. If you sell the upgrade, the purchaser of 1.0 will wait all the way until April to pay you. On the other hand, if you sell the plan, by Jan 2007 he is already paying you the plan fees for the coming year.
3. Easier recurring sales. Most organizations budget capital expenditures, especially for new purchases, separately from ongoing operating expenses. The $50 they will spend next year to buy the next version of your product must be approved and budgeted, and for the following version, and again. On the other hand, if buying the product the first time comes with an annual $50 charge for “maintenance,” it gets built right into the ongoing operating budget and is automatically approved.

It is important in this scenario to give new purchasers at full retail a “free” year (more or less, depending on your customers, but a years is fairly standard) of upgrade plan. The free helps you sell, but also avoids the sense from them that they are getting no support in terms of patches, upgrades, etc. 

So how do we go about implementing “Sell the Plan?” Again, we have multiple scenarios.

1. New purchaser: This purchaser simply buys the product outright at full retail price, in our case $100.
2. Return purchaser on plan: This person should be able to upgrade for free, whether it is because they are within their “free” year, or because they are within another year (or ten) of paid plan.
3. Return purchaser off plan: This person should be able to upgrade, but not for free. Instead of buying the new product, they buy another year (or more) of plan. This plan is normally sold at some discount off the current retail price of the product. In our scenario, we will assume it to be 50%.

How does implementation of each of these scenarios happen?

1. New purchaser: This is a standard sale. The purchaser buys it outright, gets a license key, installs, and goes.
2. On-plan purchaser: This is complex. This can be implemented either via the licensing system or the commerce system.
   • Licensing system: The licensing system needs to issue licenses that understand when upgrades are allowed and when they are not. It further needs to recognize when a version was released, compare that to the range of dates for which upgrades are allowed, and then allow or disallow the upgrade. I have not seen a single, solitary license system that can do this.
   • Commerce system via product SKUs: As in the “Sell the Upgrade” scenario, you can either have limited availability SKUs or the same SKU as new purchases, but with special coupons. In either case, the commerce system needs to  recognize that this is a returning user and precisely what rights they have. I have seen no commerce systems that do this correctly, either. The closest I have seen is that some systems will issue coupons based on previous purchases of a particular SKU by a returning user. However, these systems all treat the upgrade (for free) purchases as if they are new, and thus give them a whole new year for free.
   • Commerce system via plan SKUs: This is an approach that no commerce system has recommended, yet offers an intriguing new way. Each product has its own SKU, and each plan for free upgrades (12 month, 24 month, etc.) has its own SKU. When someone purchases a product outright, they receive the free upgrade SKU bundled with it. When they come to upgrade, the commerce system should recognize that they have a recent purchase (within time frame) of the plan SKU, and either give them access to the limited availability free upgrade SKU or the appropriate discount coupon for the regular SKU. Again, I have seen no commerce system do this outright, but some have shown flexibility in the right direction.
3. Off-plan purchaser: An off-plan purchaser is one who once was on-plan, and is now off. Essentially, they need the ability to subscribe to the plan again. This requires a separate SKU for plan, followed by a recognition of the ability to join the “free download” group. However, it is important that the commerce system only allow someone who once purchased to join the plan, else anyone will just buy the plan SKU at less than full retail and get free upgrades.

Conclusions:

1. Commerce system intelligence is a must. No system has shown the ability to do this, but some have shown promise. See my follow-up post on commerce systems.
2. Some of this can be handled in licensing, but some must be handled in commerce systems. As before, make commerce systems your focus.

As a follow-on to the previous post about licensing strategies for ISVs, I would like to discuss the nitty-gritty implementation details. It turns out that the open market has not been very kind to mISV firms, and have left with very few options, none of which provides the desired flexibilities. This post will discuss “Sell the Upgrade.” A follow-on will discuss “Sell the Plan.”

So you want to implement sell-the-upgrade. To do that, you need to have several scenarios, all working in concert. You have released one products with three versions: 1.0, 1.5 and 2.0. You are currently selling 1.5, but will soon start selling 2.0.

1. New purchaser: This is, of course, easy. You have a single product, call it SKU15, representing version 1.5. Everyone pays full price, say $100.
2. Return purchaser: This is someone who already bought 1.0 and now wants to upgrade to 1.5. The return purchaser should pay nothing for version 1.5, as it is a minor upgrade. You have a few choices: 

• Keep the same SKU for upgrade purchases and new purchases of all releases of the major version of the product. SKU10 covers version 1.0 and 1.5, whether new purchase or upgrade. Rely on your licensing system to recognize the allowed upgrade. This usually works if the same license set covers both version 1.0 and 1.5.
• Use the same SKU for upgrade purchases as for new purchases, but different between minor versions, and rely on your commerce system to recognize that this purchaser bought 1.0 already and is thus allowed a 100% discount off the purchase price of that SKU. 
• Use a different SKU for upgrade purchases than new purchases, say SKU15U (U for upgrade), and rely on your commerce system to recognize the allowed purchase. In other words, it is a limited availability SKU. 

In both of the commerce-system-dependent solutions, an upgrade means buying the new product, but having the commerce system recognize the purchaser as someone who purchased before, and thus give them the product at 100% off, either via discount of limited availability SKU. It is important that the commerce system recognize that the purchaser is a returning purchaser, and exactly how many copies they have the right to upgrade. For example, someone who bought 5 copies of 1.0 should have the right to purchase 5 copies of 1.5 for free, but not 50 copies. There are varying ways to do this, but very few, if any, commerce or cart systems seem to know how to manage this.

Now we move to major upgrades. People are buying version 2.0.

1. New purchaser: This is, again, easy. You have a single product, call it SKU20, representing version 2.0. Everyone pays full price, say $100.
2. Return purchaser: This is someone who already bought 1.0 or perhaps 1.5 and now wants to upgrade to 2.0. If you don’t give upgrade discounts, it is very easy: they are just like a new purchaser. However, most ISVs, especially mISVs, give upgrade discounts. For argument’s sake, let’s say our discount is 50%. The return purchaser should pay $50 for this upgrade. Managing this through the licensing system is nearly impossible, since they can only upgrade if they pay something, which means a new purchase, which means a new license key. Additionally, you are likely to have a separate SKU for this new version. Thus, your only choice is to manage it through the commerce system. Within the system, you have a few choices: 

• Use a different SKU for upgrade purchases than new purchases (SKU20 and SKU20U). Rely on your commerce system to recognize the allowed upgrade. Again, this is a limited availability SKU.
• Use the same SKU for upgrade purchases as new purchases (SKU20). Rely on your commerce system to recognize that this is an upgrade purchase, and thus provide the appropriate 50% discount.

In both of these cases, you depend on your commerce system for a lot of intelligence about returning purchasers. Once again, I have seen few, if any, commerce systems that can do this properly.

So, what is the solution to sell-the-upgrade?

1. Recognize that most of this is going to happen through the commerce system. Have a good cart of system that ties closely into your customer history database.
2. Make licensing as easy as possible, and have it trust your commerce system. Licensing may solve some of it, but major upgrades between SKUs will have to generate new license keys, so focus your energies on commerce systems.

esellerate, despite many other severe issues (not least of which is absurd pricing), does have the ability to do this decently using coupons. Their customer technical support is also excellent.

I have recently spent time with the various open-source cart solutions: magento, zen-cart, oscommerce and cubecart, as well as esellerate and a nice newcomer service, FastSpring. I will write a separate blog post on these services and carts soon. Unfortunately, none of these has the ability to do this cleanly. 

Next up: “Sell the Plan.”

For the last several months, I have been involved with a particular very small ISV, almost a micro-ISV (mISV), as it prepares for growth. One of the key elements we identified is that its pricing model – unlimited free upgrades – is not exactly conducive to good revenues and profitability. Although it seems obvious, it needs to be stated, and for several reasons.

1. Founders sometimes feel that to charge for upgrades would somehow offend existing customers. This was not at all the case with this customer. Nonetheless, many are afraid to do so. The opposite is true. Most customers not only understand that the service a vendor provides is ongoing, and requires compensation, but want to ensure the vendor will be around for a long time. Wisely, this founder had been saying from the beginning that as of now, upgrades are free, but he reserves the right to change it.
2. People equate value with price. Sure, everyone looks for a bargain, but if something seems too cheap, too good to be true, they subconsciously, and sometimes consciously, assume it to be, well, cheap and worthless. For a great reference, see Joel Spolsky’s article in the Inc magazine of July 2008.
3. Repeat customers are always lower cost to sell to than new customers, in every business.

It seems fairly simple, then, to charge for upgrades. But how to do it? We were left with two primary options:

1. Charge full price for a new customer, 40-50% off for upgrading customers at major revisions. This means buyers of 2.5 get 2.6 for free, but pay discounted price for 3.0. This is known as “sell the upgrade.”
2. Charge full price for a new customers, give them 12 months (or similar) free upgrades, whether minor or major versions. When the 12 months are up, they get no upgrades or updates. At that point, they can buy another 12 months (or similar) of free upgrades at 40-50% off the then-current retail price. This is known as “sell the plan.”

Sell the upgrade is cleaner to manage and implement, and is similar to what most large vendors do. When you buy Windows XP or Mac OS X Tiger, you get all the service packs for XP and updates for 10.4 for Tiger for free. You do, however, have to pay for Vista or Mac OS X Leopard.

Sell the plan has better revenue timing (it comes in earlier), and better cash flow. Further, it makes it much easier to sell to organizations that budget. Rather than a capital expenditure each year or two, it becomes a maintenance expense, built into the operating budget each year automatically.

For the above reasons, we went for sell the plan.