I help hundreds of technology buyers each year to understand the impact of technology changes on their software contracts, but I also get questions from software providers about how best to price their products. Some are bringing new products to market and want to know how to maximize revenue, while others are struggling with obsolete metrics such as per processor and want to update their pricing for the modern mobile, cloudy world. The answer is usually to find licensing metrics that make their pricing value-based while balancing simplicity and fairness. The more value a customer gets from your product, the more they should be willing to pay for it. If you make your pricing too simple then you won't match value sufficiently closely, which will cause you to price yourself out of some deals and leave money on the table in others. If, OTOH, you try to match value too precisely you risk making your pricing so complicated that buyers will reject it, and you, completely.
For example, suppose you have a product that will help people do their jobs better, so you decide that charging for each user will be a good approximation for value. The potential problem is that not everyone will use your product the same, in terms of depth of functionality and/ or frequency of access. Your single per user price will be unfair to companies with long tails of light, infrequent users, for whom you'll therefore be too expensive. Conversely your pricing will be unfair to you when the customer is mostly power users. To make your pricing fairer you could have different prices for different categories of user, but then you risk being criticized for being too complex.
SAP is advertising for a new Director Of Pricing & Licensing. The job description states “The Strategic Pricing Director is a key member of SAP’s Revenue Strategy and Pricing Group. Pricing is a critical component of SAP’s overall strategy and go-to-market activities.” Duties include:
· Develop and implement pricing strategies based on economic and competitive dynamics.
· Price products and services appropriately based on the value customers receive.
· Define and drive pricing strategy for new and/or existing solutions.
IMO, SAP does many things very well in the pricing and licensing domain. I cite it to other publishers as an exemplar of best practices in a couple of areas, such as its pricing by user category, use of business metrics for parts of the suite that deliver value independent of manual use, and tying maintenance volume discounts to conditions such as centers of excellence that filter out users’ basic support calls. However, SAP does have room for improvement, in terms of Forrester’s five qualities of good software pricing, namely that it should be value-based, simple, fair, future-proof, and published.
Considering those goals, and as an advocate for software buyers, here are some things that I’d like SAP to add to the job description:
Microsoft recently announced that it will change to its European currency pricing policy from July 2012, and the effect could be a 20% price increase for UK customers. It didn’t publicize the change, preferring to let its resellers tell their customers as and when the change affects them, so I thought I’d tell my readers what you need to know. Firstly, here is some background. Most global software companies have one master price list in their home currency and reset price lists in other currencies every year or even every quarter using then-current exchange rates. Microsoft has always taken a different approach, having set €, £, and other prices in 2001 and continuing to use the same exchange rate ever since. There are pros and cons to this approach:
· Pro: local prices are stable and predictable. In contrast, € and £ prices from other US-based vendors may rise or fall by 20% from one year to the next as the currencies fluctuate. (This is one reason why SAP’s revenue rises and Oracle’s falls when the € weakens against the $, as these price changes affect demand.)
· Con: European companies pay more than their US-based peers. This doesn’t matter so much if you’re only competing with domestic rivals, but global companies see and resent the discrepancies.
The lines are blurring between software and services — with the rise of cloud computing, that trend has accelerated faster than ever. But customers aren’t just looking at cloud business models, such as software-as-a-service (SaaS), when they want more flexibility in the way they license and use software. While in 2008 upfront perpetual software licenses (capex) made up more than 80% of a company’s software license spending, this percentage will drop to about 70% in 2011. The other 30% will consist of different, more flexible licensing models, including financing, subscription services, dynamic pricing, risk sharing, or used license models.
Forrester is currently digging deeper into the different software licensing models, their current status in the market, as well as their benefits and challenges. We kindly ask companies that are selling software and/or software related services to participate in our ~20-minute Online Forrester Research Software Licensing Survey, letting us know about current and future licensing strategies. Of course, all answers are optional and will be kept strictly confidential. We will only use anonymous, aggregated data in our upcoming research report, and interested participants can get a consolidated upfront summary of the survey results if they chose to enter an optional email address in the survey.
Yesterday I attended Computacenter’s Analyst Event. It’s a major independent provider of IT infrastructure services in Europe, ranging from reselling hardware and software to managing data centers and providing outsourced desktop management. My main interest was how it manages the potential conflict between properly advising the client and maximizing revenue from selling software. For instance, clients often ask me if it's dangerous to employ their value-added reseller (VAR) to advise them on license management in case the reseller tips off its vendors about a potential source of licence revenue.
An excellent customer case study at the event provided another example. A UK water company engaged Computacenter to implement a new desktop strategy involving 90% fully virtualized thin clients. Such a project creates major licensing challenges on both the desktop and server sides, because the software companies haven’t enhanced their models to properly cope with this scenario. The VAR’s dilemma is whether to design a solution that will be cheapest for the customer or one that will be most lucrative for itself.
As we said in our recent report “Refresher Course: Hiring VARs,” sourcing managers should decide whether they want their VARs to provide design and integration services like these or merely process orders at a minimum margin.
Computacenter will do either, but they clearly want to do more of the VA part and less (proportionately) of the R. So, according to their executives, they have no hesitation doing what is best for the customer even if it reduces their commission in the short term. But they didn’t think many of their competitors would take the same view.
I get a lot of input into my research from speaking with software buyers and sellers, which I analyze and process to come up with firm conclusions and recommendations in my published research and forum speeches. I'm going to use this blog to air some work-in-process analysis, to solicit additional thoughts and information from you. Just recently, Ive been considering why people are talking about 'pay-per-use' a.k.a. 'utility pricing' for software, and to me, the disadvantages to buyers and sellers outweigh the benefits.
Software pricing should be simple but fair, value-based, future-proof and published (see The Five Qualities Of Good Software Pricing). Yes, a one-price-fits-all 'per user' fee isn't fair or value-based, but that doesnt justify the potentially horrendous complexity of tracking detailed usage. Role-based user pricing, such as SAP user categories, is a much better way to reflect diverse usage profiles.
Im not arguing against flexible, on-demand services, particularly for temporary needs, such as renting some CPU power for a few hours. I'm concerned about pay-per-use pricing models for regularly used applications. To me they would be: