In a “man bites dog” tech story on Monday April 29th, Forbes.com featured a post by its regular contributor, Gene Marks, who reported a counter-intuitive trend. All of his clients who recently compared costs of server upgrades versus going to the cloud had decided to go with server upgrades.

Gene could barely contain his glee: “None of them chose the cloud. Why? Because all six of these small business owners and managers came to the same conclusion: it was just too expensive. Sorry media. Sorry tech world. But this is the truth. This is what’s happening in the world of established companies.”

The real problem with SaaS costs

We could all get together and vote to excommunicate Gene for “profession of unbelief” and other crimes against cloud but, as satisfying as that might be, we’d be missing out on an opportunity to understand a necessary transition that cloud services have barely begun to consider.

At the root of the problem that drove Gene’s clients to pay for server upgrades instead of adopting more cloud services is the prevailing SaaS price model: Not Amazon Web Services’ Simple Price Calculator for PaaS hosting costs but, rather, the price per seat per month that has come to define the SaaS business model.

This is not the first time that utilities have undergone a price model change as they came to pervasive dominance. If we look at early days of the electrical power industry, you can see model transitions as well. Early residential customers had to pay to get their houses wired which, eventually, stopped making sense. Similarly, with SaaS offerings, the early model has been very attractive but may also be getting to a phase that requires tweaking in certain use cases.

In the beginning of the cloud revolution, we’d show up to a pitch cloud versus software license and it went like this: You can pay Siebel/Oracle/SAP/Accenture millions to license and install something that will take years to get right or you can pay a SaaS provider $100 per person per month “all-in” and be running in a month.

The “per seat” model served the early SaaS industry well

First, it was familiar enough (at some level it was just a rehash of what was learned from looking at ARPU/mo in mobile carriers).  And second, in any activity that scaled by network effect (but was not labor intensive) the model seemed intuitively fair – is making each sales rep and the entire sales force more effective worth $100/person/mo?  Clearly yes.

However, we glossed over two big issues on the way to victory:  SaaS solutions that targeted specific functions within a company are increasingly expanding to whole companies. Where it seemed OK to pay $100 per person per month for the sales department, paying that for every single person in a company can make the math less appetizing.

In addition, it would be amusing to try to sell a standard value per seat model or a per-employee model to Indian Railways (over 1 million employees) or to a major manufacturing concern with tens of thousands around the globe.

Some use cases that defy per person per month SaaS pricing

Another parallel for model changes can be found in electronic adverts: they started with impression costs (CPM), moved to click costs (CPC) and, more and more, are headed to results costs (CPA).

What is useful in the advertising case is that, as technology advanced and it became possible to put a value on outcomes rather than inputs, customers started wanting to go that way and good suppliers had nothing to fear from looking at results. They knew they were beating the competition anyway.

This is not to say that a wholesale change in the “per person per month model” is needed. In many cases, the cost to serve is indeed related to the number of users served. One can fairly easily derive values for the computational load imposed for a quantum of seats.

However, as the cloud sweeps into more and more areas of industry, some of those clearly aren’t cut for per-seat pricing. Take compute intensive work like geophysical modeling, image rendering, protein folding etc. They might require only a few “seats” but would be quite unsuitable for traditional pricing. Some might point out with good reasons that these are somewhat exotic and, hence, bad examples.

To that end here are simpler, every day examples such as Human Resources, Financials and Manufacturing control. Let’s start with HR. Perhaps every employee needs access but not every day and, certainly, not at $100 per person per month. Many fewer people in a company need logins to Accounts Receivable, Accounts Payable and General Ledger applications. For sure, only a couple of senior level planners need access to run Manufacturing Resources Planning for a global enterprise.

Nonetheless, the value delivered to a company from any of these functions is extraordinary and it would be, on the one hand, silly to sell something extraordinarily compute-intensive like manufacturing control at $100 per seat per month but, on the other hand, even sillier to try to charge for every employee on the manufacturing floor who may benefit from such a system but is not really operating it.

Actual example and disclosure

I picked the manufacturing control case because I’m an angel investor in Rootstock Software and know a little about the disconnect between the value they deliver and traditional ways of “keeping score” and applying SaaS pricing methods.

A company like Rootstock Software, along with competitors like Plex and Epicor, solve a problem for manufacturers whose value far exceeds the number of “seats” needed to operate their software. Rootstock, with which I am more familiar, is a truly modern SaaS offering and runs on Salesforce.com’s platform with elegant integrations with Financial Force and other ERP components.

Without direct knowledge of all the other apps on Salesforce.com’s app exchange, I cannot be sure but, as a betting man, I’d wager that Rootstock, with its over 300 custom objects, is significantly more complex than many other apps on the AppExchange which can and do scale by the seat and sell by the seat.

Moreover, the value delivered scales not only by the number of people interacting with it, but also and, perhaps, far more by the number of factories, warehouses and supply chain partners controlled with it. This could not very well be captured in any sensible per person per month model.

What is to be done?

As in every transaction in business, I would suggest tying the compensation to the value delivered. A company that is currently spending in excess of $300,000 annually on IT Support, ERP software license maintenance fees and servers will gladly pay an annual subscription of only half that to run a cloud service that delivers the same value with added flexibility and fewer headaches.

And then, on top of the annual subscription for the core value, it would make sense AT THAT POINT to add on top some reasonable per person per month fee in case a company wanted to give access to manufacturing modules such as Production Engineering and Parts Management, Inventory Control, Production Control, Purchase Order Management and Sales Order Management. It would not be $100 per person per month but something yielding a reasonable margin for that additional value delivered.

I realize that this might sound like going back to old discredited models but only to a point. If cloud providers insist on taking too much out of clients with rigid per person per month models, they’d be behaving just like the software dinosaurs that they so cleverly disrupted. Flexibility now will likely prevent disruption later. What’s more, it will open up vast markets now resisting the move to the cloud as Gene Marks so eloquently described in his recent article.