Back in March, SaaS CRM vendor Rightnow announced a new pricing strategy that centered around the notion of eliminating "Shelfware-as-a-Service." This was a great reminder that "Pricing is Marketing" - and that marketing worked! Rightnow put the idea out that there that customers are paying for "seats" or "users" on SaaS products that they aren't using and made the industry take notice. Brilliant strategy and it absolutely got the industry talking. For some reason, that "chatter" picked up in recently with analysts and pundits bringing this up outside of the discussion of Rightnow and in the greater context of SaaS as a whole.
Shelfware comes from the way that people bought packaged, on-premise software and didn't use it - it literally sat on the shelf and was never opened. Shelfware in SaaS comes from the idea that companies are paying for "users" or "seats" that they don't need and are now realizing that. The problem doesn't seem to be only with the notion of paying for something you don't use but seems to be with the apparent conflict with the original "promise" of SaaS as "pay as you go" software. It seems that Rightnow was smart in their anti-Shelfware campaign as they saw an opportunity and ran with it. But for SaaS vendors in general, this is not something to be taken lightly especially as FUD against SaaS, including the "Shelfware Perception," continues to propagate.
The fact is, since SaaS is so unique, it is surprising that "shelfware" would even exist in this world. It is potentially excusable in legacy software where the vendor makes the sale and the customer gets a CD or DVD with the application and is left on their own to actually install and use the product. Unless they pay for on-boarding and setup, the vendor has no idea if they will actually use it. And even then, unless they have some type of ongoing maintenance plan, the vendor will have no idea if the customer is using the product.
Even with a maintenance plan, the vendor won't have constant knowledge as to the the usage patterns of the product by the customer. In SaaS, this excuse goes away. If you are a SaaS or Web App vendor, you must monitor your customers' usage patterns and be proactive with the information gleaned from that process. Just as you nurture leads or sign-ups to convert them to customers, you need to nurture your customers to ensure they are actively using and growing with the system.
But I need to give a couple of reminders. First, remember that a great deal of the value derived from SaaS happens outside of direct use of the product. Think of the continuous improvement to the software itself, constant vigilance by the vendor to ensure business rules are up to date (tax laws, industry requirements, etc.), infrastructure upgrades, support systems, backups, etc. These are elements that the end-customer would have had to support in the past so it is clear that even if they aren't using all of the "users" they are paying for, they are clearly getting a tremendous value simply by being your customer.
Second, SaaS is not a Pricing Model! To be very clear, SaaS does not mean "per user, per month" billing. You have to understand that. SaaS is an overall business architecture and your pricing must reflect the relationship between you and your target market and the value they feel they will derive, and how they will derive that value, from your product. All external factors, including what other SaaS vendors are doing, is irrelevant. This means that you must ensure customer-facing pricing is aligned with value perception by those customers. "What's in it for them?" is the mantra that should resonate in your head all the time.
If you understand all that, it should be clear that it might not always make sense to include users, seats, etc. as a key metric in your pricing if that is not an actionable and valuable metric to the customer. The IT groups might think in terms of "users" but in other areas of the business perhaps there are better things to focus on. Transactions, value-adding features (keeping in mind how those features help the end-customer, of course), connections to other vendors, etc. You should seek to base your pricing on something that your customers will find continued value in - continued being the key word. That continuation of value perception needs to consider the notion of a growth in usage complexity, an increase in requirements, etc.
Where many vendors get into trouble is in versioning. Many SaaS vendors do "bundling" where they create different bundles or tiers based on some metrics - features, users, storage, etc. - and charge a different price for each. This is what you see on almost every SaaS company pricing page that offers price transparency. Where the SaaS vendors run into the "Shelfware Perception" issue with versioning is often in the selection of the bundle differentatiors. Far too often the bundle differentiators are not value-added, but are instead commodity or low-value items - at least in the minds of the customer (which is all that matters at this point). Is a user - the key idea in this post - a low-value metric? It can be and it is up to the vendor to understand if that is the case.
Consider this situation... What if you make your customer choose a more expensive bundle with 100 users, when all they have are 10 users, just so they can get "Feature X?" They will curse you every time you bill them and possibly start looking for an alternative solution with the correct value proposition since they are paying for users they don't use. In their minds they are paying for users they don't need even though they are clearly benefiting from, and would pay the same amount for - maybe more - Feature X. It is all about value perception from the customer standpoint and if you took the time to clearly understand user behavior and market dynamics, you would not have the "Shelfware Perception" problem in the first place.
But you thought SaaS = Per User, Per Month pricing - that clearly isn't the case. So what do you do? You contact us to get started immediately on a new pricing strategy for your SaaS or Web App, including a plan to move from your current one.
Author: Lincoln Murphy (@lincolnmurphy on Twitter)