PAY AS YOU GO PRICING - Is it really a win for the AWS Cloud customer in the long term?

Recently, I had the opportunity to interact with Amazon Web Services (AWS) team. As we all know Amazon is a company that obsesses itself with customer service. And as part of that service, Amazon philosophy is to get its pricing right - the pricing that would generate the best possible costs for its customers. According to them that pricing framework is found in the pay as you go or pay per use model. In their publicly available Pricing Overview paper, they contend that: “While the number and types of services offered by AWS has increased dramatically, our philosophy on pricing has not changed. You pay as you go, pay for what you use, pay less as you use more, and pay even less when you reserve capacity. Projecting costs for a use case, such as web application hosting, can be challenging, because a solution typically uses multiple features across multiple AWS products, which in turn means there are more factors and purchase options to consider.” (Source and copyright: http://media.amazonwebservices.com/AWS_Pricing_Overview.pdf)

While it is wonderful that AWS has a framework that is focused on saving as much money as possible for its customers, the framework does pose some challenges for a customer. In my work, I have always been about the customer and I always put myself in a customer’s shoes first when designing pricing frameworks. What makes it easy for a company does not make it easy for a customer. AWS has used its considerable analytical capacity to design costing and pricing calculators for the customers to arrive at their monthly operating costs based on the customers’ projection of their usage across the numerous services that Amazon offers. If you take a peek at the online pricing calculator that AWS has on its website, the complexity of all is laid bare. Here are some advantages and disadvantages of a pay as you go pricing. Firstly, disadvantages:

• Considering that AWS largely works with start-ups and emerging companies who cannot afford their own private cloud, to expect such companies to have analytical and forecasting capabilities simply adds to the start-up companies’ resource costs. This, then, defeats the purpose of cost savings that a pay per use model was originally designed for. 
• Another argument is that the AWS is like a utility, like an electricity provider. But that argument is valid only when your end customer is an individual and there is only one single component - electricity to price. Even in an electric utility, if you look at how utilities trade with other utilities, it is traded in bulk wholesale bundled rates. In other words, even utilities do not use a pay per use model when trading with businesses. 
• The third disadvantage arises from the inherent uncertainties associated with forecasting that leads to sticker shock. Sophisticated models in the financial world have gotten forecasts wrong. Despite AWS’ sophisticated calculators, forecast is just that -  a forecast and from a business’ customer’s point of view, a proposition that subjects them to large volatility swings. Again, turning to the financial world, people hedge their exposure to volatility by purchasing put and call options. In general, individuals or small businesses or even large businesses -  all do not like pricing volatilities. And the pay as you go model just does that. Imagine a start-up companies’ surprise when it faces a $10 bill in Month 1 and then faces a $1MM bill in month 3 due to a traffic surge, and then the bill again comes down to $10 in month 4 and so on. Small companies simply do not have cash sitting on their balance sheets to manage such volatilities.
• The fourth disadvantage is around compensating a sales person for selling these services. Since most sales representatives are paid on revenues, a volatility in customer revenues leads to volatile swings in commission payouts. While holding a diversified account portfolio might help reduce that volatility, it ends up forcing account managers to start putting efforts into building such diversified portfolio rather than going all out to sell such plans to the first customer that wants them. 
• The fifth disadvantage is  around revenue growth maintainability. When rates drop, a pay per use pricing scheme affects not just new customers but all the customers signed up so far. It would be well nigh impossible to offer a reduced per GB rate or per instance hour rate only to new customers and not whittle down the rates of the existing customers.  This leads to the unintended consequence of constantly reducing your base revenue growth which means your business’ year over year revenue growth would be negative to neutral unless enough new customers are signed up that offsets a dip in base revenues. But new customer acquisition costs are quite high these days - Amazon or not - and the overall profitability could take a nose dive. 
• The sixth disadvantage is around bundling solutions with other partners. Most service providers today have flat rate, pooled or stacked pricing service plans, which offer very predictable monthly rates for accessing certain bundled capacities. If the customer has to use more data it is as simple as switching them to a higher fixed rate service plan. In my experience, after experimenting with most types of pricing frameworks, I find that predictable pricing is what customers prefer - big or small; and most consider that pay per use pricing is an operating cost inefficient solution. Further, most small customers prefer a single bill for related solutions, and that means that when AWS partners with mobility providers or Business Intelligence Analytics providers to sell bundled solutions, it would not be able to offer a pay per use pricing but has to devise a much simpler, and predictable flat rate pricing to fit in with other providers. Even AWS, with all its might and glory, has to sell solutions to businesses along with its partners as proven by large companies such as Avaya which sells 90% through its partner channels.
  
  
  While pay per use has its limitations pointed above, it also has its advantages to a customer. Here are some:
  • Firstly, if the service is used in sessions instead of through an entire service period, then sessions based billing can be done under pay per use framework. But even here, as you may have noticed with Go Go In-flight wireless service, the sessions are always quoted at flat rate pricing bundles. 
  • Pay per use helps companies when they go through idleness in certain periods and then capacities kick up in other periods. But in the real world, this hardly ever is the case. When the service is used for niche, time-sensitive applications or a one-time use or a try before you buy sale, then the pay as you go model might be appropriate. Even here, a spike in usage can happen inside of a day for some companies, and make their trial costs very high, unless the trial service is offered free of charge of course. 
  • Another advantage is when selling your services to companies that are used to the pay as you go model such as advertising companies with pay per click models or credit card processing companies with transaction payments. They are already used to transaction based payments and may prefer services based on pay per use models. 
  
  
  In conclusion, while pay per use pricing framework has its uses in specific business situations and industry verticals, it is not a model that finds favor with a wide population of business users, from small businesses to enterprise, and across a spectrum of industry verticals, from stealth mode start-ups to well established, flat growth, dividend paying public companies.