When writ­ing blog posts, we usu­ally reply to one or sev­eral other posts, quot­ing at most 2–3 extracts of them. In emails, it is fairly com­mon to keep reply­ing and artic­u­lat­ing refine­ments as fur­ther thoughts are spurred. Why don’t we do it on blogs as well? I don’t know, but I’ll try here, and it may prove inter­est­ing. Let me know what you think, pos­i­tive or negative ;-)

I recently asked Olivier Amp­rimo to exam­ine my argu­ment around pric­ing for Enter­prise Social Com­put­ing offer­ings. He kindly did it with an excel­lent post, so this is my reply, a bit in the spirit of old-fashioned cor­re­spon­dence. Olivier gave some back­ground info in his post, and let’s just add that I have rarely wit­nessed such deep thinking—his blog is full of excel­lent mate­r­ial as well. Obvi­ously, there is much more in Olivier’s analy­sis, than the points I reply on here. (You may want to read the post Olivier scru­ti­nize, then his before this one)

Let’s start with a basic typol­ogy. There are at least 4 dif­fer­ent types of Enter­prise Social Com­put­ing offer­ings, each enabling a dif­fer­ent set of capa­bil­i­ties for the organization:

1. A core foun­da­tional plat­form for enter­prise social net­work­ing: think of it as Face­book or LinkedIn redux inside an orga­ni­za­tion. Employ­ees have rich pro­files, explicit con­nec­tions, an activ­ity stream tied to their net­work and an open archi­tec­ture allow­ing to pull activ­i­ties from the exist­ing busi­ness sys­tems. News­ga­tor is an excel­lent example.
2. Spe­cific but corporate-wide tools avail­able to all employ­ees: here we have the Twitter-likes, Youtube-likes, etc.
3. Per­sis­tent, large-community, but not corporate-wide social tools: wikis, blogs, and so on used by spe­cific and per­sis­tent com­mu­ni­ties. Tra­di­tional com­mu­ni­ties of prac­tice exem­plify this type of needs.
4. Per­ish­able social tools used by focused teams, usu­ally project or busi­ness teams: these are the wikis used within teams to pre­pare the busi­ness doc­u­ments for exam­ple, a Team­Space if using Share­Point, etc.

Onto Olivier’s post:

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

Fun­da­men­tally, Julien makes the assump­tion that Enter­prise Social Com­put­ing offer­ing is all about prod­uct offer­ing.[…]

An Enter­prise Social Com­put­ing pilot is not about test­ing an off the shelf solu­tion, it is about build­ing a con­tex­tual plat­form, with mashups and tweaks. Yes, con­ver­gence hap­pens in the social com­put­ing soft­ware. Prod­ucts are embark­ing more and more fea­tures. Lines are get­ting unclear between blogs, wikis, social net­works and … But there is no off-the-shelf social stack. The most expen­sive is there­fore not the soft­ware; it is its imple­men­ta­tion. It is not the prod­uct; it is the know-how and the sensemaking.

When test­ing offer­ings falling in Types 2, 3 or 4, I would agree. But the license fees for a good plat­form, even for a pilot period are impor­tant and rival the imple­men­ta­tion costs. While there is no off-the-shelf social stack, orga­ni­za­tions need to start with the best pos­si­ble plat­form (best is highly con­tex­tu­al­ized to each orga­ni­za­tion). Often times, the fees for this kind of plat­form, with a reg­u­lar volume-discount pric­ing, are tak­ing up a good pro­por­tion of the bud­get. Even if just equal to imple­men­ta­tion costs, license costs are mate­r­ial in launch decisions.

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

As a result, the pilot phase is actu­ally the most expen­sive phase. It is where one injects know-how and mean­ing. Post pilot costs are just deploy­ment costs and, some­times, addi­tional customization.

My point exactly. As Olivier says, pilots are already incred­i­bly expen­sive in terms of know-how. If you pile high license fees on top of it, as you do when using volume-discount pric­ing, then the cost of the pilot explodes along with the risks, and the poten­tial ROI of a full deploy­ment sinks. Hence my argu­ing for very low pric­ing for a pilot, essen­tially cost-offsetting, before increas­ing the pric­ing as usage increases.

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

Julien makes the assump­tion of a stan­dard and enterprise-wide deploy­ment, upfront. This works well with tra­di­tional (non-social/individual) client appli­ca­tions (such as office) or with Enterprise-wide process appli­ca­tions (such as an ERP or a CRM). The prob­lem is that there are hardly any stan­dard and enter­prise wide deploy­ments of social com­put­ing, upfront. Social com­put­ing tools are not address­ing the same issues as tra­di­tional IT ones. The deploy­ment is pro­gres­sive as social com­put­ing tools address con­tex­tual and pre­vi­ously implicit inter­ac­tions around explicit, usu­ally enterprise-wide processes.

We dis­agree on this point, and here’s why: even though any deploy­ment will be phased, the busi­ness case is built with the sought-after end in mine: a global deploy­ment. Pilots are for tast­ing the water. Gen­er­ally cheap in terms of funds, always expen­sive in terms of resources. Clients don’t test tech­nol­ogy stacks with­out being assured they will be able to deploy if they want to. Hence, they nego­ti­ate and lock pric­ing in before they start the pilot. If they don’t, the price will unfor­tu­nately have dou­bled when they want to pursue ;-)

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

That’s why they have a net­work effect as Julien rightly noted, but that is also why the logic of apply­ing the net­work approach to pric­ing is dif­fi­cult.

1.    One approach is the game the­ory that Jean-Lou Dupont uses on RWW: “it only takes *one* detrac­tor (i.e. some­one who sells an equiv­a­lent ser­vice at bet­ter price… that’s what com­pe­ti­tion is for, no?) to make this the­o­ret­i­cal model fall down”.

Some­how I fail to see how the incen­tives work that way. Volume-increasing pricing:

• is not chang­ing the total cost (for the client) or total rev­enue (for the ven­dor). It sim­ply changes how it’s vary­ing over time. The Total Cost of Own­er­ship when fully deployed is the same.
• makes ini­tial pric­ing per user very low and even free when the rea­son­ing is applied 100%. How a com­peti­tor 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 com­put­ing caters is the long tail behind the fire­wall.
Read fur­ther a pre­vi­ous post of mine.

Slide 12 of Julien’s enclosed scribd-ed KeyNote pre­sen­ta­tion, he states that “it is impor­tant for the client to make it avail­able to all its employ­ees: which groups of employ­ees will rec­og­nize its value first is unknown, and you may not tar­get the cor­rect group if you do a tar­get deploy­ment”.
Julien works in an envi­ron­ment that is very spe­cific, yet com­mon. He is entrenched in IT (that is used to think “prod­uct’) and at a cor­po­rate level (that is far from oper­a­tions, which hap­pens to be very true in his indus­try). The com­bi­na­tion seems to let him thinks about stan­dard prod­ucts that are eas­ily deploy­able top down. One size fits all. Expe­ri­ence shows it tends to be time con­sum­ing, finan­cially costly, oper­a­tionally dis­turb­ing and employee fright­en­ing.

Back to my open­ing typol­ogy: for a corporate-wide enter­prise social net­work­ing foun­da­tional plat­form, 1 plat­form is needed, not sev­eral liv­ing together. For spe­cific but cor­po­rate tools, one stan­dard tool is also needed. If orga­ni­za­tions want to share videos inter­nally, they are look­ing for one Youtube-like tool, not many which will com­pete for a crit­i­cal mass in the knowl­edge pool built. For type 3, per­sis­tent tools, stan­dard­iz­ing the plat­forms also ease the bur­den on the user by avoid­ing using dif­fer­ent wiki tools when switch­ing wikis for exam­ple. Not to men­tion 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 invest­ments. Two dif­fer­ent sce­nar­ios can be envi­sioned for deploy­ing wikis used in teams for example:

1. Let users choose the wiki appli­ca­tion best suited for their needs, and let they deploy and man­age them on an ad-hoc basis.
2. Rec­og­nize the need for on-demand and fully cus­tomiz­able wikis, but enforce a stan­dard tool to cre­ate them, like Atlassian’s Confluence.

In case 1, you offer full con­trol to the end-users to choose the tool they want, but this would inevitably result in a costly mess to main­tain. In case 2, 95% of the con­trol is given back, but the tool is stan­dard. The ROI will of course dif­fer widely in the two cases. Stan­dard­iz­ing always brings cost-savings, and can more and more be done with­out impact­ing the returns on the applications.

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

In fact, it is a ques­tion of per­spec­tive (sense­mak­ing) and method­ol­ogy. As in charge of inno­va­tion, Julien is in a posi­tion to go for pilots, which means that he is in a posi­tion to search for and inter­act with the “cor­rect group” to build a suc­cess­ful (or not) use case. That’s empiri­cism. This would help him get a sense of the impact the pilot might have at a larger scale, as well as the dif­fi­cul­ties of pre-requisites for a suc­cess­ful imple­men­ta­tion (with enterprise-wide in mind on the term).

This is easy to do when you’re look­ing at build­ing capa­bil­i­ties enabled by tools falling in type 3 and 4, and this is what most com­pa­nies do. How do you do it when you are look­ing to deploy an enter­prise social net­work­ing plat­form? A twitter-clone? Within large orga­ni­za­tions, whether or not you’re in IT, you can’t pos­si­bly know all the dif­fer­ent groups oper­at­ing with their own cul­ture, goals, processes, incen­tive struc­tures, etc. Tar­get­ing is use­ful but not opti­mal at all. If you tar­get, you may hit some “cor­rect groups”, but then again you may not. Even if you do it exactly the right way, facts of life within large orga­ni­za­tions can turn a cor­rect group into an incor­rect one at a high velocity.

The best strat­egy seems to be to com­mu­ni­cate and pub­li­cize the capa­bil­i­ties, then let the groups who would ben­e­fit from the tech­nol­ogy enablers use them.

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

A par­tic­u­larly inter­est­ing approach in this con­ver­sa­tion is Atlass­ian’s pric­ing pol­icy and busi­ness model. Atlass­ian has a tra­di­tional pric­ing struc­ture in the soft­ware indus­try, to a cer­tain point.
Atlass­ian plays on:

• Low­er­ing the entrance barrier.

The price is below the usual amount of money that requires the work­flow of inform­ing a lot of peo­ple to get one sig­na­ture, as well as many oppor­tu­ni­ties for loads of “why” and a “no” and is capped. Peo­ple are thus empow­ered to test the prod­uct, cus­tomize it to cater local and con­tex­tual needs. By doing so they poten­tially build a use­case and start the grass­root move­ment below radars. The client becomes the reseller. But the pric­ing is made in a way that if the first year is afford­able, the next year ones are more expen­sive that tra­di­tional soft­ware: 50% of the ini­tial license (vs 10–20%), not to men­tion the adjust­ment of users. So in the end, on a 3 year basis, the cost of the soft­ware is not cheaper than tra­di­tional soft­ware, but the prod­uct is up and run­ning and inhouse (so that it is too late to say NO!)

• Vol­ume of portfolio.

Low­er­ing the entrance bar­rier is the best way to have a large client base. And because the bal­ance between first and next year is 2 to 1, the turnover of Atlass­ian grow sub­stan­tially mechanically.

• Nice and robust products.

They are self-explanatory thanks to a mean­ing­ful inter­face, that embarks con­tex­tual help and an exhaus­tive help doc­u­men­ta­tion one click away. As such, they require nor cost nor effort in the sup­port and main­te­nance phase (n+1 and beyond) and ensure that Atlass­ian milks the cow, with style

Yes, Atlassian’s pric­ing is smart. But the cow they don’t milk. One con­di­tion such pric­ing works well is that the unlim­ited user license is still not highly priced. If it was, then we would not see the same accep­tance of the prod­ucts. Yet, it fails to cap­ture the pro­ducer sur­plus it could when used in large orga­ni­za­tions with per user pric­ing, albeit not the tired old way.

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

Julien these were my 2 cents, happy to dis­cuss this further.

I cer­tainly hope so, although you might want to avoid this cor­re­spon­dence style :-) Not sure how this works for readers…

Source: Enter­prise Social Com­put­ing Pric­ing: insight­ful, but you hardly see the woods for the trees