Reversing the Enterprise 2.0 Pricing Model

Written by Guest Author / February 21, 2009 12:00 AM / 25 Comments

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.

Comments

Subscribe to comments for this post OR Subscribe to comments for all ReadWriteEnterprise posts

TRUE: "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."

That is the problem with classic enterprise hardware companies. They have an inflated public price when in reality the items are sold at 60 to 80% discount.

However, bandwidth and mirroring services get too expensive with volume from what I've heard, forcing startups to forgo the seemingly initial investment in favor of an in-house implementation.

Posted by: Antonio Altamirano | February 21, 2009 12:26 AM

Such posts are why I love RWW.

Posted by: George Tziralis | February 21, 2009 4:34 AM

This seems to be an argument more for trial accounts than anything else.

Mentally, I'd have a hard time saying "this costs $10/user/month right now, and it's fine, but for me to use with my all my colleagues, it's suddenly $18/user/month." Or $25, or whatever. It's much easier to just know the price is $18/user/month, but be able to try it out for free with 2-4 people, or for a limited time with a larger group.

If I can prove value at small scale, or a larger scale for a limited time, then the cost should be easily accounted for. Swapping out low pricing for higher pricing later goes against basically the entire rest of the marketplace (not just software, but pretty much everything). I'm not sure many people would flock to this 'innovative' strategy. I may be wrong, but free or limited trial accounts are more easily understood and accepted by most people.

Posted by: Michael Kimsal | February 21, 2009 5:20 AM

Additionally, this may work against organizations during a rollout. Some places I've worked at have had an issue with letting more people have certain software because the cost would increase, *even when the cost-per-seat went down* based on volume licensing. Turning this around and having cost-per-seat *increase* is really going to make it hard to justify to people who are watching the money. For every metric you can come up with to measure the value, someone will likely be able to make a counter argument, and also likely point out that your metrics are too new to be used for anything meaningful.

I think there's a reason that increasing-per-seat models haven't been seen yet. Given the enormous amount of money on the line, and the tens of thousands of brains that have addressed this problem over at least the last decade, and the powerful "increase the bottom line" push in the corporate world, I'd imagine this likely has been floated or tried in some cases already and found lacking.

But - I may be wrong. If someone could pull this off, more power to them.

If *anyone* could pull this off, justifying it by some metric of increased productivity due to network effects, wouldn't it be Microsoft? Your company is not as effective is only half the people have access to your Exchange server, so why not increase the price for more Exchange seats as the company grows?

Posted by: Michael Kimsal | February 21, 2009 5:28 AM

Great article, Julien!

I think we have exactly targeted the problem that you've raised here with our Enterprise 2.0 product - cyn.in.

I think the biggest cost to the company apart from the software itself is that of adoption of the product as well as the change in mindset that comes along with it.

We believe that CAL based (per user) pricing is detrimental to adoption. Because, Enterprise 2.0 apps get used by small teams in large enterprises and from there they percolate their way inside the entire organization. CAL based pricing hampers adoption at the initial stage.

With cyn.in, we have made the initial adoption cost zero by making it available freely for everyone to download and use. There is no limitation to users or features in the free version.

Our graph goes up as the usage increases. We charge based on usage and infrastructure requirements and have eliminated the user based (CAL) pricing from the picture completely. Companies can start with free open source edition, then move up to the nominally priced SaaS plans and finally move to the on-premise model.

I think you've hit the nail on the head with Adoption being the key ROI driver. And with cynin, we've targeted exactly this point.

I'd really appreciate your feedback on our pricing.

Posted by: Romasha Roy Choudhury | February 21, 2009 6:45 AM

I think the biggest obstacle to "Enterprise 2.0" technologies is that no one is even asking the ROI question. Too much emphasis is placed on "this feels like something we should/should not do".

Thanks for putting this topic front-and-center.

Posted by: mogrinz | February 21, 2009 6:48 AM

Excellent piece. I'm so so thrilled to see this covered on RWW!

Also, volume and transaction based pricing especially brings budgeting headaches for larger organizations. Larger organization buyers can't keep adjusting costs like a monthly phone bill. It needs to be simple enough where a fixed cost results in a estimated range of acceptable value. IMO, this creates a more solid foundation to gauge value and improves the chances of charging more per unit, as usage goes up.

One nit: I'm having trouble with the cause and effect argument - I don't believe pricing structures to be the reason "why Enterprise 2.0 is not taking off more strongly". We're not at the maturity phase in the life cycle of E2.0 where this is the primary inhibitor. Wikis aside, itâs still a land grab and vendors are cutting all sorts of deals to get the big names on their client roster and prove their solutions.

Posted by: Sameer | February 21, 2009 7:19 AM

Another thing that makes your increasing price scale difficult for Enterprise 2.0 vendors is that Enterprise 2.0 isn't just about the Fortune 500, it's about the Fortune 500,000. When SaaS vendors have cloud-hosted, self sign-up solutions (like we do with Present.ly) in addition to in-house installations we're not putting all of our eggs in the basket of huge companies. We're also providing value to huge numbers of companies with 2-20 employees. These companies would never reach the kind of "full deployment" or "half deployment" metrics for a volume inreased pricing scheme.

I think the fundamental problem is that software vendors didn't used to have the ability to target companies from 2 employees to 200,000. Everyone's still trying to figure out how to make that work.

Posted by: Michael Bleigh | February 21, 2009 7:35 AM

Based on my experience as a corporate buyer, price increasing with volume would not sell. While I agree with your assessment that entry barrier needs to be low, the new model you are suggesting makes for higher cost as you scale. Most CIO/CFO's don't like it. They generally like to seem reducing unit cost as you scale.

This model can also be an issue to product vendor as his margin will be very low initially.Here are some other alternatives that could be worked out

- Agree on certain volume commitment so that appropriate discounted pricing structure can be applied and have something like a quarterly or half-yearly license true up where by at the end of each quarter/half-year based on actual usage the customer pays for the incremental licenses. The pricing will be flat in this case as the overall discount structure will be applied up front.

- Get into subscription based pricing where the company pays an annual subscription fee based on license usage (using same true-up concept mentioned above) and provide support, patches, free upgrades to newer versions etc for the subscription. In this case vendor needs to go with attractive subscription pricing to get customers. This will also provide steady stream of revenue for vendor.

- Better still go with SaaS model where the vendor hosts the complete platform and provides a private Enterprise 2.0 implementation for the company and provides an annual subscription price with quarterly/half-yearly trueups.

Posted by: Nandu Muralidharan | February 21, 2009 8:08 AM

Julien, Great food for discussion! I think an interesting "try" from the vendor would be to discuss with the customer an 80% enterprise adoption end-game model before going out of the gate. This would present a total annual cost of x licenses tied with an agreeable ROI based on average value per user at full deployment. How to pay as the deployment goes from 0% to 80%? The vendor could first divide the end-game seats by the total price and present this fee per seat as the customer adopts over time. However, the customer knows there is an economies of scale in value as more are added and will then demand a sliding schedule where the price per seat is less early and more later, mapping to the average value per user curve. Bingo!

Here’s my flaw: For this to work, the vendor may need to switch advertising from price per seat to ROI per seat. This approach may work if the first sales discussion is with the decision maker who has the power for true enterprise deployment, but we all know this is hard to get with larger organizations. Instead vendors enter at a department level. Since there is limited or no visibility to an enterprise-scale adoption model, the vendor is left with a pricing plan based on the immediate sale with that group’s deployment. So, we’re stuck again with volume discounting demands as more departments come on board.

Posted by: Paul Dandurand | February 21, 2009 9:23 AM

very nice blog Thanks You Admin

Posted by: Muhabbet | February 21, 2009 9:43 AM

Sorry, total rubbish this is.
The guy has no clue.

Posted by: mukzz | February 21, 2009 11:44 AM

Hit the nail on the head, the solutions are very specific to the vendor in question. I agree both with Julien and Nandu. Barrier of entry needs to be low and increasing cost per unit is a bit unsettling.

I enjoyed reading the article as it argues the case for our pricing model quite nicely. Because utility value is easier to calculate in our model, we hope to make that case convincingly. I can't divulge the specifics of our model yet, we're going into public beta come summer. Like twitter/friendfeed we're a many-to-many but aiming for a more meaningful exchange. An ideal tool for selective alerts, crowd sourcing and information gathering. Without the infomania/overload...

So a pricing model might look something like this:

1 Modest or no sign up fee.
2 Premium on hosting cost increases with value calculated.
If signup fee, count it as credits, start billing when
they run out out.
(Value calculated according to agreed upon metric)
3 One time fee when agreed upon milestone is reached. No
per s

Posted by: Elias | February 21, 2009 11:49 AM

Great post, but I think it is a terrible idea. Per user pricing that needs steep discounting is a bad idea, but not as bad an idea as charging customers more for being a better customer.

I wholeheartedly agree with the statement made earlier by another commenter: "per user pricing is detrimental to adoption". Charging per user is a bad idea, and the deep discounts companies feel the need to provide for large accounts is evidence of that.

Take Twitter for example... there are millions of users, but how many really make significant use of it? A company will want to make a service available to everyone, but because users consume resources so differently, guessing at a cost per user is an exercise in futility.

EditMe's pricing is based on EditMe's cost of delivery. That is, customers pay based on the data center resources they consume. Though there is a volume discount, it ends at a certain point guaranteeing a minimum profit margin on the service.

This allows customers to scale their use of the product at their own pace, and only pay for what they use. In my view, this is a significant competitive advantage as most of my competitors have steep per-user fees built in. In the era of cloud computing and adoption-oriented applications, it doesn't make sense to price SaaS any other way.

Posted by: Matt Wiseley | February 21, 2009 12:12 PM

You can't charge more for the same thing. But you can easily develop features that large users need and charge for those.

People rail against "free" but when the marginal cost to deliver is zero, everything trends toward "free". So you might as well acknowledge that and structure your business accordingly.

Posted by: pwb | February 22, 2009 2:45 PM

I suppose that the reverse pricing model makes complete sense in the paying end-user point-of-view. However, I believe that one of the reasons for this model to be so rarely applied lies in the fact that the cost of goods and services needed by the supplier of ther service to keep the business running (hardware, software and peopleware) follows a traditional model, following the "economy of scale." In essence, the "reverse" pricing model makes complete sense, but some sort of mathematical simulation would be needed in order to estimate the initial prices as well as the step increases which, as pointed out by the author, should be aligned to previously defined and agreed upon metrics.

Posted by: Ricardo Souza | February 22, 2009 6:48 PM

We (http://www.LEADSExplorer.com/en/le/t/signup_price.html) have a flat fee per user.
The volume discount is related to the number of leads generated, qualified and accepted from your website.

Posted by: Engago Team | February 23, 2009 12:45 AM

Wishful thinking IMO.

I can understand that from a physical point of view, the potential value of a network can grow to as much as O(n^2) so some folks might be inclined to think of indexing pricing to this curve but the logic is flawed:

it only takes *one* detractor (ie. someone who sells an equivalent service at better price... that's what competition is for, no?) to make this theoretical model fall down.... unless we are talking about cartels and the like here ;-)

Posted by: Jean-Lou Dupont | February 23, 2009 7:49 AM

From first hand experience in trying to come up with a pricing model for E2.0 products, I'd agree with a lot of Julien's points. We had a real hard time selling a non-traditional licensing model both internally and to potential customers. Let's not even get into the complexities of enforcing some of these licensing schemes.

In the end we wound up going with a structure that had a fixed up front cost, had NO per-user cost, and had a variable licensing cost that attempted to capture the value side of the equation. The latter was of course the hardest one and would vary by product. In our case, we were selling an IT Service Management product the variable piece was not on the number of IT elements (traditional model) but was instead based on the level of interaction by the unlimited users on the IT elements. The idea was that the customer would see ever increasing value by having more and more users operating on the IT elements, so they only payed as adoption increased and they actually started to realize

Posted by: Abbas Haider Ali | February 23, 2009 12:17 PM

There isn't a silver, gold or bronze bullet for price.

I think the only universal solution to pricing conundrum is to provide so much value that it makes pricing irrelevant. Your value should be readily apparent; can't rely on sophisticated metrics to prove the point. We've found that a simple ROI formula is difficult to argue with:

ROI = (Gains - Costs)/Costs

Here's what we came up with for Relenta. This model can be easily adjusted to just about any situation:

http://blog.relenta.com/roi-calculator

Posted by: Dmitri Eroshenko, Relenta | February 24, 2009 8:53 AM

Flexibility is key for software providers in this troubled economy. For example, eTouch SamePage just announced it will offer multi-tenancy for on-premise enterprise customers, especially beneficial for large enterprises, umbrella organizations and academic institutions.
Historically, multi-tenancy is a deployment model used only by SaaS vendors and products. With this additional delivery mechanism, SamePage will offer its customers increased deployment versatility.

Posted by: Abbe | February 25, 2009 1:43 PM

I'd argue there is a fundamental problem with per-user licensing in E2.0 applications, regardless of whether a volume discount or volume premium is applied.

Too many enterprises I've seen limit access to tools in order to save on per-user licenses: if each user has to "justify" his/her participation in a collaboration space against some per-user cost, use is discouraged - sometimes quite explicitly. (This would only get worse, of course, if the vendor were applying more expense per user as the enterprise participation percentage went up).

It may be beneficial to the vendor to align cost and value, but it won't help the client to have increasing cost discourage the most valuable behavior. What you describe as, from the customer point of view, "a divergence between cost paid and value obtained" is actually increased ROI! (Less cost per unit of value).

Eliminate per-user pricing altogether (say, by building your enterprise collaboration platform on open source) and you are free to encourage use, allowing emergent (sometimes even unexpected) uses which lead to real innovation.

Of course one can argue that there's still a "per-user" or "per-use" cost underneath it all in terms of hardware scaling, support, and the like - but the more you can break away from the cost-per-use equation the better your return on investment.

The worst case scenario is per-seat licensing of applications with high sign-up rates (or billing per user in the enterprise, not per actual usage) and low usage rates.

Making enterprise 2.0 applications easier to use - reaching as much as possible consumer-grade ease of use - and ensuring that there is marginal additional cost as new users come on board - is a far better strategy for encouraging use, which ultimately means a better strategy for achieving ROI.

Posted by: John | February 28, 2009 11:22 AM

Good thinking here... The reality (or shall I say a better way) to match the value you provide a large enterprise with the value they gain from deploying the product more fully is to create add-on applications or services. It is every product manager's dream to have a platform that is well entrenched in an enterprise that can be leveraged for additional value creation (for both sides).

The increasing price for enterprise adoption idea sounds great from the software provider perspective, but anathema to the software consumer. Therefore, different ways of leveraging the product or at least the relationship is called for. It's more of a customer-partnering scenario I'm advocating here than an adversarial one. The customer can choose whether or not to implement or try the new product offerings only if it provides them real value... and your cost of deployment and cost of sales as the provider should be significantly lower. Just a thought.

-jeff brantley

Posted by: Jeff Brantley | March 30, 2009 9:47 AM

I'm really very useful to follow a long-time see this as a blog here Thank you for your valuable information.

Posted by: peynir | October 31, 2009 3:44 PM