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