Startup Tips for Enterprise Software Pricing

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.

Community

Google+

And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:

Google

Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Answers.OnStartups.com

Subscribe to Updates

 

30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn

OnStartups

Current Articles | RSS Feed RSS Feed

Startup Tips for Enterprise Software Pricing

 

One of the topics that is a common dilemma founders of enterprise software companies face is pricing.  It’s a complex issue which does not lend itself readily to “formulaic” answers.  Having said that, I have a few thoughts and ideas on how to approach this problem (but this list is by no means exhaustive, nor definitive).

Please note that I’m not an enterprise software pricing “expert” by any stretch of the imagination (even if using a startlingly imaginative person).  However, I do have some “first hand” experiences with the issue and can share some ideas drawn from those experiences.

Tips and Ideas For Pricing Enterprise Software

 

  1. Know That Enterprise Software Is Sold, Not Bought:  What I mean by this is that enterprise software deals are rarely closed by customers having a need, doing a Google search, finding your website, entering their credit card number and generating revenue for you.  Enterprise software of significant complexity requires effort from a sales perspective.  This has the further challenge of being both expensive and time consuming (your sales cycle in the early periods of an enterprise software product will likely be measured in months (sometimes over a dozen months), not weeks.
  1. Factor In Sales Costs:  Too many first-time entrepreneurs make the mistake of pricing their product based on what it costs to develop, without factoring in what it will cost to sell the product.  This does not even take into account the cost of implementation (a separate issue), but the costs to get a customer from being a lead/prospect to where you have a signed contact (and yes, you’ll need a contract) which results in cash exchanging hands.  Do not be surprised if it costs you more to actually close a deal (in terms of travel, sales commissions, legal fees, etc.) than you had planned on charging for the product.
  1. Define A “Variable” Component To Pricing:  Instead of coming up with some “fixed” price for an enterprise license for your product, see if you can find some variable metric to which you can attach your pricing.  If possible, this metric should map to the value that the customer is getting from the product.  Even better, is if the metric maps to how your customer does business.  For example, if you’re selling real-estate software to independent agents (for the record, I know nothing about this market, it’s just an example), you could price the software on a per transaction (or even a percentage of transaction basis).  This way, the customer pays as they create value for themselves (hopefully with the aid of your product).  Though there may be some customer resistance to this variable pricing, it will often be less than you might expect.  In my first company, we made a major switch-over from “fixed” licensing to a “per-account” price.  The per-account model worked because that’s how the industry worked anyways, and everyone understood it.  Our customers indirectly made money on a “per account” basis, so the cost of our software fit nicely into their accounting and profitability models.  
  1. Limit Use Of  The “Tolerance For Pain” Pricing Model:  In my early days, we often priced our products based on our “best guess” as to what the customer could afford.  This was what you might informally call the “tolerance for pain” model.  Given the low volume of deals, every customer was a unique deal and it wasn’t difficult to determine approximate size of business and potential value that we were bringing to the table – and pricing accordingly.  However, this model does not “scale”.  It is too dependent on founder/management involvement and unnecessarily increases the complexity of the sales process.  
  1. Beware Customer Consolidation:  In my experience, many startups that sell to enterprise customers will at some point or another feel the pain of consolidation (i.e. one customer buying or merging with another customer or prospect).  If you’ve sold an “unlimited” license to Small Company X (and you came up with the price out of thin air, based on the tolerance for pain model above), and then Small Company X is acquired by Big Company Y – you’ve basically just short-sold yourself.  Big Company Y is now using the “enterprise license” of your software sold to Small Company X.  Multiply this by 5 or 10 occurrences and your startup can easily go out of business because it runs out of “low hanging fruit” customers to sell to.  This is another good reason to have variable pricing.  In my personal case, just about every time we had a customer get acquired by a larger company, the larger company also became a customer and generated a substantial increase in our software license fees.  What made this particularly beneficial was that these deals rarely incurred the sales cost, because of the pre-existing relationships – we simply started multiplying by a larger number of “units” (in our case accounts).  The more astute readers will likely guess that this was very high margin business (and yes, it was).
  1. Consistently Increase Prices In The Early Years:  If you plan to offer more than one product (which many startups do), then it is in your interests to have a demonstrated history of increasing the prices of your products over time.  This has multiple advantages:  First, in case you had priced your product too low to start with (which is much more likely than having priced it too high), then the increases give you an opportunity to “catch up” and find that optimal price point.  Second, once the market becomes aware of this consistent practice, customers learn that it is to their benefit to adopt your product early and be rewarded by way of a lower price.  This gives the sales process some much needed “urgency” (which is a key to closing big deals sometimes).  I’m not talking about the tacky:  “Drive it off the lot today for this low, low price which is only available while you’re on the showroom floor!”.  I’m talking about having a bit of structure around your pricing proposals (so the price is not available indefinitely) and coming up with a regular schedule for revisiting and adjusting your prices.
  1. Consider the “Most Favored Customer” Clause: This one’s a little tricky, and I hesitate a bit to even offer it here lest some take the decision too lightly and jump into something without understanding the details.  But, I’ll take a chance and talk about it anyways.  The “Most Favored Customer” clause in a contract basically provides certain customers “price protection” in the event you lower your prices for future customers.  So, let’s say Company X is considering buying your product for $1,000/user.  One of their concerns is that they’re in a competitive industry and if Company Y ends up getting a “better deal” from you in the future, they could find themselves at a cost disadvantage.  The “most favored customer” clause can address this concern, which might be helpful in getting the customer “over the hump”.  However, the even better benefit to something like this is what it does for your dealings with future customers.  Lets’ say you gave your first two or three customers a “most favored customer” clause at the $1,000/user price-point.  When you are negotiating a deal with your next customer, you have more leverage than you otherwise would.  In Game Theory, I would call this an “advantage by self-induced constraint” phenomenon.  Basically, you’ve taken away your ability to give deep discounts to future customers because if you did, you’d have to go back and reduce the price for the existing customers that you had the “most favored customer” clause with.  Oddly enough, this actually does work when you have somewhat “arbitrary” market pricing where customers don’t know what the “real” price of a product should be.  This saves you from “acts of desperation” where you substantially undercut your own prices to get a deal done.  However, I recommend that you think through the issues here and consult an advisor before jumping into something like this.  I include the idea here because it has worked for me in the past and can be a powerful tool in the startup tool-chest.
  1. Focus On Maintenances:  Most enterprise software deals have some sort of recurring “maintenance” fee that customers pay (usually on an annual basis).  These fees often cover incremental updates to the software, some level of technical support and other benefits.  An important thing to remember here is that your maintenance fees not only need to cover your costs for the “support’ that you are providing, but will likely also become your primary funding for future R&D that you do on the product.  If you under-price your maintenance, you will be starving your future cash-flows that would go towards funding enhancements to the product.  Nobody wins win this happens.  One way to counteract customer resistance to higher annual fees is to make a commitment to enhance the product.  In my experience, I have seen situations where the software company sets aside a certain number of “development hours” for product enhancements that are driven by customer feedback.  This also gives customer’s comfort as they are then assured that the product will not be easily “abandoned”.  You want to provide customer comfort by devising a vehicle that takes some portion of the maintenance dollars for Product X and funnels them back into Product X.  This is actually a good thing for you too. 
  1. Avoid Trial Installations:  Based on how much leverage your customers have, and how desperate you are, you may be asked to provide “trial” copies of your software running on customer premises.  This wouldn’t be such a bad thing if it were not for the fact that actually installing the software and getting it working for the customer comes at a substantial cost to you.  This problem is made even more acute by the fact that in a fair number of cases where trials don’t result in sales, your startup had nothing to do with the outcome.  It could be because the customer lost interest, didn’t have real interest in the first place, or didn’t allocate sufficient internal resources to the trial project.  My recommendation here:  Don’t do it.  This is almost always a losing proposition in enterprise deals.  Instead of trials, try to use “acceptance periods” (a form of money-back guarantee) that allow a customer to determine the software does what it is supposed to after the sale is made.  This way, money has exchanged hands, you have some confidence that someone somewhere actually decided to “invest” the necessary resources and you dramatically reduce your chances of an “aborted” deal.  The biggest concern you should have with trials is that although you think you have a deal (and they’re simply ensuring the software works), the people that actually sign contracts and write checks have not yet approved the purchase.  So, you’re basically spending your cash (which is likely scarce) to fund a “pilot project” that only some guy in some business unit buried inside the organization cares about.  Trust me on this one.  [Note to self:  An entire article could be devoted to this one topic alone, as there are many other subtleties to the issue].  Note to readers:  When I leave a note to myself, I actually do come back and read them and it generates ideas for future articles.  I don’t just do this for dramatic effect.
  1.   Leverage Cost Of Capital Differences:  When dealing with large numbers, it might be helpful to remember that your cost of capital (i.e. cash) is likely much higher than your customer’s.  As such, it is not unheard (and not tacky, if done correctly) to offer customers the equivalent of a “cash discount”.  This could be in the form of prepaying maintenance and/or future service fees (though you can’t recognize the revenue, the cash is almost as green) or more “immediate” payment on the upfront fees.  In my experience, getting cash to exchange hands as early in the process is worth some reduction in fees.  This is particularly true for new customers with whom you don’t have an established relationship.

Phew!  This article ended up being much longer than I expected (I banged it out in one sitting, as I do most articles).  I’m still not sure I answered the original question, but hopefully have at least provided some food for thought.  This is clearly a complicated issue, and I’m sure books have been written about it.  

Summary Of My Message:  It is more important to get the “structure” of your pricing right than it is the actual values.  Also leave a way for you to “adjust” your prices over time (ideally, by increasing them) and beware the hidden costs of enterprise software sales (sales calls, aborted trials, delayed payments, ulcers, etc.)

What are your experiences?  What challenges have you faced in the enterprise software pricing game?  Leave comments and share your thoughts, your fellow entrepreneurs will be appreciative.

Posted by Dharmesh Shah on Mon, May 08, 2006

COMMENTS

Any advise on Pilot Projects? Should a startup do free pilot projects?

posted on Wednesday, May 10, 2006 at 2:07 AM by Gaurav Agarwal


Jim Geisman www.softwarepricing.com) is a real expert in this area. He's active in the MIT Enterprise Forum, conducts seminars, and consults. Very good guy. I have notes on his recent seminar for MITEFC GET SMART on my blog: http://www.raydeck.com/2006/02/software-pricing-notes/

posted on Wednesday, May 10, 2006 at 9:13 AM by Ray


Can't see anything on the 'Forum' page. :(

posted on Wednesday, May 10, 2006 at 1:14 PM by


For what it's worth, here is a related blog post

http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html

posted on Wednesday, May 10, 2006 at 5:32 PM by Rob


Exceptionally useful article!

posted on Thursday, September 28, 2006 at 7:17 AM by Sheamus


You have really considered the various dimensions of Enterprise Software Pricing. Congrats.

It is not a coincidence that I have just a couple of days blogged about Software Product pricing http://blog.nrichsoft.in/2006/12/12/getting-your-pricing-right/

It is not meant for any particular category of products but it addresses the issues one needs to address before getting onto the aspect of pricing.

posted on Thursday, December 14, 2006 at 9:16 PM by Badri


Very well written article.. I agree the structure of pricing is far more important than the actual prices.

posted on Sunday, February 18, 2007 at 3:37 PM by JM Smallwood


Excellent article! This contains valuable and useful information that shows much experience was involved in the writing. I myself have experienced many of the shortcomings described as well as resolved them with the same or similar recommendations. As a curiosity, has anyone observed a hybrid pricing model with upfront licenses per site/location coupled with monthly and transactional pricing for maintenance fees?

posted on Wednesday, April 30, 2008 at 12:44 PM by Cindy


Dharmesh, 
 
Very well thought out list of points. Good Article.  
 
I would think that one of the other things that enterprise software developers need to think about is whether to offer their product as a TBL (time based license) where the cost of the software is for a three year use. This model as opposed to a term license. You cover it somewhat in point #8 under maintenance but not directly. With TBL mechanism you have the opportunity to recover the cost of the added cost of R&D and new features at a much higher price point as opposed to maintenance revenue which is usually lower. The TBL pricing can also include the maintenance fee.  
 
The other point is that companies also need to factor in post-sales costs. Ex: costs occurred when an application engineer needs to visit the site to help get over an technical issue that cannot be resolved over the phone or if the company calls in with a request to train additional staff for s/w use.

posted on Thursday, August 13, 2009 at 7:52 AM by Deepak Das


Dharmesh - Brilliant article.  
 
You have a typo in it. 
Nobody wins win this happens == Nobody wins when this happens 
 
shiraz

posted on Thursday, August 13, 2009 at 4:49 PM by skanga


Don't forget to formulate a negotiation and discount strategy. It's hard to enough to come up with your pricing internally, but then many software companies start discounting rampantly at the first sign of trouble in the sales cycle. This create a vicious cycle that dramatically reduces profits. So be prepared. If customers have price objections, that may be a good sign. Enterprise buyers are trained to raise price objections. Understand them. Offer to remove value in exchange for lowering price. ("we're pretty self-sufficient, we don't want to pay for 24/7 support." "Ok, we'll take you down to bronze support.") You can also use prepayment discounts, as the post suggests, case study discounts, or work with the customer to lower installation costs.

posted on Friday, August 14, 2009 at 12:37 PM by Reuben Swartz


Thanks for the article. This really helps to get the thoughts rolling. It's hard to know where to start with pricing in the Enterprise space. Cost models vary so widely that sometimes if feels like a lot of guess work.

posted on Monday, August 17, 2009 at 3:04 PM by Micah Slavens


Hi Dharmesh, 
 
This article is well written and full of ideas that help many of us able to work out a very critical item of marketing a product in an ever changing marketing environments. Sometimes we forget the basics of selling and buying. In many areas solution is selling and not marketing. Cost and pricing model depends on what works for a customer. Very good article! 
 
Rama

posted on Thursday, August 20, 2009 at 10:16 PM by rama


Comments have been closed for this article.