The holy Grail of Pay-as-you-go
The latest addition to the pricing models in the SaaS market is the pay-as-you-go-model. One of the first to offer this on a large scale – and make tons of money with it – was Amazon with its cloud solution Amazon Web Services (AWS). Basically, you’d pay only for what you use in terms of CPU-Cycles, storage and traffic. Unlike many other services which only give you limited resources, this model allows you to easily grow and scale your business. And even though, especially on large scale, Amazon is a very expensive cloud infrastructure, it is still the most widely used and implemented one out there. Leaving analysts puzzled.
This confusion is rooted in a common misunderstanding of the pay-as-you-go model: despite popular believe, the selling point actually isn’t the resource itself. What people are effectively buying is flexibility and convenience. Flexibility because most of those services offer a very, very low starting plan: a basic offer that is free in most cases. You can spin up a free instance on AWS within half an hour. For many things, this is enough to get started. Only once a project gains traction and generates traffic, one needs to upgrade to bigger machines and pay for the extra resources used.
At the same time the service is flexible enough to handle peaks for you. Peaks are good for your business, as they usually mean more business. The last thing you want is for your website to shutdown because the package you bought was too small to handle peak traffic.
Next to that, this model is convenient. In a pay-as-you-go-model you barely need to plan for future growth. The payment grows with the number of customers you have. And although you end up paying a premium once you reach a certain threshold -as price is always directly linked to the amount of customers you have- it is easy to pass costs on to your own customer.
Applied to Plans
Thinking back of the plans we talked about before, how does that integrate in a pay-as-you-go-model? Amazon has been pioneering here as well, with a feature they call "reserved instance hours". It boils down to a classic and old principle: the discount if you buy a lot and pay upfront.
Basically instead of being charged for every minute you use, you say at the beginning of a period that you’ll pay for at least 2 full CPU months and Amazon gives you that for a discount. If you don’t use them, you pay too much but if you do, you don’t pay as much as for the normal pay-as-you-go. If you need more resources than that, you often pay a discounted price on those extra resources, too. Not as good as the offer for the reserved resource but still cheaper than if you hadn’t reserved at all.
So, if there is any way that you can create billable timed resources through your service, this is the model you want to go for. Going back to the radio streaming example from before: one stream hour could be such a resource – every hour that one persons listens to a stream. Now on the lowest plan, you’d have to pay nothing, get 1.000 StreamHours included but every stream hour after is at 10 ¢ - this would account for a little more than one full-time-listener but is enough to try the service and see if it works for you. As the previously mentioned shoutcast-streaming feature is excluded in this plan, this isn’t a long-term option for you. But 10 ¢ per stream per person per hour also doesn’t sound too much to pay.
The second plan now costs, let’s say 39 €, includes 5.000 StreamingHours and every hour on top costs another 8 ¢. The next higher plan includes 15.000 at 79 € at 6 ¢ the extra hour and the one for 99 € contains 50.000 StreamingHours with any hour after being as cheap as 2 ¢. This is only a calculation example and doesn’t necessarily work in the real world but it illustrates the idea. Because the concept of plans still works here, with the special feature that you can even offer a plan of 0€ you make money with. Might even make more money than with the other plans because of the higher per-hour-price.
The reason why you still want the other plans though, should be obvious. Aside making business predictions easier, you can also reward your customers on their success. Instead of making it the experience of "well, you had so many streams, we had to cut your services", you can make it the story of "Congratulations on your peak of listeners last week. We just wanted to let you know, for successful Radio Streams like yours our plan B has a pricing system, with which you’ve saved 100 € this month alone already.". You become part of their success story, a supporter and helper on the way. Not the technology that failed on them during the best stream of their lifetime.
Through this model suddenly you are also much more interested in the numbers of each and every client and love to serve them to optimize those, give them insights and dashboards, even live stats to make them do their job better. And once you understood this mechanic behind the curtains, it becomes obvious why Amazon is so successful. It isn’t because of their resources, it is because of the business model implemented through their pricing scheme.