Why is the Enterprise 2.0 market not taking off more strongly? The reason has to do partly with ill-conceived pricing structures: volume-discount (VD) schemes. Fix them, and you fix one of the obstacles preventing the market from expanding rapidly. And by fixing them is meant reversing them, in particular by using volume-increasing schemes.
Pricing Tied to Volume
Enterprise social computing offerings — such as social networks or the numerous Twitter-for-the-enterprise applications that currently abound — generally don’t have complex pricing structures. They are volume-discount based: that is, the more accounts customers buy, and the more employees who use them, the larger the discount vendors give them, and the lower their average price per user will be. Some vendors advertise flat pricing schemes, but when a customer is big enough, a volume-discount deal inevitably creeps in.
Value and Cost Out of Balance
Volume-discount pricing structures are simple, tried, and true. So, why aren’t they efficient? The reason is because of where returns on investment (ROIs) are located. Enterprise social computing offerings provide increasing marginal productivity as they scale, at both the individual and organizational level. The more that employees use a service, the higher the margin gained by their company in productivity, and the more the company extracts value from the product. A corporate customer that has 10% of its employees using a Twitter-like product won’t extract as much value as one that has 50% of its employees using it.
Increasing returns to scale can come in different ways: positive network effect, viral economies of scale, distributed economies of scale, etc. All enterprise services offer some of these dynamics (or at least the simple network effect), and the better designed the product, the bigger these economies of scale. (Download this PowerPoint presentation of Umair Haque‘s work for more on the subject.)
If customers extract more value (higher returns) per user as the number of users increases, yet pay an ever-decreasing price per user (which is VD pricing), value and price have diverged. And this divergence is shaping the Enterprise 2.0 market. Let’s look at the consequences, and keep in mind that the issue is symmetrical for vendors and clients: vendors see a divergence between price charged and value provided, and clients see a divergence between cost paid and value obtained.
The following graph is a simplification of the value and cost curves:
Note that the N axis is shown in relative, not absolute, increments: the marginal value derived from an employee using the application is a function of the percentage of employees already using the application, not of an absolute number.
Let’s look at the cost-to-value picture if 10% of a corporate customer’s employees use the application. Because the company hasn’t bought many accounts (only enough for 10% of its total workforce), the discount is not big. Unfortunately, the value it gets from this 10% for a Twitter-like application is minimal. So the cost-value ratio does not make sense for the customer at this level. However, once a critical mass of employees starts using the application, the value per user is quite high; but the price, being heavily discounted, is low.
Adoption Harder than It Needs to Be
The pain point is right in the middle of these two extremes. A corporate customer evaluates software deployment with the end goal in mind. For enterprise social web services, that objective is usually to deploy it to 100% of employees and get the percentage of active users as high as possible. The business case hinges on this end goal.
Achieving the goal is possible in one of two ways. The first is to start small, bring on early adopters, demonstrate the application’s value, and move gradually towards global deployment. In this case, you buy accounts as you need them, getting modest but increasingly higher discounts as your volume increases. The second way is to purchase the anticipated total number of accounts needed for global deployment, negotiating a fat discount right away.
In the first scenario, customers have trouble making a case for the application, because the cost per user is very high, and the value obtained is not sufficient to offset those costs. The project will likely not scale due to an insufficient cost-to-benefit ratio. In the second scenario, the customer incurs the total cost right at the start, although deployment would likely be phased, as would the value obtained. This phased approach means that the cost-to-benefit ratio isn’t rosy either, and unless the head team can deploy aggressively and successfully, the project is at risk of being shut down. Big-bang deployment is an option, but few organizations have the culture to pursue this successfully, and so it usually fails. Pilot projects might help but do not solve the cost-to-benefit problem.
Reversing the Scheme: Increase Price with Scale
Volume-discount pricing schemes are profoundly shaping the Enterprise 2.0 market and make getting new customers and scaling much harder than they need to be. One solution is to reverse the pricing scheme: instead of charging less per user as more accounts are purchased, vendors should charge more as more accounts are purchased. In the graph above, the cost curve would be flipped and aligned with the value curve.
Using a volume-increasing scheme would accelerate customer acquisitions, new pilot projects, and the number of deployments that could potentially scale. Vendors should provide very low entry points, charge for set-up and deployment at cost, and let the users themselves prove the value of their services. Vendors would not incur additional costs because sales would be quick and deployment would be sold at cost (which for SaaS is minimal). The pricing scale for an application would be agreed on from the start, and if the application proves to have value, it will scale, along with the average price per user and the vendor’s total revenue.
This approach would also help signal the value of an application: the vendor that is confident that an application will spread once deployed within an organization projects a different image than the one that tries to lock in all revenue up front, no matter whether deployment is successful or not. Vendors would go from having a few customers make up their total revenue stream (but with those customers obtaining varying degrees of value) to a more long-tail customer base: lots of clients in various stages of deployment, and thus many more revenue streams at various levels. The vendor’s total revenue would no doubt increase: the revenue generated per customer would stay about the same, but you would drastically increase your customer base, and those various revenue streams would add up.
Execution Not Easy, But Potential Is Big
Of course, as with any pricing strategy, executing this one is not straightforward. For example, what metrics are meaningful for a Twitter-like application? Can an application be considered to be fully deployed if 50% of an organization’s employees are active users? What about 20%? Or 70%? In this particular case, vendors and customers should probably use the quarterly increase in active users as a metric. There are others obstacles, too, which I go into in more depth here. Alternative approaches are possible, of course, and we can expect innovative pricing structures to be increasingly used as the differentiator in the enterprise social web space. Executing won’t be easy, but using innovative metrics and fences to make price and value converge as closely as possible may be the single biggest opportunity for both vendors and customers alike.
Not many volume-increasing pricing structures seem to be in use today. Any ideas why not? Let us know in the comments.
Julien le Nestour is passionate about the macro principles shaping the environment we act in: edge economics, deep macro trends, geopolitical influences. You can reach Julien on his blog at MacroPrinciples.com.
