How to price Enterprise Social Computing offerings?

How to price social enter­prises appli­ca­tions? Value and util­ity pric­ing through increas­ing price struc­tures Why ven­dors and clients should develop and agree on reverse pric­ing schemes for all the “enter­prise 2.0” (mean­ing­less but broad buzz­word intended)? Increas­ing pric­ing struc­ture that increase the price as the num­ber of active users increases are far more efficient than cur­rent degres­sive pric­ing struc­ture, that dis­con­nect com­pletely value and cost for clients. This explains largely why, even as large enter­prises are express­ing inter­est, the mar­ket for this type of appli­ca­tions is not grow­ing nearly as quickly as needed and often antic­i­pated. This would also help the puz­zled ven­dors who won­der why, since their appli­ca­tion add so much value (they are right), only few large enter­prises are actu­ally will­ing to buy them at what seems a rea­son­able pric­ing (they are wrong). We explore here how ven­dors and their clients can cre­ate mutual value by agree­ing on increas­ing pric­ing schemes. Julien Le Nes­tour | Feb­ru­ary 09 | Use with this post (or not, but designed to!)| julien@macroprinciples.com | Cre­ative Com­mons Attri­bu­tion Non­Com­mer­cial Share Alike http://www.flickr.com/photos/alkalinezoo/2474735037/sizes/o/ A clas­sic degres­sive pric­ing scheme is the most com­mon struc­ture used by “enter­prise 2.0” ven­dors 1 Cur­rent sit­u­a­tion Aver­age cost for the orga­ni­za­tion of a new user active on the appli­ca­tion Price is usu­ally capped after a thresh­old Dol­lar scale $ 2 Aver­age Cost per user 0 10 50 200 1000 5000 10000 20000 40000 60000 N 100000 Num­ber of active users (absolute num­ber) Users scale (here in total num­ber of users) “Enter­prise 2.0” appli­ca­tion ven­dors have gen­er­ally adopted a clas­sic degres­sive pric­ing scheme: the price per user is decreas­ing as you buy access for more employ­ees. Julien Le Nes­tour | Feb 09 macroprinciples.com licens­ing Vari­a­tions like flat pric­ing may occur, but most usu­ally fall back to the same old and clas­sic degres­sive pric­ing scheme 2 Cur­rent sit­u­a­tion But of course you nego­ti­ate when you’re big and fall back to degres­sive Aver­age Cost per user $ 1 Flat price per user announced as a list price Aver­age Cost per user N 100000 0 10 50 200 1000 5000 10000 20000 40000 60000 Num­ber of active users (absolute num­ber) Some ven­dors choose to dis­play a flat price per user per period as a list price. But of course, it’s noth­ing more than clas­sic degres­sive pric­ing after a — usu­ally low — thresh­old. The same can be said for thresh­olds in num­ber of users (pay this for up to 10 users, than you pay this for up to 100, etc.). The main effect of these vari­a­tions is to dis­con­nect the mar­ginal and aver­age cost per user. The trend for the lat­ter remains the same how­ever. Julien Le Nes­tour | Feb 09 macroprinciples.com licens­ing Thanks to increas­ing returns dynam­ics, the aver­age value per user increases in scale for clients Cur­rent sit­u­a­tion Dol­lar scale: $ value extracted by the client orga­ni­za­tion Mar­ginal value for the orga­ni­za­tion of a new user active on the appli­ca­tion Aver­age Value per user N 0 10% 20% 30% 40% 50% 55% 60% 65% 70% 80% Num­ber of active users (% of total pop­u­la­tion) Users scale (here in % of total user pop­u­la­tion) All offerings falling in the “enter­prise 2.0” domain have some degrees of increas­ing returns dynam­ics: as more employ­ees start using the appli­ca­tion, the value they gain by using it increases. This can be any­thing from pos­i­tive net­work effect for basic appli­ca­tions to more com­plex scale effects for elab­o­rated offerings. To quote Umair Haque: “their mar­ginal pro­duc­tiv­ity increases in num­ber of con­nected users”. Since the indi­vid­ual pro­duc­tiv­ity of each indi­vid­ual start­ing to use the appli­ca­tion increases with scale, the mar­ginal and aver­age value of a new active user at the orga­ni­za­tion level is cumu­la­tively even more expo­nen­tial. Addi­tional sources: Umair Haque Julien Le Nes­tour | Feb 09 macroprinciples.com licens­ing The level of increas­ing returns scale effects depends on how well designed the appli­ca­tion is 2.0 RETURNS TO SCALE !”#$%&’(‘)*+,$ -(.$/+012(,$0′$3&-4+ Cur­rent sit­u­a­tion Com­bi­na­to­r­ial (Haque) The returns to scale of web and soft­ware appli­ca­tions vary accord­ing to their prop­er­ties. Increas­ing returns scale effects are now com­monly used by con­sumer and cor­po­rate appli­ca­tions. The type of returns achieved (their slope) depends on the prop­er­ties of the appli­ca­tions. Returns Expo­nen­tial (Reed) Poly­no­mial (Met­calfe) Scale We will 2.0 economies scale? Viral and net­work economies, because they How shoul­duse a simplified graphic ver­sion of the value curve, but ven­dors should strive to achieve the directly medi­ate users and/or peers, should real­ize polynomial-exponential returns best scale effects pos­si­ble within their offering. to scale. Dis­trib­uted economies, because they micro­me­di­ate the recom­bi­na­tion of plas­tic microchunks, should real­ize exponential-combinatorial returns to scale. Refer to Umair Haque’s excel­lent work (figure extracted from his pre­sen­ta­tion: The Age of Plas­tic­ity Edge Com­pe­tences and Net­work Eco­nom­ics 2.0) for a start­ing point: URL: http://www.bubblegeneration.com/resources/edgecompetences.ppt Source: Umair Haque, The Age of Plas­tic­ity Edge Com­pe­tences and Net­work Eco­nom­ics 2.0 Julien Le Nes­tour | Feb 09 macroprinciples.com licens­ing The size of the client’s orga­ni­za­tion impacts its value curve for absolute num­bers, not rel­a­tive num­bers Cur­rent sit­u­a­tion Dol­lar scale: $ value extracted by the client orga­ni­za­tion Small co Mid co Big co Aver­age Value per user 0 10 50 200 1000 5000 10000 20000 40000 60000 N 100000 Num­ber of active users (absolute num­ber) Users scale (here in total num­ber of users) Of course, the size of the client’s orga­ni­za­tion impacts the form of its value curve. The larger a com­pany is, the more extended its value curve will be. Note that when the scale used is the per­cent­age of users within the total employee pop­u­la­tion, then size is not a fac­tor and there is only one curve (see slide 4). Julien Le Nes­tour | Feb 09 macroprinciples.com licens­ing Value and cost are com­pletely mis­matched with a degres­sive pric­ing scheme while they should be as closely aligned as pos­si­ble! Ratio­nale for change Dol­lar scale: value extracted by the client orga­ni­za­tion $ Aver­age Value per user Aver­age Cost per user N 0 10% 20% 30% 40% 50% 55% 60% 65% 70% 80% Num­ber of active users (% of total pop­u­la­tion) Users scale (here in % of total user pop­u­la­tion) The price paid per user is decreas­ing as clients add users whereas the value extracted from each user increases with each new one brought on board. The mis­match is strik­ing and has sev­eral con­se­quences. Julien Le Nes­tour | Feb 09 macroprinciples.com licens­ing The incen­tives for large (hence risk averse) com­pa­nies to try a dis­rup­tive tech­nol­ogy are weak $ Ratio­nale for change Aver­age Value per user 1 2 3 Pilot pop­u­la­tion Deploy­ment being done Full deploy­ment pop­u­la­tion Pilot Cost per user N 0 10% 20% 30% 40% 50% 55% 60% 65% 70% 80% Aver­age Cost per user Num­ber of active users (% of total pop­u­la­tion) Large com­pa­nies will aim at a corporate-wide deploy­ment, the one max­i­miz­ing value. But they will approach it in a phased way: 1) First con­tact and nego­ti­a­tion of the long-term pric­ing for the full deploy­ment as well as punc­tual pric­ing for the pilot 2) Small scale pilot to test and mit­i­gate busi­ness, tech­ni­cal and user adop­tion risks 3) If pilot suc­cess­ful, expand to a pro­duc­tion deploy­ment Julien Le Nes­tour | Feb 09 macroprinciples.com licens­ing A degres­sive pric­ing scheme increases the cost of tran­si­tion­ing from pilot to pro­duc­tion for dis­rup­tive tech­nolo­gies $ Ratio­nale for change • Large scale deploy­ment • Small scale deploy­ment for user adop­tion • Low total cost • Unsus­tain­ably low ROI per user due to degres­sive pric­ing • Project at risk if does not scale quickly to lower cost per user and increase ROI to reap scale economies • High total cost • High ROI per user because of degres­sive pric­ing • Project at risk because the ramp-up period for user adop­tion will be long, while the cost paid and ROI planned assume full deploy­ment 40% 50% 55% 60% 65% 70% 80% Aver­age Value per user Pilot Cost per user N Aver­age Cost per user 0 10% 20% 30% Num­ber of active users (% of total pop­u­la­tion) After the pilot, 2 main strate­gies to deploy glob­ally: 1) (on the left) Start with a small group of users, usu­ally early adopters and for whom the busi­ness value is clear, then expand from this core 2) (on the right) Deploy glob­ally as quickly as pos­si­ble A degres­sive pric­ing scheme makes it very difficult to jus­tify either the total cost or the ROI per project. The more dis­rup­tive the tech­nol­ogy, the more difficult to demon­strate its benefits, the more such a scheme makes it more difficult to deploy. This helps explain he difficulty to get pilots for ven­dors and the risk averse nature of clients. Julien Le Nes­tour | Feb 09 macroprinciples.com licens­ing By switch­ing the price to align with the value, the total rev­enue for a ven­dor stays the same, even if reached at a different pace 1 Benefits $ Value 1) With degres­sive pric­ing, ven­dors are pric­ing out at small scale, while for­giv­ing most of the value at large scale 2) The total rev­enue with degres­sive pric­ing fol­lows the price (=cost) curve 3) If we switch the cost to align with the value, then the growth in rev­enue has a different pace, but the total rev­enue stays the same Pric­ing out For­giv­ing value N 0 10% 20% 30% 40% 50% 55% 60% 65% 70% 80% Num­ber of active users (% of total pop­u­la­tion) Cost 2 $ Value 3 $ Cost Value Total rev­enue with degres­sive pric­ing N 0 10% 20% 30% 40% 50% 55% 60% 65% 70% 80% Num­ber of active users (% of total pop­u­la­tion) Total rev­enue with increas­ing pric­ing Cost N 0 10% 20% 30% 40% 50% 55% 60% 65% 70% 80% Num­ber of active users (% of total pop­u­la­tion) Julien Le Nes­tour | Feb 09 macroprinciples.com licens­ing Ven­dors need to shift from few clients at full price (degres­sive pric­ing) to lots of clients at pro­gres­sively increas­ing prices (increas­ing pric­ing) 1 Benefits $ Rev­enue scale Degres­sive pric­ing Strat­egy: Expect large rev­enue streams from a few clients, don’t go if can­not get a full rev­enue stream right-away. If client wants to deploy pro­gres­sively, make it pay a dis­counted full price or par­tial but not dis­counted (can’t have both!). a Total rev­enue by client a) a very small num­ber of clients have done a full deploy­ment, pro­vid­ing large rev­enue streams b) a small num­ber of clients are pilot­ing the appli­ca­tion. The num­ber is small because of the planned difficulties to tran­si­tion. c) clients express­ing an inter­est, but not see­ing an ROI with a large enough prob­a­bil­ity, are stay­ing on the side­lines, due to the costs and uncer­tainty asso­ci­ated with a pilot Increas­ing pric­ing Strat­egy: Expect clients to start small-scope pilots to mit­i­gate poten­tial risks and demon­strate the value, then move on to a phased deploy­ment when the value has been demon­strated. Make it easy for them to jus­tify the project by giv­ing them a sta­ble ROI per user through­out the deploy­ment. Man­age a port­fo­lio of clients that are at vary­ing stages of their pilots and deploy­ment and increase rev­enue as they scale up. c N 0 100 200 300 400 500 600 700 800 900 Num­ber of clients … b c 0 100 200 300 400 500 600 700 800 900 Num­ber of clients … N 2 $ Rev­enue scale Total rev­enue by client a b a) a big­ger num­ber of clients are in full deploy­ment, but at avry­ing stages of it, pro­gres­sively deploy­ing the appli­ca­tion as their orga­ni­za­tion is get­ting used to it b) a large num­ber of clients are pilot­ing the appli­ca­tion, attracted by the very good cost/benefits/risks ratio c) clients express­ing an inter­est exper­i­ment with the basic ver­sions of the appli­ca­tion, or for very large prospects, kick-start an experiment/pilot with the vendor’s help licens­ing Julien Le Nes­tour | Feb 09 macroprinciples.com Util­ity pric­ing, ie pric­ing per active user, is nec­es­sary to allow a suc­cess­ful deploy­ment of a dis­rup­tive tech­nol­ogy $ 2 Price per user con­tin­u­ously Pric­ing Met­rics to avoid thresh­olds effects 1 Instead of charg­ing just 3 Aver­age Cost per user Aver­age Value per user different prices for 3 ranges N 0 10% 20% 30% 40% 50% 55% 60% 65% 70% 80% Num­ber of active users (% of total pop­u­la­tion) When deploy­ing a dis­rup­tive tech­nol­ogy like enter­prise social net­work­ing, 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. If charg­ing with thresh­old effects (x$ for 100 users, than y$ for 1000 users), the ven­dor makes artificial and unnec­es­sary dis­con­nects between cost and value. If charg­ing reg­is­tered users, the ven­dor does not charge for value but for its per­ceived poten­tial to deliver value, which can be badly wrong. Julien Le Nes­tour | Feb 09 macroprinciples.com licens­ing Note on pric­ing met­rics: why active users count is gen­er­ally more efficient Pric­ing Met­rics Active user pric­ing Active users activ­ity is often the best proxy for value. It should be auto­mat­i­cally tracked within the appli­ca­tion and at a high enough fre­quency (ie monthly or quar­terly, not just annu­ally). Activ­ity pric­ing not efficient Activ­ity pric­ing aims at match­ing value and price exactly. It is very difficult to define activ­ity met­rics that match value exactly how­ever, and gen­er­ally the dis­con­nect is too large to be used efficiently. Exam­ple: enter­prise search appli­ances pric­ing per doc­u­ment indexed fall in this trap obvi­ously. Most com­pa­nies have poor archiv­ing prac­tices, keep­ing obso­lete doc­u­ments on the net­work. Charg­ing to index those doc­u­ments (that can rep­re­sent a large por­tion of the total doc­u­ments) sim­ply increase cost with­out increas­ing value. Activ­ity pric­ing too uncer­tain for dis­rup­tive tech­nolo­gies Another rea­son why activ­ity pric­ing is a sec­ond best to active users pric­ing is the difficulty to define tar­gets for dis­rup­tive tech­nolo­gies. Search is known. Take the appli­ca­tions deliv­er­ing Twitter-like capa­bil­i­ties to the enter­prise. The best would be to price by usage, that is, by mes­sage. But how do you define the “nor­mal” usage to set your prices ? No one knows. Price it per active users how­ever, and you do cap­ture the value rec­og­nized by the employ­ees, since they will con­nect only if they find value in its use. Julien Le Nes­tour | Feb 09 macroprinciples.com licens­ing The cost/benefit ratio of Increas­ing Pric­ing for small com­pa­nies is too low, Degres­sive Pric­ing is adapted here $ Big co Mid co Small co Aver­age Value per user Seg­men­ta­tion The mech­a­nisms of value are the same for small com­pa­nies. Look­ing at the value in terms of the pro­por­tion of total employ­ees bring the same results. N 0 10% 20% 30% 40% 50% 55% 60% 65% 70% 80% Num­ber of active users (% of total pop­u­la­tion) $ Small co Mid co Big co Aver­age Value per user Looked at it in terms of absolute users, how­ever, the cost/benefit of imple­ment­ing increas­ing pric­ing is too low for ven­dors. For small and some­times medium com­pa­nies, the best strat­egy is to keep degres­sive or flat pric­ing. A thresh­old then needs to defined by the ven­dor to deter­mine when switch­ing from degres­sive pric­ing to increas­ing. This needs to be based on the total num­ber of employ­ees in the client’s orga­ni­za­tion. 0 50 1000 10000 40000 100000 N Num­ber of active users (absolute num­ber) Julien Le Nes­tour | Feb 09 macroprinciples.com licensing

• Arnaud Poujardieu
  Bonjour Julien
  I fully agree with your point of view related to ESN pricing model
  Changing pricing model and habits is tough. Those who will succeed in this chalenge will get a more balanced relation between ESN provider and clients. This will create more Win win conditions which is mandatory for long term mutual valuable relations opportunity.
  I am working at blueKiwi. Are you ready , for benchmarking this model together within Schlumberger?
  Will be please talking with you
• Julien Le Nestour
  Hi Arnaud -
  
  Thanks for your comments. I am not blogging as an employee here so I will be in touch privately. Don't want to create any ambiguity ;-)
  
  Best regards,
  - Julien
• charlie
  Julien, thanks for writing this. It summarizes nicely a critical strategic issue for both the enterprise customer and the vendor. As you point out finding this alignment is critical to successful relationships in the long term. Piloting social applications is and interesting exercise given the nature of the value curve. Articulating hard ROI from smaller pilots and then extrapolating that forward to bigger user populations is critical. Any further thoughts on this by you or your readers would be welcome.
• carlo
  Hi Julien,
  
  thanks for this excellent piece of analysis. At my company Qitera that offers a enterprise social search platform (http://www.qitera.com/enterprise) we are currently defining our new pricing shemes and your article brings in some very well-thought perspectives.
  
  I am also senior advisor at IT-research firm Experton Group and recommended your post to the readers of our new blog. http://experton-group.blogspot.com/2009/02/ente...
  
  regards et à bientôt
  Carlo
• Jon Husband
  I'll comment more later, but for now ...
  
  In general, the argument you have set out has articulated en brouillon the thinking I have been doing about what I call ROII (Return on Investment in Interaction). For that I thank you.
  
  Re: 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.
  
  I think that this is essentially the inverse of (for example) a $50 million dollar SAP implementation.
  
  Which I think speaks to timing and attention scarcity. SAP for me is (still) an example of a transition technology, as the evolution of IT applied to business and work processes began the major move from paper to information systems in a real and pervasive sense. If you think about it, it wasn't really that complex .. take existing processes, align them horizontally instead of vertically, strip out obvious redundancies (everyone remember the "Spot the Waldo" reengineering stuff ?), and then pour electronic concrete (SAP system) over it.
  
  Now we are moving into collaboration applications layered over a dense-and-deep IT infrastructure (let's leave ERP systems out of this aspect for now), applications that consist of stitching together various web tools and web services (as a generality) that lay on top of the denser, more "permanent" databases and engines. These applications ands services are becoming both more open and more integrated all the time, to the point where through "open" APIs people can plug the tools they like using into larger applications and systems. As the concept of "cloud computing" evolves, so too will the mix-and-match personalisation.
  
  The former (and current) pricing models assumed amortization of investment over time in something more-or-less permanent (at least, assumed to be for the purposes of ROI hurdles).
  
  With large-scale (and over time growing) participation and interactivity, the notion of value obtained and created changes, as you have pointed out.
  
  I'll re-read and think, and come back when I feel I can talk cogently about ROII.
• Julien Le Nestour
  Hi Jon, many thanks for the already insightful comment, eager to read more :-)
  
  Yes, ROI is no longer a meaningful metric. What amazes me now is how many people are judging a tool based on its "features", which is an even less relevant concept to judge IT offerings.
• Sibs
  Juliene,
  
  Great article, thank you for sharing. I agree with your point of view 100%. The network effect of social computing in the enterprise is a great way of articulating the argument of volume increasing pricing. I think there are two barriers to address, however, by vendors and vendors in consultation with their clients. 1) Balancing those elements of a solution that may be construed by organizations as more social-social than social-work and 2) Ensuring that the client marketing/champion is doing a good enough job to drive adoption. From our experience deploying our next generation directory solution (http://gtec.innovapost.com/), these two issues are a challenge to a volume increasing pricing strategy.
  
  For #1, with many social applications there are often features and functionality that don't have a hard link to business productivity. I'm an advocate of 2.0 in the workplace as I believe there are productivity (see my whitepaper Beyond Functional Contribution via the link above) and employee engagement benefits to be reaped, but we do have to be careful because some solution elements are, and will be, used for social-social purposes. If the solution has an abundance of features that drive social-social behaviour and attract users as a result, it's a tough pill to swallow for organizations to pay more because the organizational value proposition under these circumstances because more tenuous. Those of us in the Enterprise 2.0 space would still maintain there is value, and I am one of them, but not all of our customers will.
  
  For #2, I think we all agree that enterprise 2.0 is largely a cultural paradigm shift about the nature of work and the view of employee behaviour. So deploying these solutions in the enterprise requires the enterprise to roll up its communications, culture change, and marketing sleeves and promote the internal solution like they would their latest product launch. As a vendor, we need to help guide these efforts as they will directly impact the use of the solution. If we don't provide clients with any help, but we want volume increasing pricing, we're not doing ourselves any favours.
  
  Just a few rambling thoughts as I read your article.
  
  Warm regards,
• Club Penguin Cheats
  It summarizes nicely a critical strategic issue for both the enterprise customer and the vendor. As you point out finding this alignment is critical to successful relationships in the long term. Piloting social applications is and interesting exercise given the nature of the value curve.
• Kids Games
  Interesting assessment. Developing a pricing strategy can always be a source of contention for companies. You lay out a good outline to follow.