Tag Archives: licensing

How to price new enterprise software products

The enterprise software market is almost always a paid one. So how do you price a brand new enterprise innovation?

sw_px-200pxSoftware is one of those “magical” goods in microeconomic terms: it has virtually no Marginal Cost. So how do you get a customer to pay you thousands—or even millions—of dollars to buy something you can reproduce for free?

If you’re looking for a “magic formula” to calculate the price of your software, you can hit the ‘back’ button. You won’t find that here. Instead, if you are looking for a strategy to establish a tangible, defensible price for an intangible innovation, read on…

STEP 1: Price by the value you create

There are many, many software pricing models. However, at the end of the day, you’re going to have to defend your quoted price. This is easiest to do, if you price based on what your customers value. Figure out what units your customers use to measure value, and then pick a price model based on those units. Now you have Value-based Unit Pricing.

STEP 2: Use ROI to establish your “list price”

Enterprise software purchases are investments in “promised value.” However, it will take a lot of work for your customer to “unlock” that value: they have to get budget approval, initiate a program, execute it without over-runs, integrate it into their business operations, etc. To make it worthwhile, your software will have to provide a large return on this upfront cost—at least 40-50%. If your software cannot do this, it will never clear the triple wicket of business sponsor, IT manager and procurement manager.

Look at the market—and more importantly—what it costs your customers to do the very thing you are trying to automate or improve. Calculate the cost per year and subtract enough for a 40% ROI. Now you have your List Price. (Note: if there is already software you want to displace, price your product to make replacement of it something that yields a 40% ROI. Why should anyone take the risk to buy your product if it is not good enough to do this?)

STEP 3: Use co-development to establish your “maximum discount”

When you go to a new customer with a new product and quote a price, they will immediately ask for a discount (especially if you are new to the market). How do you insulate yourself against this? Establish a fixed lower bound for your software that you can legitimately never price below (at least until 1-2 generations pass and everything changes).

The best way to do this is by using co-development partnerships. Co-development partners not only buy and use your product; they provide added time, people, teamwork and insight to make it better. (This is not only good for them, it is also a path you can use to establish market leadership). Co-development should be rewarded with your Maximum Discount.

Once you have done this, whenever a follow-on customer pushes for a larger discount, you can point out that your co-development partner only received your maximum discount because of the work and time they contributed.

STEP 4: Build your price rate cards

You now have all the tools you need: value-based unit pricing, list price and maximum discount for co-development. You are now ready to give your sales and contracts team all those wonderful spreadsheets to calculate the price of your new enterprise software—at least until the next generation of innovation arrives…

A Few Closing Remarks: Two things to NEVER do when pricing your software

Give it away for free to get the deal*. You will inevitably get enticed to give your software away for free to get a major customer. Don’t fall into this trap. Once you have done this you have established your software truly has zero Marginal Value (not just zero Marginal Cost). It is really hard to negotiate UP from zero. Give away add-ons, charge implementation at cost—do anything—but don’t give away enterprise software for free (*unless you are using a Freemium model, of course).

Demand premium pricing. You may be so proud of your latest and greatest software that you will want charge more than “legacy providers” for your innovation. Unfortunately, unless you can demonstrate—at a visceral level—that your software provides value that no one else can, you have destroyed the ROI value proposition of your product.

Article first published as How to price new enterprise software at Oulixeus

SaaS’ next pricing challenge, balancing easy budgeting with flexibilty: Four models

Balancing-Act-280px-tallAfter many years on the marketplace, the benefits of SaaS – especially when compared to owning everything yourself – are obvious and well known: Flexibility to “dial” capacity up or down as needed, pay-as-you-go pricing, access to high economies of scale with low investment… However, SaaS pricing modes often lacks two things that we all had when we “owned” all of our own resources (people, servers, on-premise licenses, etc.): predictability and control.

Back then it was easy to figure out what our budgets would be for the next year. Our starting budgets were based on existing payroll (for IT and software staff) and capital resources. We could easily decide (usually once per year) if we wanted to increase or decrease this by X%. Once we did this, it limited how much we could possible spend. The big challenge was prioritizing this budget across what turned out to always be too many projects. (Usually, the time required to build and ramp up systems kept this in check.)

Now things are different. Because we can buy SaaS-based services quickly and easy we can do more in less time and with far less work. However, this can lead to traps where we become “victims of our own success.” The SaaS-based online program we launch could get so much traffic that our costs quickly beyond grow beyond our budget. The easy access to storage could lead our teams to store too much, burning through money.

This problem is bad enough with commodity items (usually serviced with IaaS, Infrastructure-as-a-Service and PaaS, Platforms-as-a-Service). It can become “unmanageable” with complex portfolios of activity that do not easy fall into easy-to-size units (marketing and advertising campaigns, clinical trials, public sector programs, etc.) In these cases, SaaS creates a predictability problem for “both sides of the table”: customers cannot easily predict and control what their budgets will be while vendors cannot easily predict revenue recognition (affecting their ability to control business expansion).

SaaS vendors need to find viable solutions to this conundrum balancing SaaS’ flexibility with the basic need to budget and control costs. Here are four options:

The Fixed Price Model

Under this model, the price of the SaaS product is fixed, regardless of usage volume. A first blush, this can easy to budget (great for customers). However, it can kill TCO for vendors (the first time a customer wildly exceeds planned volume). Guarding against this leaves vendors two choices: raise prices (to guard against – leading to reduced demand) or KYFC “keeping your fingers crossed” (potentially risky).

This model is good in places where variability is low (e.g., sales force automation – one sales person can only generate so many contacts in a given month).

The On Retainer Model

This model draws from the ‘Old World’ of having lawyers and accountants – people who can perform a wide range of services – on retainer. It is somewhat tailored on a case-by-case basis, looking at expected volume across a wide portfolio of work and flattening this out into constant quarterly or monthly payments, adjusted by periodic reconciliation (based on actual vs. planned usage). This balances customer and vendor risk – and predictability with flexibility. However, it is complicated.

This model is good in places where usage is subject to “external factors” (e.g., portfolio-based business models like architecture, legal, research, campaign management, etc.)

The Credit Model

This model draws ultimately from the postal service (e.g., stamps). Customers budget for and buy X usage credits per quarter. Each use of SaaS consumes these until their budget runs to zero. They can distribute these credits for use internally however they desire. This “caps” costs but can leave businesses “in a lurch” if credits run out faster than expected.

This model is good for discretionary business applications (e.g., recreation/reward allowances and advertising click-thru’s)

The Tax Model

This model adds a standard overhead “tax” to a recurring operation. It is most well known in the credit card payments industry but has applications in many other “commodity” transactions. It is predictable. However, it requires high volume to avoid high taxation rates per transaction.

This model works best in places where the cost of the transaction is low vs. the value of the item transacted (e.g., eCommerce, HR payroll software).

None of these are ideal for all circumstance. However, each balances the benefits of SaaS’ flexibility with the “old fashioned” business need of predictability and control for specific business scenarios.

Disclaimer: I have been both a SaaS buyer and seller, using all of the models above – and many more that I would avoid like the plague. See my background for more information.

Note: If you liked this, you may be interested in Nine (Ten) Software Pricing Models Evaluated