An idea on Software as a Service pricing: no premium features, premium resources.

Short:

Base Software as a Service (SaaS) pricing on resources the customer will outgrow. These resources should define the price elasticity from the customer.

Long:

When I was running this morning next to a corn field, it reminded me of a game we played as kids. With a plastic tractor we went to gather corn from the field and sell it in the neighborhood. Some of the corn was whiter than others and instead of throwing them away (everybody wants good looking yellow corn, right?) we started to sell the white corn as “premium” corn. We told the people whom we sold the corn to, that the white corn (€ 1.5 / a piece) was better to make popcorn from and that the yellow corn (€ 1 / a piece) was best to cook or just eat like that.

 

To our surprise, people really wanted to buy corn from us. In the end we had our hands full of coins. They should have know that we just went to the field across the corner to get the corn & that the white corn really wasn’t much different from the yellow corn. Still, people also bought the white corn.

This got me thinking why somebody would buy the white corn which was obviously not that much different than the yellow corn, it was just uglier. Because the corn field was just around the corner, and we where a bunch of little kids, my assumption is that the main the most important factor playing a role is the price elasticity of the people who bought the corn. People who where willing to pay more to a bunch of cute looking kids with a plastic tractor, paid more, encouraged by a bit of perceived value. (“premium” corn). This got me thinking about price setting with SaaS.

Software as a Service pricing and the price elasticity of the customer

Most SaaS companies create different plans, with different prices and different features. The rational behind this might be to target different groups of customers with different needs. (1) And to optimize revenue, some people want to pay less and you want to earn money from every type of customer. In essence facilitate to customers with a different price elasticity. (2)

The first argument, doesn’t make that much sense for most SaaS companies in my opinion. If you look for example at New Relic’s pricing they have a pro and standard package in which the standard package has basic features and the pro package has a lot of nice, more detailed analytics. In this case the customers who order the standard and pro package both have the same needs, they want to monitor their servers. The only different groups of customers there are, are defined by their price elasticity. Some customers are only willing to pay $24/month (standard package) and some are willing to pay $149 / month (pro package) and you obviously want to make profit from both groups of customers.

If this is true for most SaaS companies, then why does the majority of them base their pricing on premium features. Limiting basic users and giving the real deal only to premium users. You are essentially saying to your customers “If you can only pay that much then we will only solve a part of your problem” It would make much more sense tobase pricing on resources that grow or shrink with the price elasticity of the customer. A great example of this is Assistly. They base their pricing on the number of agents which makes much more sense than limiting features. Companies that can pay more, are bigger and have more support agents. Everybody gets the whole awesome experience, nobody is limited. An interesting article on the Assistly’s pricing can be found on Xconomy.

There is even a risk that can occur with feature based pricing. If you offer a basic plan which has the minimum number of features to solve the problem your company wants to solve for the customer.  Then customers with a higher price elasticity, who can pay more (but of course don’t want to) can take this basic plan instead of the premium plan and you are essentially losing money. In New Relic’s case, a big money making company can take the $24 /month/server plan, but if they didn’t have a choice, they wouldn’t have a problem with paying $149/month/server.  In this case it might be worth to look if it would make sense to base pricing on eg. the number of requests or visitors of a website. Customers with a lot of visitors on their website can probably pay more than customers who only have a few 100 visitors a month. The former would be paying $149/month/server and the latter $24/month/server. In Assistly’s case, a big company would have no other choice than to pay more because they would have more support agents.

But of course, this is just a thought, grown out of thin air after a morning run. Do you think it makes sense to create plans by limiting features, if you can charge for resources that grow with the price elasticity of the customer? Given you are mostly solving the same problem for all your customers.