OnStartups

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.

2. 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.

3. 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.  

4. 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.  

5. 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).

6. 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.

7. 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.

8. 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. 

9. 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.

10.   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.