I recently asked Olivier Amprimo to examine my argument around pricing for Enterprise Social Computing offerings. He kindly did it with an excellent post, so this is my reply, a bit in the spirit of old-fashioned correspondence. Olivier gave some background info in his post, and let’s just add that I have rarely witnessed such deep thinking—his blog is full of excellent material as well. Obviously, there is much more in Olivier’s analysis, than the points I reply on here. (You may want to read the post Olivier scrutinize, then his before this one)

Let’s start with a basic typology. There are at least 4 different types of Enterprise Social Computing offerings, each enabling a different set of capabilities for the organization:

1. A core foundational platform for enterprise social networking: think of it as Facebook or LinkedIn redux inside an organization. Employees have rich profiles, explicit connections, an activity stream tied to their network and an open architecture allowing to pull activities from the existing business systems. Newsgator is an excellent example.
2. Specific but corporate-wide tools available to all employees: here we have the Twitter-likes, Youtube-likes, etc.
3. Persistent, large-community, but not corporate-wide social tools: wikis, blogs, and so on used by specific and persistent communities. Traditional communities of practice exemplify this type of needs.
4. Perishable social tools used by focused teams, usually project or business teams: these are the wikis used within teams to prepare the business documents for example, a TeamSpace if using SharePoint, etc.

Onto Olivier’s post:

http://venividiluxi.com/en/?p=96“>

Fundamentally, Julien makes the assumption that Enterprise Social Computing offering is all about product offering.[...]

An Enterprise Social Computing pilot is not about testing an off the shelf solution, it is about building a contextual platform, with mashups and tweaks. Yes, convergence happens in the social computing software. Products are embarking more and more features. Lines are getting unclear between blogs, wikis, social networks and … But there is no off-the-shelf social stack. The most expensive is therefore not the software; it is its implementation. It is not the product; it is the know-how and the sensemaking.

When testing offerings falling in Types 2, 3 or 4, I would agree. But the license fees for a good platform, even for a pilot period are important and rival the implementation costs. While there is no off-the-shelf social stack, organizations need to start with the best possible platform (best is highly contextualized to each organization). Often times, the fees for this kind of platform, with a regular volume-discount pricing, are taking up a good proportion of the budget. Even if just equal to implementation costs, license costs are material in launch decisions.

http://venividiluxi.com/en/?p=96“>

As a result, the pilot phase is actually the most expensive phase. It is where one injects know-how and meaning. Post pilot costs are just deployment costs and, sometimes, additional customization.

My point exactly. As Olivier says, pilots are already incredibly expensive in terms of know-how. If you pile high license fees on top of it, as you do when using volume-discount pricing, then the cost of the pilot explodes along with the risks, and the potential ROI of a full deployment sinks. Hence my arguing for very low pricing for a pilot, essentially cost-offsetting, before increasing the pricing as usage increases.

http://venividiluxi.com/en/?p=96“>Julien makes the assumption of a standard and enterprise-wide deployment, upfront. This works well with traditional (non-social/individual) client applications (such as office) or with Enterprise-wide process applications (such as an ERP or a CRM). The problem is that there are hardly any standard and enterprise wide deployments of social computing, upfront. Social computing tools are not addressing the same issues as traditional IT ones. The deployment is progressive as social computing tools address contextual and previously implicit interactions around explicit, usually enterprise-wide processes.

We disagree on this point, and here’s why: even though any deployment will be phased, the business case is built with the sought-after end in mine: a global deployment. Pilots are for tasting the water. Generally cheap in terms of funds, always expensive in terms of resources. Clients don’t test technology stacks without being assured they will be able to deploy if they want to. Hence, they negotiate and lock pricing in before they start the pilot. If they don’t, the price will unfortunately have doubled when they want to pursue ;-)

http://venividiluxi.com/en/?p=96“>That’s why they have a network effect as Julien rightly noted, but that is also why the logic of applying the network approach to pricing is difficult.

1.    One approach is the game theory that Jean-Lou Dupont uses on RWW: “it only takes *one* detractor (i.e. someone who sells an equivalent service at better price… that’s what competition is for, no?) to make this theoretical model fall down”.

Somehow I fail to see how the incentives work that way. Volume-increasing pricing:

• is not changing the total cost (for the client) or total revenue (for the vendor). It simply changes how it’s varying over time. The Total Cost of Ownership when fully deployed is the same.
• makes initial pricing per user very low and even free when the reasoning is applied 100%. How a competitor or free-rider can emerge in this context?

http://venividiluxi.com/en/?p=96“>

As a result, if you have to play with curves, you might want to play with the Long Tail. Because what social computing caters is the long tail behind the firewall.
Read further a previous post of mine.

Slide 12 of Julien’s enclosed scribd-ed KeyNote presentation, he states that “it is important for the client to make it available to all its employees: which groups of employees will recognize its value first is unknown, and you may not target the correct group if you do a target deployment”.
Julien works in an environment that is very specific, yet common. He is entrenched in IT (that is used to think “product’) and at a corporate level (that is far from operations, which happens to be very true in his industry). The combination seems to let him thinks about standard products that are easily deployable top down. One size fits all. Experience shows it tends to be time consuming, financially costly, operationally disturbing and employee frightening.

Back to my opening typology: for a corporate-wide enterprise social networking foundational platform, 1 platform is needed, not several living together. For specific but corporate tools, one standard tool is also needed. If organizations want to share videos internally, they are looking for one Youtube-like tool, not many which will compete for a critical mass in the knowledge pool built. For type 3, persistent tools, standardizing the platforms also ease the burden on the user by avoiding using different wiki tools when switching wikis for example. Not to mention on IT, I know :-) Only for Type 4 social tools can this be envisioned.

But the ROI needs to be taken into account, and yes, there are two parts: returns and investments. Two different scenarios can be envisioned for deploying wikis used in teams for example:

1. Let users choose the wiki application best suited for their needs, and let they deploy and manage them on an ad-hoc basis.
2. Recognize the need for on-demand and fully customizable wikis, but enforce a standard tool to create them, like Atlassian’s Confluence.

In case 1, you offer full control to the end-users to choose the tool they want, but this would inevitably result in a costly mess to maintain. In case 2, 95% of the control is given back, but the tool is standard. The ROI will of course differ widely in the two cases. Standardizing always brings cost-savings, and can more and more be done without impacting the returns on the applications.

http://venividiluxi.com/en/?p=96“>

In fact, it is a question of perspective (sensemaking) and methodology. As in charge of innovation, Julien is in a position to go for pilots, which means that he is in a position to search for and interact with the “correct group” to build a successful (or not) use case. That’s empiricism. This would help him get a sense of the impact the pilot might have at a larger scale, as well as the difficulties of pre-requisites for a successful implementation (with enterprise-wide in mind on the term).

This is easy to do when you’re looking at building capabilities enabled by tools falling in type 3 and 4, and this is what most companies do. How do you do it when you are looking to deploy an enterprise social networking platform? A twitter-clone? Within large organizations, whether or not you’re in IT, you can’t possibly know all the different groups operating with their own culture, goals, processes, incentive structures, etc. Targeting is useful but not optimal at all. If you target, you may hit some “correct groups”, but then again you may not. Even if you do it exactly the right way, facts of life within large organizations can turn a correct group into an incorrect one at a high velocity.

The best strategy seems to be to communicate and publicize the capabilities, then let the groups who would benefit from the technology enablers use them.

http://venividiluxi.com/en/?p=96“>

A particularly interesting approach in this conversation is Atlassian’s pricing policy and business model. Atlassian has a traditional pricing structure in the software industry, to a certain point.
Atlassian plays on:

• Lowering the entrance barrier.

The price is below the usual amount of money that requires the workflow of informing a lot of people to get one signature, as well as many opportunities for loads of “why” and a “no” and is capped. People are thus empowered to test the product, customize it to cater local and contextual needs. By doing so they potentially build a usecase and start the grassroot movement below radars. The client becomes the reseller. But the pricing is made in a way that if the first year is affordable, the next year ones are more expensive that traditional software: 50% of the initial license (vs 10-20%), not to mention the adjustment of users. So in the end, on a 3 year basis, the cost of the software is not cheaper than traditional software, but the product is up and running and inhouse (so that it is too late to say NO!)

• Volume of portfolio.

Lowering the entrance barrier is the best way to have a large client base. And because the balance between first and next year is 2 to 1, the turnover of Atlassian grow substantially mechanically.

• Nice and robust products.

They are self-explanatory thanks to a meaningful interface, that embarks contextual help and an exhaustive help documentation one click away. As such, they require nor cost nor effort in the support and maintenance phase (n+1 and beyond) and ensure that Atlassian milks the cow, with style

Yes, Atlassian’s pricing is smart. But the cow they don’t milk. One condition such pricing works well is that the unlimited user license is still not highly priced. If it was, then we would not see the same acceptance of the products. Yet, it fails to capture the producer surplus it could when used in large organizations with per user pricing, albeit not the tired old way.

http://venividiluxi.com/en/?p=96“>

Julien these were my 2 cents, happy to discuss this further.

I certainly hope so, although you might want to avoid this correspondence style :-) Not sure how this works for readers…

Source: Enterprise Social Computing Pricing: insightful, but you hardly see the woods for the trees

Innovation is obvious in the Enterprise Social Computing field. Features are invented and combined in novel ways; ever changing suites of products are built and marketed. Innovation is very real, even if not of the scale signaled by the hype around it. It’s not in pricing however. Even worse: pricing is often structured contrary to the value offered and hinders both pilot and full deployments.

Look at the metrics, fences, and whole pricing strategies of your favorite vendors. Strategy may even be too strong of a word, as they often are a combination of classic scale metrics (per user per month), setup and deployment fees that are pure cost pricing, bland and rigid Volume-Discount price structure.

Vendors should exploit the principles of value pricing on a much wider and deeper scale than they currently attempt to. Value pricing is obviously nothing new, yet it seems strangely ignored by both vendors and their clients. Practiced in the emerging IT field, it will have deep impacts for both vendors and clients and will spur a much more productive collaboration between the two.

Value and cost are not matching

Every product bearing what is usually dubbed a “social component” has significant network effect and peer production dynamics. The more employees actively use the application, the more they — and so their organization — extract value out of its use. Marginal benefit per user, and hence total value, thus increases with the number of active users. Yet, most pricing structure are degressive, Volume-Discount schemes: price per user decreases with the number of users. Price and value varies in opposite ways:

What happens here is a total reversal of what should be aligned: the more employees use the system, the more value you get out of it per user, the less you pay. And the less users you have, the less value you get, the more you pay. This explains both the refusal of lots of companies to pilot new technologies, and the difficulty to transition from pilots to full deployment: if you can’t do it in one shot, the economics will be much less in your favor to do it in a phased way.

Aligning value and cost decreases risks for large clients

When companies are looking to pilot innovative technologies, they consider both the pilot itself and the full deployment — of which the pilot is just the first step — if it ever happens. But they also evaluate half-successes: what happens if they need to deploy only across half their planned user base? Companies will do a pilot, agreeing beforehand to a price structure that sees the price decrease as the number of users increases. ROI calculations will more often than not be based on optimistic expectations towards the adoption rate, overestimating the price discount. So what happens if you planned on deploying the piloted technology across 10,000 users and find out you have to start with 1,000 and demonstrate the value over time? Well, your price per user will likely shot up significantly.

This means that, with classic Volume-Discount pricing structures, companies will usually have the choice between a full deployment or no deployment. Deploying on a smaller scale would decrease the ROI significantly as it lowers the value and increases the costs. Unfortunately, what this means is that disruptive innovations, where the value is by definition not obvious for stakeholders, and where it usually emerges from early adopters experience, are very difficult to successfully transition from pilots to production. They would need a phased deployment, starting small and scaling up progressively, that is not profitable with a Volume-Discount price scale.

By pricing their software closer to the actual value delivered and perceived by their clients, vendors will get pilot deployments accepted much more easily, and most importantly will see more of them succeed.

Replace Volume-Discount pricing by Volume-Increasing pricing

Pricing is both a significant obstacle and opportunity for savvy vendors and clients. Developing a pricing strategy that better aligns value with price will help both to provide and benefit from innovative IT applications.

So how should vendors approach a newly defined pricing strategy? We’ll take the social media example: price it with activity metrics coupled with increasing, not degressive, scale metrics. In practice, you would charge a price per user that actually increases with the number of active users inside the client’s organization. Looks wrong? Adopt your client’s point of view: if your deployment is very successful, they will pay an expensive price but derive lots of value from it. Additionally, if the deployment needs to be phased to convince stakeholders of the value potential, they will also pay a matching price that will enable them to scale its use. Reversing the price structure lowers significantly the risk for the client, increasing the chances of a pilot happening.

A positive externality of such a pricing strategy, at its peak for Enterprise Social Computing offerings, is the credibility and confidence about their product projected by vendors. Nearly all are using arguments about how easy it is to engage employees, how they will want to use it, collaborate with each other, etc. So don’t limit yourself to the market pitch, embed this in your pricing and demonstrate your confidence.

Redefining pricing habits is not easy but the rewards can be great

Vendors can do this by working with their clients and defining targets for user activity or user adoption. This will be easier when your product is replacing a legacy application, and more difficult when it is truly innovative.

A good case study are the applications providing microblogging (or microsharing, in a word Twitter-like like Yammer (which just announced a on-premise version) or Present.ly) features for the enterprise. The more users will use it, the more value the client organization will get out of it. In most organizations however, the value of a Twitter-like for corporate use will not be obvious, and will slowly build up with time, as it spreads internally.

Yet, pricing is desperately of a Volume-Discount type, making an after-pilot deployment with a small group of early-adopters look very expensive per user (large companies will compare it to the price per user for fully deployed applications like email or IM). Smart vendors will reverse the price structure, offer organizations the opportunity to try out the new technology, experience its value over time after a pilot, and scale up accordingly. They have to forgo immediate but short-term benefits, in order to get a chance to demonstrate their value added and reap the benefits as the client scales up its use.

Defining the correct strategy is not easy and will require time and efforts. Each side has of course opposite incentives for the definition of the ranges. Compounded with this, setting the target in terms of active users for a successful deployment in terms of user adoption will not be easy for truly innovative technologies. But there are many ways to implement a good pricing strategy. Defining ranges of user number will likely be difficult in many case: what should be a target of active users, for Twitter-like applications, to define a successful deployment? This can be mitigated by setting targets on user adoption rates. Stating that the user base should grow by at least 10% from quarter to quarter or 3% from month to month would align clients and vendors very well. Incorporating in the contract that, say, a successful deployment is 30% of all employees, would enable to define a reward fee to the vendor if deployment reaches 50% of active users. This will again match the value to the price and most companies shouldn’t have a problem with this.

The possibilities are truly infinite and have to be explored on a case by case basis, taking into account the complete characteristics of a product. Let me dismiss right away the most common counter argument for using Volume-Increasing price structures instead of Volume-Degressive: vendors will lose a lot of value to small companies that will never require to scale up. This is true, if no fences are in place. But it’s very easy to define at least 2 structures based on the total size of the organization. For organizations with less than 1,000 employees, you apply Volume-Discount pricing. For more, Volume-Increasing. That may not be right for your product, but the point here is that you need to segment your market, and then use this segmentation to apply different structures.

In any case, pricing a product based on the number of active users instead of seats, is the least a vendor can do, especially if the software is delivered as a service.

Deeply segmenting your total market then using innovative metrics and fences to match price and value as closely as possible is the single biggest opportunity available for both vendors and clients alike. Let’s use it.

You can also use the following slide deck to go further along this path:

How to price social enterprises applications? Value and utility pricing through increasing price structures

UPDATE: The post is now up here on MP. A shorter version is now also up at ReadWriteWeb.

How to price social enterprises applications? Value and utility pricing through increasing price structures

[Small digression: it’s very hard (at least to me) to find the right “voice” for blogging. My natural tendency is to write in details. Unfortunately, I don’t the time to afford it in the blog, and it’s probable readers can’t afford it either. So for the time being, I’ll try to be more concise. Let me know what you think :-) ]

So, what are the strategic moves these actors can make to both monetize their users and win ? First, let’s look at the monetization part:

• Sell “classic” ads: no need to expand. Doomed.
• Sell “non-classic” ads (cf the Esther Dyson piece): they would not only compete head to head with each other but also with the innovative travel search engines, which would propose such features as “friend an airline” themselves (only it would be “please let us know your 3 preferred airlines so that they can propose you personalized deals when you search for a travel plan”). This would make them compete in a broader, much more competitive market. They’re both unlikely to win.
• Adopt the transaction way: propose a search engine aggregator right on their site, and charge a %age off each transaction. Same thing: competition more acute, value for users not clear (if they are slightly less usable or competitive than another site, they will lose). Not only that, but the majority of frequent flyers are corporate users and corporate users book through their accredited travel agents (no choice).
• Charge a fee for premium accounts: classic model, charge users a small monthly fee for access to exclusive features. With 2 players competing for the same market, they would need a huge distinctive value to be able to charge this way. As we see below, they don’t .

As with all other social networking implementations, a key part of success is attracting users to get the spiraling effect rolling. How could D/T try to distinguish themselves to attract such users ?

• Add more features ? It’s unlikely one can come up with a feature so unique it isn’t imitable by the other one.
• Look and feel ? Idem.
• Actually, everything else, idem.

Tripit has for it its email extraction feature; Dopplr their look and feel and their commitment to openness (implemented deeper than Tripit’s). Neither has a killer competitive advantage to attract users, and it’s unlikely it even exists (but the future may prove me wrong). So should they do ?

In my opinion, go for the corporate market. Yes, I know, but please bear with me. The should offer corporations a specific set of features exclusive to their company’s employees. The main ones I have in mind would be to get in touch with other, but unknown, employees, while traveling (or at home when others are traveling). Picture this: you’re a young and recent employee of a global organization, stuck for the week-end somewhere you don’t know anyone. But it’s a big location of your company, so you know there are others also there. A tool that lets you signal you’re there and ready to go for lunch/dinner/skiing/whatever with other employees would bring everyone a lot of value.

Think about social networking in terms of costs/benefits: you use tools that lets you extracts more value out of your contacts in less time. Such a tool would let employees extract value out of very loose relationships (don’t even know each other, just employees of the same group) and out of their travel time. The cost / benefits for individuals is great. It is even more significant for said companies, in terms of knowledge sharing, networking, innovation opportunities, etc… (Hey, the only thing in common is their employer, what do you think will occupy 90% of their conversations ?)

Now let’s take our original monetization/attraction questions with this in mind. First, charge employers for access to such features. It is not trivial in terms of data security, and you can price monthly by active users (ie everyone can use it, but companies pay only for the ones who actually use the tool). Done right, this one is an easy sell.

Attraction ? Well, ones you start to have a significant subset of companies onboard, what do you think the employees will use to keep in touch with their friends and families travel plans ? Another tool so that they have the joys to juggle among 2 different apps for doing the same thing ? Right, by going after the corporate market, they would in effect get the spiraling effect in the consumer market (where they can have the transactions model if they want to).

Anyway, that’s my take on it and I would be very interested by any comments on these dynamics; especially if you think I’m wrong, please comment away…

What do you think next-gen strategies look and feel like? Can you name a company that’s a good example? What’s different about them – what’s their advantage built on?

I proposed to take TripIt and Dopplr as a case study. Their—now intertwined—future should provide insights on the characteristics of the competitive advantages they’re using.

Let me start by presenting these two companies and the way they’re competing. Then we will look at them from a strategy standpoint and explore what competitive advantages they seem to be using, and how that will likely evolve. Already familiar with these services ? Skip to the strategy part.

History

Tripit launched with a unique feature and value proposition. Frequent travelers spend a lot of time keeping track of their various travel plans, and inputing them in a variety of tools (personal calendar, corporate calendar) and devices. Tripit proposition is to let it do that. You forward all your travel confirmation emails to plans@tripit.com and let them extract the useful info, put that into a calendar with additional information (maps, weather, etc.) and finally provide you with a “clean” iCal feed (containing everything) that you can plug in any tool accepting iCal.

This was their core. They started well and kept refining the service with additional functionalities (like allowing an assistant to manage your travel plans, etc.). They also added the usual layer of Social Networking functions, allowing you to connect to others, share your plans, collaborate on travel planning, etc.

Dopplr launched for its part as a pure social network for frequent travelers, with a single feature: register your travel plans and connections, and Dopplr alerts you whenever you and your connections are in the same location at the same time. They also started well and kept refining the service with additional functionalities, but the core was these alerts.

Conceptually, think of Dopplr as a tool that allows you to manage the subset of your social contacts you would like to meet with when you or they are traveling. At its beginning, and even today, Dopplr could have provided the same service as a Facebook application, for example.

Tripit meets Dopplr. Though obviously in the same market, these two apparently ignored each other, until recently. Tripit, expanding its social networking functionalities, added “closeness” alerts, alerting you when you will be in the same location as one of your connection. Yes, it’s exactly Dopplr’s features.

Strategy

From a strategy perspective, Dopplr and Tripit differs significantly.

Tripit built has a strong and unique competitive advantage (CA) with its email extraction technology. It can provide a highly valued feature which is likely difficult to replicate. Its other features are classical social networking and closeness alerts, which do not provide any differentiation from Dopplr. In terms of design, the site and user experience has been well thought out, but without being mind blowing.

Dopplr on the other hand based all its strategy on a few CA that Umair would probably characterized as next-gen:

• Very skilled at connecting with thought-leaders and the blogosphere: Dopplr launched with an incredible buzz and this attention is sustained. It receives way more coverage than Tripit. This is due to the skills and connection of the peoples onboard.
• An emphasis and efforts on achieving radically new design and user experience. Take a look at both sites and Dopplr immediately stands out as purer and more fluid in terms of design as Tripit. Make no mistake, tripit is well designed as well, it just didn’t go as far as Dopplr in refining the feeling the use of the service provides to the users.
• What seems to be a better insertion in the “flow” as defined by Stowe Boyd: Dopplr embraces a lot of openess features: it has a FB app of course, but also lets you display a widget on your site or blog, etc.

What will be interesting is the future dynamics of this market. On one side, one player whose strongest asset is a unique feature; on the other, a player who plays better on several next-gen CA. Note also that TripIt’s founders seem to come from the travel industry while the founders and managers at Dopplr are a much more diversified crowd of geeks and designers. So the DNAs should be very different and what we’ll see might be the result of that.

How this will play will be shaped by the dynamics of the market too. Both players need to attract users in order for them to be useful to travelers, and both players need to monetize their user base.

A “premium” fee charged for additional features seems difficult to implement in this 2-players market. Monetization via ads should also not be straightforward, as travelers entering their trips have likely made plans anyway and shifting them from existing travel reservation sites will prove extremely difficult. Even Esther Dyson rosy picture, where one would “friend” an airline and let it propose special deals based on the travel plans, seems utterly optimistic. You don’t need to be a social networking site to implement such a feature, if this is successful on Dopplr, it first has to compete head-tohead with TripIt, and then with the likes of Orbitz which will implement these as well. (On Orbitz, you would just “friend” (authorize) an airline as well and accept that it proposes special deals when you search for your next ticket).

What does this leave in terms of competitive advantage ? We’ll explore this in part 2. Feel free to comment of course.