Rental and subscription models vs. perpetual licenses

[Mark Dalgarno]

Rental / subscription models should be attractive to customers who want a lower cost of entry, lower risk and the ability to spread payment when purchasing a software tool.

Given this added customer benefit how would you normally price rental / subscription models vs. perpetual licenses?

What are people's experiences of using different types of payment model?

[Elian Chrebor]

Hi Mark, I use the both models for myLittleAdmin and myLittleBackup. Perpetual licenses are the most used. But the count of rental licenses is currently increasing. Currently our monthly fee is equal to the "normal" license price, divided by 12. The subscriber can upgrade to the last version for free, including for major upgrades.

[Matt Richards]

We are trying to push the subscription model, so our monthly subscription price is purchase / 36. The only reason we offer the purchase model is that some customers can not connect their systems to the Internet for security reasons. We are just getting started, so we don't have enough data to tell you which is better.

[Mark Dalgarno]

Matt Richards said:

We are trying to push the subscription model, so our monthly subscription price is purchase / 36. The only reason we offer the purchase model is that some customers can not connect their systems to the Internet for security reasons. We are just getting started, so we don't have enough data to tell you which is better.

Matt,

How did you arrive at the figure of purchase / 36?

Mark

[Matt Richards]

We estimated that the useful life of the type of software we were trying to replace was about 3 years. This software typically sells for $9,000, which requires a lot of management approval. Renting it for $250/month should be much easier to approve but is still a worthwhile price for us.

[Mark Dalgarno]

Matt Richards said:

We estimated that the useful life of the type of software we were trying to replace was about 3 years. This software typically sells for $9,000, which requires a lot of management approval. Renting it for $250/month should be much easier to approve but is still a worthwhile price for us.

Thanks for the additional info.

Mark

[Gustavo Orrillo]

We will use a subscription model. People will pay a monthly subscription price. What we are figuring out is how to segment our customer base in order to have different price points for each customer segment. If we get this right we will be able to offer the software for free to some customer segments and charge a premium to those customers willing to pay for it.

Hope this helps,

Gustavo

[David Locke]

In installed software, the subscription model drives releases. You are practically saying that you will have a major upgrade every year. So the customer buys a subscription thinking they will get an upgrade. And, guess what? You absolutely must deliver an upgrade within the subscription period. If that software is broken out of the box, you end up extending the subscription.

I've come across two opposing theories. One says mask price. Make buying unconscious or habit. The other says, use price to drive consumption. There are other ways to drive consumption, but paying a bill is strongly coorelated with use. If they don't use it, they won't upgrade, so you bill them to make them use it, so they will upgrade or resubscribe.

Billing can also be used to moderated the loads on your capacity. You can bill them zero dollars for a bundled service, just so they know the value of what they are using. When you anticipate a load beyond capacity, because you've got historical data, you can ensure that you do not bill during the loaded period. To get more use in a low load period, bill.

[Brian Vogelsang]

I tend to gravitate towards the subscription model as well. There are many bad things about perpetual, not the least of which is it encourages salespeople to over discount at quarter end to make their numbers. This also leads to revenue peaks and valleys, with little revenue predictability. Perpetual is also highly sensitive to economic climate, as companies budgets contract so does their willingness to part with their cash. Subscription is easier to stomach from a cash flow standpoint.

Have a look at Daniel Shefer's pricing article here: http://www.shefer.net/Articles/Pricing_for_Software_Product_Manager...

Also, http://www.softwarepricing.com has some great articles on pricing. I read everything I come across that Jim Geisman posts/writes. He is one of the few software pricing gurus I've come across.

[Jim Geisman]

We've been working a lot on (and thinking about) SaaS pricing for several years and Scott's comments (among others) cause me to post this. I hope these thoughts will be useful.

1. SaaS is a lot of things rolled into one making for confusion when we talk about SaaS. The low entry fee, accessibility, scalability, continuous upgrades, architecture and remote hosting tend to get mushed together which often causes confusion when we talk about "SaaS". So when we talk about SaaS what are we talking about?

2. Subscriptions, maintenance, per-user, etc. are examples of different payment structures and can be applied to any software delivery/licensing model. Scott's comment about subscription vs. maintenance payment structure is exactly correct. The only real difference between the two is one is structured with an up-front payment that is many times (4-6 X) the ongoing payment stream. The other is a level payment stream from the git go...

3. SaaS isn't for everyone as Scott's post indicates. One of the issues that seems to get missed is fundamental: What market segment is SaaS aimed at? This is not an SMB vs. enterprise as evidenced by the broad (but not universal) acceptance of the SaaS delivery model across differently sized companies. This is an issue of how well matched are all the offering elements of SaaS (see 1. above) to a customer need. For example, many SMBs are cashflow or IT-cost sensitive. This is much different from the business manager in an enterprise who signs up for a SaaS-delivered app because that person cares about the payment structure (to expense it), low entry cost (to hide it from IT) and speed of implementation.

4. SaaS price comparisons are often incorrect leading to lower-than-needed price levels. Many times folks set prices by comparing apples (SaaS-software-plus-hosting) to bananas (on-prem software-only). You need to compare apples to apples... Compare the software-only part of a SaaS offering to on-prem software-only (or load hosting costs onto the on-prem software so it is like SaaS). When you divide a perpetual software price by, say, 36 to get a SaaS price, you are either undercharging for infrastructure or the software only piece.

5. SaaS pricing metrics don't necessarily align with how value is delivered. Per-user isn't a "bad" metric (as per-CPU can be) if the value customers get rises with the number of users. SF.com's per-user metric makes sense since value is often pegged to usage by sales people. We're looking at event registration apps for workshops we will be doing and their metric is per-registrant\ which makes sense to me.

I hope these thoughts will clarify discussions -- at least here -- about SaaS and pricing.

[Stewart]

Hi Mark,

Pricing is one of the most difficult, discussed and debated topics in Product Management.

Here is a good article from the people at On Product Management. You can search their site for pricing to get other useful advice.

Stewart
http://twitter.com/StewartRogers