Accuracy vs. Simplicity

You are supporting two slightly different versions of the same product, maybe running on different hardware or against different databases. Based on experience, Version B is a little more complex than Version A to support, requires a slightly more skilled support engineer perhaps, takes a little more troubleshooting time, or tends to be used by customers who need more handholding.

It makes sense to price support for Version B a little higher than for Version A then, right?

Quick, what do you think?

For me, it’s a big maybe. Yes, it makes logical sense to price higher, but who said pricing was a science? If you already have multiple levels of pricing, perhaps because you offer multiple levels of support, adding yet another differentials may push your pricing in the complicated category, hence less appealing to customers, not to mention more vulnerable to errors. So perhaps you are better off with a consistent price, for simplicity’s sake.

Pricing is psychological

What’s a better pricing strategy? $99.95 or $100?

It depends. If you’re selling to consumers the classic approach is to use $99.95, which looks so much cheaper than $100 and a bargain is a good thing. On the other hand if you’re selling to the enterprise using $99.95 seems cheap, unsophisticated, nickel-and-diming.

In the same vein, if you decide to use a non-standard way of pricing support (say price per system when the usual approach is pricing per user) you’ll want to check that your target customer will consider it future-thinking, not out-of -it. This doesn’t mean you must always follow the safe and boring path of imitating what your competitors are doing — but you must check that your approach is viewed as fresh, inventive, attractive rather than bizarre, far-fetched, and worrisome.

Pricing Schemes

As we all know support pricing is as much art as science, but pricing schemes are fairly limited. You can price:

• by user: you have a choice here since you can price by named user (anyone liable to use the system) or by concurrent user (the maximum number allowed to use the system at one time, regardless of how many different users can exist.) This scheme works well if the underlying product itself is priced by user — and naturally it should be possible to audit the number of users to minimize, shall we say, counting errors. Because it’s annoying to have to count users each day many vendors sell support for bands of users, say 100-200 users.
• by system or platform. This works well if the product is itself a box, or runs on a particular box, but may have various numbers of users or caretakers. Here again you want to be able to audit the number of systems.
• by support contact. The approach here is different: instead of counting heads (or boxes) we count the number of individuals allowed to contact support for personalized, 1-1 service. This scheme is often a part of a mixed scheme, combining a basic per-user charge (for the maintenance part of support) with a per-contact charge for the support piece per se. The benefit of per contact pricing is that customers have an incentive to minimize the number of technical contacts, which in turn may increase the technical ability of the contacts. And you can more easily impose certification or other conditions on the contacts.
• by site. The idea behind this scheme is to create a custom quote for the customer, estimating their global usage for the year. This is typically done only for large customers and in conjunction with a site license arrangement for the product. Customers like site deals because it gives them complete freedom to add users.
• by transaction. This is not a common scheme (yet) but I believe it will develop as a value-add pricing scheme over time. The idea here is that instead of paying per user or per system the customer pays per useful things that can be accomplished with the product. So for instance if the product is a CRM system perhaps the customer could pay per case. The more cases logged the higher the bill.
• by incident. In contrast to the previous scheme this one is very old: you call, you pay. Very common with consumer products.

Are you using other schemes? Please post a comment and share your experience.

The psychology of percentage vs. fixed pricing

Quick, which is cheaper? Premium Support priced at 100k PLUS the 18% (of license) Standard Support or Premium Support priced at 21%  of license?

If you’re like most people, that 100k sounds big, doesn’t it, bigger than the measly 3%. But in fact, if the license exceeds 3.33 m (certainly a large amount!) you’re better off paying the 100K than the 3%.

What does it mean for pricing? You should be aware that a large fixed fee may frighten customers away, so consider using a pure percentage, or split the difference as in  “50k plus 20% of license”. At the same time, a high fixed fee is useful to set a minimum entry price so you could add a caveat, as in “21% of license with a 100k minimum” or “21% of license with a 150k minimum”.

Always run the computations using with several likely license price levels until you are satisfied that you can both get your minimum prices and an attractive scheme for the customer.

Mixed fixed and percentage pricing?

Most support offerings are priced using either a percentage of the license price or fixed pricing. But there’s no law that says you cannot mix the two. A typical example would be a high-end offering that includes account management, let’s call it Platinum, that could be priced as (for instance) 20% of license PLUS 75K, where 75K represents a portion of an account manager’s time.

Caveat number 1: By using fixed pricing you may well be leaving money on the table since fixed pricing does not scale. So if a very large client selects Platinum you would need to assign more than 75K’s worth of an account manager to it while you are only taking in the 75K. Not good.

Caveat number 2: While a “percentage plus fixed” pricing scheme is not terribly complicated it’s not as straightforward as a pure percentage or pure fixed price, so you expose yourself to unintentional (and, perhaps, intentional) pricing errors that create bad feelings with customers during the initial transaction and renewals. This is not good since you want to treat your Platinum customers with great care. I’m a great fan of simplicity and mixed schemes are never the simplest.

Caveat number 3: If you are watching VSOE compliance (and you should) you may be told by your Finance team that mixed pricing schemes are not compliant. That’s not an entirely true statement, since VSOE mandates consistency of pricing across comparable customers, regardless of the pricing scheme, but certainly the existence of a mixed pricing scheme makes it more difficult to establish VSOE for Platinum, so there is indeed a technical reason to avoid mixed pricing.

Bottom line: use a mixed pricing scheme where it makes sense — that is when it doesn’t unwittingly create a situation where your largest customers are getting too much for too little.

Anything wrong with fixed pricing for support?

Many vendors use percentage pricing for support. For instance, basic support may be priced at 18% of the license price. Would it be wrong to use a fixed price instead?

Fixed prices are just fine. They are very simple to communicate and they can have an effective dampening effect on discount requests. They can be easier to manipulate on price lists and quotation forms.

On the other hand, fixed prices can be awkward when you need to scale them for customers with more licenses or more products. If all your customers use the same product, no problem: charge them all the same amount. But it makes little sense to charge customers the same amount for 1000 licenses or 1 — nor can you charge the customer with 1000 licenses 1000 times more than the customer with the one license.

So before you fall in love with fixed pricing be sure to check how it will scale for larger customers. You don’t want to either leave money on the table or be seen to be gauging your largest and typically most important customers.

Supporting sunsetted products

Is it possible to provide support for a product that is no longer supported by Engineering? And is it possible to charge for that support?

Yes and yes — with caveats.

Normally, for an active product, a support contract provides assistance with questions and troubleshooting, fixes for at least major issues, and periodic maintenance releases. The commitment also extends to continuing to support the product for either a set period of time or until a number of new releases become available. Customers are sometimes happy to upgrade to new releases if new releases are consistently more stable than older ones or if they contain interesting new functionality, but for many customers the cost and uncertainty of upgrading makes them wish to remain on older releases. In other cases it’s the vendor that decides to “sunset” a product. In either case, the Support organization has a choice to provide support, or not, for a product that’s no longer active from a development perspective.

1. Plan ahead. The worst circumstances to make a decision on how far to go to help a customer is when the customer is in trouble — and the Engineering team is nowhere to be found. Have a game plan and communicate clearly with customers ahead of emergencies to avoid painful escalations.

2. Explore the limitations of restricted support. It’s true that most customer requests are not associated with bugs, and it’s also true that customers running older releases are less likely to be making production changes, hence to create new problems, but the possibility of discovering a new bug on an older product is not nil. What will you do then? Also you may rely on the Engineering team to deliver troubleshooting assistance, not just fixes. Would you be able to conduct troubleshooting without help? Finally, customers are likely to run into problems with the surrounding environment: will the old release work if they have to upgrade the operating system? the database?

 

 

3. Be honest with the limitations within Support. Providing support for a slightly-old release is fairly easy since the staff remembers it well, but after several years it can become more challenging as turnover makes experienced staff rare and reproduction environment disappear. If you want to continue to provide support on older releases you should expect to beef up the knowledge base and the reproduction environment. It’s not just “free money.”

4. Make case-by case decisions. If an older release is relatively problem-free, has an adequate base of customers wanting to remain with it (meaning enough of a revenue base), and there are no compelling reasons to upgrade to the next release, you have a good candidate for extended support. Otherwise, you should probably say no. Ideally there can be a transition period during which minimal Engineering assistance is available for troubleshooting and the most critical fixes, after which time you can plunge into support-only mode.

5. Archive the older release code. You never know!

6. Communicate clearly. Customers that are running older products need to understand exactly what they are paying for. In particular, if absolutely no fixes are available, they need to understand the need for careful testing of any changes. It may be wise to schedule a conference with the customer to ensure that the special terms of the support-only contract are well understood.

7. Enforce the SLA. If a customer chooses to remain on release 5 after it’s officially sunsetted (support only, no fixes), be prepared for some constructive discussions the nesxt time she finds a bug. It’s important to carefully refer back to the agreement and encourage either a migration to the current release or a workaround rather than caving in to a fix.

8. You can charge more (for less, as it were…) Customers who want to remain on older releases may be prepared to pay a premium to avoid upgrade costs, and they should understand that, although the vendor is no longer required to create fixes, there are real costs associated with supporting older releases in terms of people, reproduction environments, and the costs of supporting a small numebr of customers. You can increase the cost by a fraction each year that passes to reflect that fact. (And I would never offer such support for less than normal maintenance rates.)

Bottom line: it’s absolutely possible to provide “support only” maintenance contract, without fixes, and you can charge a premium for support beyond the normal period, but beware of having to provide suppor tn older products when your staff is no longer familiar with them.

Support for custom applications?

If the software you support can be customized extensively, the resulting applications may be completely different from the vanilla version, and your customers may want you to support them. What are the options?

Say no. Many vendors choose this apparently safe route. They only support the vanilla application and expect the customer to provide the troubleshooting and programming expertise to debug problems on the customized application. I say this is “apparently” safe because the reality can be that the support staff expands vast amounts of effort and time coaching and helping customers come up with the test cases from which they can work.

Team with a third party. A popular route, especially when the customization is created by a third party is to ask that third party to take over the support of the completed application. This should work well because the third party is familiar with the details of the application (at least if it built it) and has the technical skills required to perform debugging and enhancements. On the negative side, the relationship with the customer is mediated by a third party (which could be completely fine if you have an indirect model) and naturally the third party could heap all sins upon you if there’s a problem, even if the issue lies in the customizations. You also leave money on the table doing this.

Provide support using a custom quote. Some vendors are bravely trying to provide support to custom applications themselves. This is clearly risky unless they have a pretty good idea of how the application was customized in the first place, so typically such arrangements are limited to customizations done by the vendor’s Professional Services team, or vetted and approved by it. Vendors in this situation also need to ensure that they have a good handle on source code control. The pricing for supporting the customized application is established once the application has been inspected and is additional to the support of the base application.

Provide support using a standard quote. Here’s a new idea: rather than requiring a custom quote for supporting customized applications why not automate the pricing to some percentage of the customization work (this would require that the vendor’s own Professional Services group perform the customization.) The advantage of this approach is to streamline the buying process (and renewals). The main concern is to maintain an appropriate level of funding, especially for small-scale customizations that don’t cost very much upfront but may require significant levels of additional support. Are you experimenting with this idea? Tell us about your experience.

Flat fee or percentage pricing?

When deciding whether to price support offerings with a flat fee or via a percentage of the license price, keep the following in mind:

- A flat fee is well-suited to a set product price. On the other hand, if the license price varies a lot a percentage will conform better to the potential variations in price. In particular, using a percentage will allow you to maximize revenue from customers with the largest purchases — and without much pushback from them.

- A flat fee is a natural mechanism for imposing a floor or minimum price.

- With percentage pricing there’s the age-old debate of whether to compute it against the list price or the net (discounted) price. Be sure to clearly define the rules.

- It’s fine to mix and match, for instance to price support with a percentage price but with some fixed-price options (e.g. for additional contacts.)

- As always, keep pricing simple. The more convoluted the pricing the more it will require explanations and justifications for customers, and the more likely “mistakes”, intentional or not, will be made while quoting. Keep it simple and easy to justify.

Is simple better?

When it comes to support pricing, yes! Complicated pricing antagonizes customers because they feel it must be hiding predatory practices; breeds confusion with sales reps that easily leads to “creative” pricing; and opens up avenues for customers to press for discounts.

Simple pricing with firm no-discount or pre-planned discounts policies removes confusion and is better accepted all-around. In the enterprise software world, a pricing based on percentage of net license with no discounts seems to be a very robust and successful strategy. You can offer several levels of support at various percentage levels and voila! A complete support portfolio everyone can feel good about.