| In many industries the pricing models are as old as the | | | | offering that distinguishes itself by giving the chance of |
| industries itself, and the rules of the game were set a | | | | developing an application on their platform mostly by |
| long time go and are well known by everyone. This is | | | | visual "drag and drop" operations. They are well |
| not the case of SaaS. Being a young software | | | | funded and should be considered as a strong |
| delivery model, the key factors of a good pricing | | | | competitor to companies like Intuit with quickbase or |
| strategy are not that clear. | | | | Salesforce's force platform. |
| It seems, just by taking a look at the pricing models of | | | | So, let's analyze their pricing model without talking |
| many SaaS offerings, that traditional licensing model of | | | | about money, we are interested in the model: |
| the on-premise software is not the best idea for | | | | - They charge basicaly on three different concepts: |
| OnDemand software. | | | | users, records and file storage. |
| Also, the traditional services (like consulting) model "I | | | | - They offer a free account with: 1 user, 2000 rows |
| charge for the time you are using my resources | | | | and 100MB of space. |
| (professionals) and their value (junior, senior, etc...)" | | | | - From there you have two options to scale: the |
| doesn't seem to be the best way to approach the | | | | workgroup bundles (with discounts) or the |
| SaaS pricing problem (probably fits better when talking | | | | 'pay-as-you-go' more flexible depending on your needs. |
| about cloud computing). We are not talking about | | | | - There are four different workgroup bundles: plus, pro, |
| traditional services, we are talking about pricing a | | | | premium, business, each one with a fixed price for a |
| subscription business. | | | | certain number of users/records/space. Of course a |
| In SaaS, the change from offering "products" to | | | | bundle is cheaper than having the same amount of |
| "services", from "acquire" to "subscribe" implies the | | | | usage via 'pay-as-you-go'. |
| need of defining the best way for charging for the | | | | - The 'pay-as-you-go' model basically charges you for |
| solution offered. | | | | each user/10000 rows/1 GB you use. |
| So, any SaaS provider faces the problem of fixing the | | | | You can take a deeper look at Coghead's pricing |
| right price to its solution / services. There are many | | | | model here. |
| alternatives and factors that should be considered | | | | Let's talk now about how does this pricing model |
| when dealing with this. | | | | relates to the "model ideas" and goals we talked about: |
| Most of the proposals out there use some (or all) of | | | | - They, obviously have a periodic (monthly) payment. |
| this ideas: | | | | Something that makes perfect sense for a PaaS |
| - Pay periodically: This means charging the customers | | | | offering. |
| on a regular basis (usually monthly). | | | | - They charge both for the users and for the |
| - Pay for each user: Very widely used, from | | | | resources used. This is very often used in PaaS |
| Salesforce to that new SaaS start-up that two college | | | | offering, that can be very easily overused. Charging |
| students just started. | | | | for number of rows or space is a way for Coghead |
| - Pay for the resources: This usually means computing | | | | to make sure nobody abuses the platform. |
| resources: CPU/hour, GB, Bandwith, etc... it is used very | | | | - They have some feature pricing also: Limited users |
| often in IaaS or PaaS. | | | | and acces point for applications that wish to be public. |
| - Pay for the features: So the customers pays just for | | | | - They have both 'pay-as-you-go' and a 'package' |
| the features in our solution they really need. Maybe | | | | alternatives. |
| new functionality or maybe simple using 'more' of the | | | | So, they seem to use all of the ideas we talk about, |
| tool (for example more applications in a PaaS offering). | | | | this, of course brings a problem of complexity but |
| Each of this 'ideas' have its own pros and cons. For | | | | gives the users a lot of flexibility. |
| example, 'paying for each user' has the problem of | | | | And now the final question, does this pricing models |
| generating fear in the customer about adopting the | | | | achieve the goals we wrote about in this post? |
| solutions widely, or 'pay for the resources' has the | | | | - It is certainly atractive for a new customer/developer |
| problem of the customers not knowing what they will | | | | to start knowing/using the platform via the free basic |
| pay the next month... | | | | account. |
| In one word, usually SaaS pricing models are more | | | | - About making the costs for the customer predictable: |
| flexible than in the traditional license-based on-premise | | | | They offer this through their bundled-workgroup |
| software, and mean less risk and a wiser spending. | | | | choices. You know what you pay for. This is not true |
| This can, though, lead to a problem of complexity that | | | | in the 'pay-as-you-go' option, which is also more |
| should be taken care of. | | | | expensive, so their pricing model tends to bring |
| First, let's take a look about something one should | | | | customers to the 'workgroup'choices. |
| always keep in mind, the goals that any pricing | | | | - Increase the customer share: This true for the |
| strategy for SaaS should pursue in order to sustain a | | | | 'pay-as-you-go' , but not so true for the 'workgroup' |
| profitable business model. | | | | option, where de customer could hesitate before |
| - Make it interesting for a new customer to start using | | | | buying the next and more expensive bundle. |
| the product. Having a free version, a trial version, or | | | | - Don't make the pricing too complex: We really think |
| simply a 'pay-as-you-go' strategy starting low, usually | | | | Coghead fails at this one, their pricing model is quite |
| solves this. | | | | complex for the average user. We didn't even talked |
| - Make the costs for the customer predictable. | | | | here about their partner offerings or the concepts |
| Everyone likes to know what to expect when talking | | | | behing the different kind of users. We asume that, for |
| about paying... some SaaS offering have this problem | | | | a PaaS offering whose customers are both business |
| (specially those that have cost based pricing models). | | | | and technically skilled, complexity is not such a big |
| One should let the customer know, and decide what | | | | problem. |
| they want to spend. Though we should keep in mind | | | | - Avoid customer abuse: This is quite covered there is |
| the next goal. | | | | no easy way that a customer could make a very |
| - Try to increase the customer share once the | | | | extensive use of the platform without paying for it. |
| customer is using the tool. This can be achieved in | | | | Maybe they could have a problem with bandwidth, |
| many different ways, most of them related to the | | | | something they don't charge for (they actually have |
| 'pay-as-you-go' model (features, users, resources, | | | | limits at least for public/web users of an app). |
| etc...). The customer should feel that spending more | | | | We consider that the usual behaviour of a customer |
| really means extracting more value from the tool. | | | | would be to: |
| - Don't make the pricing model too complex. This is a | | | | 1. Try the free account. |
| problem very often found in SaaS offerings, and that | | | | 2. Go for the first bundle. |
| can make the adoption of the tool by the market | | | | 3. Then the second, third, and finally the 'business' |
| slower and harder. Let's keep in mind that many | | | | option. |
| companies are not used to SaaS yet. | | | | 4. If the customer has further needs they wouldn't |
| - Make sure that the customer does not abuse in the | | | | have any option but going for the quite unpredictable |
| use of the solution. This can happen quite easily in | | | | 'pay-as-you-go' model. |
| solutions where lots of data are involved, like those | | | | So, in the end, increasing the complexity of their pricing |
| that use video, business intelligence tools, etc... the | | | | model by using most of the usuall ideas in SaaS pricing, |
| provider should be protected against this. | | | | (they made some changes recently) Coghead has |
| So, how would this goals and the main ideas explained | | | | been able to cover most of the goals. We think they |
| in the first post be applied when defining a SaaS | | | | have an strong pricing model (complexity is not such a |
| pricing strategy? | | | | big trouble for this kind of PaaS tool) that supporting |
| Let's take a look at a real world example: coghead | | | | their excelent flex-based tool, should help them in |
| Coghead is a very good, and quite veteran PaaS | | | | becoming a big player in the PaaS area. |