Sunday, November 16, 2008

About SaaS Pricing Models

In many industries the pricing models are as old as the industries itself, and the rules of the game were set a long time go and are well known by everyone. This is not the case of SaaS. Being a young software delivery model, the key factors of a good pricing strategy are not that clear.
It seems, just by taking a look at the pricing models of many SaaS offerings, that traditional licensing model of the on-premise software is not the best idea for OnDemand software.

Also, the traditional services (like consulting) model "I charge for the time you are using my resources (professionals) and their value (junior, senior, etc...)" doesn't seem to be the best way to approach the SaaS pricing problem (probably fits better when talking about cloud computing). We are not talking about traditional services, we are talking about pricing a subscription business.
In SaaS, the change from offering "products" to "services", from "acquire" to "subscribe" implies the need of defining the best way for charging for the solution offered.
So, any SaaS provider faces the problem of fixing the right price to its solution / services. There are many alternatives and factors that should be considered when dealing with this.

Most of the proposals out there use some (or all) of this ideas:
- Pay periodically: This means charging the customers on a regular basis (usually monthly).
- Pay for each user: Very widely used, from Salesforce to that new SaaS start-up that two college students just started.
- Pay for the resources: This usually means computing resources: CPU/hour, GB, Bandwith, etc... it is used very often in IaaS or PaaS.
- Pay for the features: So the customers pays just for the features in our solution they really need. Maybe new functionality or maybe simple using 'more' of the tool (for example more applications in a PaaS offering).
Each of this 'ideas' have its own pros and cons. For example, 'paying for each user' has the problem of generating fear in the customer about adopting the solutions widely, or 'pay for the resources' has the problem of the customers not knowing what they will pay the next month...
In one word, usually SaaS pricing models are more flexible than in the traditional license-based on-premise software, and mean less risk and a wiser spending. This can, though, lead to a problem of complexity that should be taken care of.
First, let's take a look about something one should always keep in mind, the goals that any pricing strategy for SaaS should pursue in order to sustain a profitable business model.
- Make it interesting for a new customer to start using the product. Having a free version, a trial version, or simply a 'pay-as-you-go' strategy starting low, usually solves this.
- Make the costs for the customer predictable. Everyone likes to know what to expect when talking about paying... some SaaS offering have this problem (specially those that have cost based pricing models). One should let the customer know, and decide what they want to spend. Though we should keep in mind the next goal.
- Try to increase the customer share once the customer is using the tool. This can be achieved in many different ways, most of them related to the 'pay-as-you-go' model (features, users, resources, etc...). The customer should feel that spending more really means extracting more value from the tool.
- Don't make the pricing model too complex. This is a problem very often found in SaaS offerings, and that can make the adoption of the tool by the market slower and harder. Let's keep in mind that many companies are not used to SaaS yet.
- Make sure that the customer does not abuse in the use of the solution. This can happen quite easily in solutions where lots of data are involved, like those that use video, business intelligence tools, etc... the provider should be protected against this.

So, how would this goals and the main ideas explained in the first post be applied when defining a SaaS pricing strategy?
Let's take a look at a real world example: coghead

Coghead is a very good, and quite veteran PaaS offering that distinguishes itself by giving the chance of developing an application on their platform mostly by visual "drag and drop" operations. They are well funded and should be considered as a strong competitor to companies like Intuit with quickbase or Salesforce's force platform.

So, let's analyze their pricing model without talking about money, we are interested in the model:
- They charge basicaly on three different concepts: users, records and file storage.
- They offer a free account with: 1 user, 2000 rows and 100MB of space.
- From there you have two options to scale: the workgroup bundles (with discounts) or the 'pay-as-you-go' more flexible depending on your needs.
- There are four different workgroup bundles: plus, pro, premium, business, each one with a fixed price for a certain number of users/records/space. Of course a bundle is cheaper than having the same amount of usage via 'pay-as-you-go'.
- The 'pay-as-you-go' model basically charges you for each user/10000 rows/1 GB you use.
You can take a deeper look at Coghead's pricing model here.
Let's talk now about how does this pricing model relates to the "model ideas" and goals we talked about:
- They, obviously have a periodic (monthly) payment. Something that makes perfect sense for a PaaS offering.
- They charge both for the users and for the resources used. This is very often used in PaaS offering, that can be very easily overused. Charging for number of rows or space is a way for Coghead to make sure nobody abuses the platform.
- They have some feature pricing also: Limited users and acces point for applications that wish to be public.
- They have both 'pay-as-you-go' and a 'package' alternatives.
So, they seem to use all of the ideas we talk about, this, of course brings a problem of complexity but gives the users a lot of flexibility.
And now the final question, does this pricing models achieve the goals we wrote about in this post?
- It is certainly atractive for a new customer/developer to start knowing/using the platform via the free basic account.
- About making the costs for the customer predictable: They offer this through their bundled-workgroup choices. You know what you pay for. This is not true in the 'pay-as-you-go' option, which is also more expensive, so their pricing model tends to bring customers to the 'workgroup'choices.
- Increase the customer share: This true for the 'pay-as-you-go' , but not so true for the 'workgroup' option, where de customer could hesitate before buying the next and more expensive bundle.
- Don't make the pricing too complex: We really think Coghead fails at this one, their pricing model is quite complex for the average user. We didn't even talked here about their partner offerings or the concepts behing the different kind of users. We asume that, for a PaaS offering whose customers are both business and technically skilled, complexity is not such a big problem.
- Avoid customer abuse: This is quite covered there is no easy way that a customer could make a very extensive use of the platform without paying for it. Maybe they could have a problem with bandwidth, something they don't charge for (they actually have limits at least for public/web users of an app).

We consider that the usual behaviour of a customer would be to:
1. Try the free account.
2. Go for the first bundle.
3. Then the second, third, and finally the 'business' option.
4. If the customer has further needs they wouldn't have any option but going for the quite unpredictable 'pay-as-you-go' model.
So, in the end, increasing the complexity of their pricing model by using most of the usuall ideas in SaaS pricing, (they made some changes recently) Coghead has been able to cover most of the goals. We think they have an strong pricing model (complexity is not such a big trouble for this kind of PaaS tool) that supporting their excelent flex-based tool, should help them in becoming a big player in the PaaS area.

TodoOndemand is a blog about SaaS, Cloud computing and OnDemand software. We focus on how the new SaaS software delivery models are changing the way we think about enterprise software.

No comments: