The Economics of SaaS

Software as a Service (SaaS) has a lot of intriguing aspects. The zero hardware cost, no need for systems software, lower implementation costs, vendor provided maintenance/upgrades, etc. are quite attractive. Many buyers are also enthralled at the concept of monthly software pricing. But not every SaaS vendor does the monthly pricing thing. In fact, many use pricing models quite similar to on-premise ERP vendors. Those are the multi-year deals that require a big upfront cash payment.

I used to think that all SaaS vendors should be/are offering the monthly payment option but it turns out that this isn’t the case for some very understandable reasons.

From the vendor’s perspective, cash is the fuel of any software company and SaaS vendors need a lot of it. Remember, they must acquire everything needed for successful data centers. That’s a cost on-premise vendors don’t have. Second, many SaaS vendors aren’t collecting big upfront payments. They may have customers using only a few licenses during the implementation (when a vendor’s support costs are highest and revenues the lowest). They won’t get a big up-front payment from a customer unless they price their software accordingly. They also have the usual software costs like development, sales, marketing and support to fund as well. In all, SaaS companies aren’t exactly cash-flow generating machines except for those companies with lots and lots of paying customers.

One example of that phenomenon can be found in today’s TechMarketView. They stated:

“No one said it was going to be an easy ride in the SaaS world. ‘The other’ poster-child for the delivery of software as a service, Netsuite, fell in deeper loss last year as it poured more dosh into sales and marketing – now 48% of its $193m revenues. CEO Zach Nelson poured brave scorn on rivals SAP (deserved) and Microsoft (misguided), but gave no hint as to when his business will make money.”

How acute is the cash flow situation? SaaS vendors will incentivize buyers (or just require them) to pre-pay usage on a multi-month or multi-year basis. The payments will be upfront and provide critical cash to software vendor operations. This cash will:

- prevent or reduce the need for more venture capital funding rounds. Fewer rounds mean less dilution for the founders and early shareholders. - make their books (i.e., cash balance) look stronger going into an IPO round. The hope is that this would improve the strike price of the initial offering, too.

From the customer side, these prepaid contracts may have some upsides. They could lock-in a specific, discounted pricing for a long, known period of time. But, they could also lock-in a customer in other ways, too. Plus, customers may be pre-paying for usage during the implementation period. That has always been a rub for on-premise customers and it may be one for many SaaS customers, too.

Is it right for SaaS customers to always expect month-to-month pricing? Probably not. The more complex the application, the greater the implementation effort and the need for implementation assistance suggest that customers must fairly compensate vendors for the increased support needed during this implementation timeframe. To do less is not fairly matching payments to services received. If the application is a straight-forward single application, month-to-month pricing is probably appropriate and should definitely be offered by the vendor.

If a SaaS vendor doesn’t offer month-to-month pricing is that necessarily bad? Not really. What we need to remember is that SaaS solutions are often quite advantageous from a TCO basis. Even if the cash flow dynamics change, the differences from cash flow timing will not, in most cases, change the basic TCO conclusion. Remember, with SaaS, you’re not buying hardware, systems software and other components.

SaaS customers should carefully negotiate SaaS contracts especially those requiring multi-year terms and upfront payments. Look for: - discounts for pre-payments - further pre-negotiated discounts for the use of new modules and introduction of new users - option to revert to a month-to-month option after the initial term lapses - future payment reductions due to service level shortfalls or other failures in the initial payment term

(Also: See what colleague and fellow Enterprise Irregular, Jason Busch, had to say regarding a prior post I did on Material Change of Control clauses in software deals)