I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)

« Super-fast flat file parsing in C# and Java with a perfect hash function | Main | How we ended up writing our own programming language »

A few lessons about pricing B2B apps

My own SaaS company has always been struggling with its own pricing. For a company now selling its own pricing optimization technology for commerce, this was a bit ironic. Well, pricing of software is unfortunately very unlike pricing goods in store, and the experience we acquired working with our retail clients improving their own prices provided little insights about the pricing of Lokad.

Since the creation of the company, Lokad has been offering a metered pricing, charging according to the amount of forecasts consumed. However, in practice for the last two years, we signed only a handfew contracts where the pay-as-you-go pricing had been actually preserved. In practice, the usage consumption as observed during the trial period was used as the starting point of the negotiation; and then the negotiation invariably converged toward a flat monthly fee.

Starting from today, we have extensively revised the pricing of Lokad toward a very simple list of packages only differentiated by the maximal size for the client companies.

For SaaS companies selling to businesses, the (almost) ubiquitous pricing pattern consist of charging per user; that's the approach of Salesforce, Google Apps, Office 365, Zoho and many more. However, sometimes, charging per user doesn't make sense, because the number of users can be made arbitrarily low, and does not reflect at all the usage of the service. All cloud computing platforms fall into this category.

Metered pricing only works with Über-geek clients

The cloud computing example is misleading because it gives the false impression that metered pricing is just fine. Metered pricing works for cloud computing platforms because their clients are very technical and can digest pricing logics 100x more complex than logics acceptable by "non-tech" businesses.

At Lokad, we have observed many times that the fear of doing a mistake and increasing the invoice tenfold was generally considered as a deal-breaker. Most companies don't even nearly trust as much their employees as software companies do trust their software developers. A metered pricing put an implicit high level of trust on the employees operating the metered service.

Flat monthly / quarterly / yearly fees are the way to go

Through dozens of negotiations with clients, some large, some small, and across many countries, we have always converged toward periodic fees to be paid every month, quarter or year. Sometimes, we did add an additional setup fee to reflect some extra-effort to be delivered by Lokad to setup the solution, but in 7 years of business, we had only a handfew contracts more complex than a flat setup fee followed by a flat period fee.

The lesson here is that anything more complex than setup fee + periodic fee is very prone to accidental complexity providing little or no business value for the software company and its client.

Don't cripple your software by restricting access to features

The "freemium" vision consists of offering a free version with limited features, and restricting the access to the more advance features to paying clients. Again, if you consider a software where it's natural to charge per user this approach might work; however, when the software is not user-driven, not granting access to all features just drags down your small clients - who have mostly the same needs than your bigger clients.

We learned that crippling our own apps was just bad. At the end of most negotiations with clients, we were nearly always ending up granting access to all features - like the highest paying plan - for most companies. Naturally, the price point was adjusted accordingly, but nevertheless, we observed many times that crippling the software was just a lose-lose approach.

It's fine to trust your clients by default

For years, at Lokad, we had relied on the implicit assumption that whatever metric were going to be used to define the boundaries between the subscription plans, this metric had to be tracked by the software itself. However, by narrowing our vision to the sole metrics that our software could track, we had eliminated the one metric which was truly making sense: charge according to the company turnover.

Our new plans are differentiated based on turnover, and yet, we have not automated way to measure the turnover. However, is it really a problem? I don't think so. Over the years, we have very (very) few companies trying to game our terms. Moreover my observations indicates that the larger the company, the less likely they are to even consider the possibility of cheating.

The logical conclusion is then to grant access to everything by default, and then to gently remind companies of your pricing terms when the opportunity arise. B2B isn't B2C, for the vast majority of B2B software, even if you don't put any protection in place, the service isn't going to be swarmed by corporate freeloaders.

If it does, well that's a rich man's problem.