A lot has been written in economic and business literature about pricing. You remember, find the market clearing price, factor in elasticity etc. All very valid economics but not exactly reality in a world where you are selling software to a few dozens of customers for many thousands of dollars.

In my experience, enterprise software pricing is as more art than science. This is true both of establishing pricing models as well as setting price points. However, there are some important best practices in that art. Here are my favorites regarding pricing models:

1) Align pricing with business value. This one seems so obvious until you look at what real companies do. Take companies that price their software on CPU counts. Jane customer says: “Hmm. So the worse performing the sofware is (i.e. it doesn’t scale with me) the more you’ll charge me”. With the stipulated exception of an innately compute bound process, it makes no sense. Common scalar metrics are per application module and per user. Frankly these work pretty well because they are common and well understood.

However, models that tie directly to value are even better:

• Per invoice sent
• Per device deployed
• Per dollar saved
• etc.

However, some of these can risk violating #2, #3 and #4 below.

Annuity models where you capture value during successive time periods have their own innate business value connection in that they are paid as the customer keeps using (and hopefully valuing) your product. But this can be overlayed on the other metrics.

2) Make sure that the pricing makes sense to your customers (oh and your sales people while you’re at it). If your sales team and customers cannot grok the intent of the pricing model quickly you are doomed to spend the rest of your tenure in the job explaining it over and over to the befuddled faces of people who are going to go write a custom contract that blows away your consistent model anyway.

3) Don’t make it too complicated. Any econ geek worth his graphs will be tempted to come up with an ‘n’ variable model that factors in the elasticities and optimizes for nearly all situations. However, this will certainly violate #2 and possibly #4. Stick with K.I.S.S. models as long as they deal with #1, #4 and #5. A quick test is can you tell someone the model once and have them use it without further discussion. If not, try again.

4) Make sure you can actually and easily track (and enforce) the metric. This one is a classic, particularly for products where the model has changed. Somebody decides to charge per widget instead of per dingaling but has no way of counting widgets efficiently. This is bad for you because:

• you will spend a lot of effort chasing the metric
• you will annoy your customers
• you will lose revenue

Not only that but you will incent non-compliance. The customer usually wants to be compliant, often for moral reasons but at least for audit purposes. If you make it hard to figure out what they are actually using (and will have to pay you for), they’ll just start fighting you on everything and trying to game their way out of as many units as possible.

5) Ensure that the timing of pricing matches the provisioning of service. That’s a fancy way of saying that if you are typical enterprise software vendor who will have an ongoing relationship with your customer for years, make sure that there is a good way to capture additional revenue down stream to make it continue to be worth supporting the customer.

Typically, enterprise software has a substantial maintenance and support charge that helps with this long term alignment. However, since this is allocated to the support and engineering organizations, it leaves nothing for the sales and service side to spend their effort working for.

SaaS models are ideally suited to this problem. The customer pays continuously as you provide your running software continuously.

However, even with conventional software ‘sales’, there are ways of generating recurring revenue. Just make sure that you have designed a product where the customer needs more over time. More seats, more transactions, more devices, more functions, etc.

6) Signal appropriately. Technically, this is probably more a price point issue but I’m throwing it in anyway. Make sure that the pricing is well aligned with your intended position in the market. If you are trying to be the high end vendor and go in with an pricing offer lower than your competitor you are not sending the right message.

7) Don’t be too rigid. Enterprise software sales have a strong tendency to be customized for many of the customers. Either because they have unique needs, or more commonly because of competitive pressures and other negotiations.

Know and communicate to your team the healthy exception vectors. What things can be changed without violating best practices down the road? Price points are easy. Ratios of upfront to repeat charges (per time or per added unit) will fit into the model. However, changing the scalar metric to something you can’t track is not a good idea.

If you’ve followed these best practices, the custom pricing should not cause problems rather just be another tool for generating business.