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.

I have a unique product so how can I do a competitive analysis for support?

Good for you! A unique product is a wonderful thing!

Now about the support portfolio: the fact that your product is unique doesn’t mean that the support for said product will be incredibly different from the support offerings for other products. You may need to get a little creative when it comes to finding appropriate “competitors” to benchmark against, but you should be able to find plenty of relevant inspiration, for instance:

• Vendors of products in the same general space, even if their product offer is different from yours (I know you’re unique). Analyzing their support portfolios will tell you something about the way customers expect support to be packaged (free or not, limits on contacts or incidents, support hours, etc.)
• Vendors of products that your target audience will use in conjunction with your product. Look at their support pricing for inspiration, in particular the structure of the pricing: is it per user? per system? per incident?
• Vendors of products that are similar to yours, but that use a different distribution model than you, so packaged if you’re SaaS, or open source if you are not. From the customer’s perspective it’s the total solution that matters so it’s useful to look at different models.

I like to consider 5-7 “competitors” in the analysis to get a good picture of where you stand. Good luck!

Support for “free” customers?

Many vendors have a hybrid model through which some customers get completely free service, with the hope that some will switch to fee-based service. In that situation, what are the options to deliver support to the free segment of customers?

1. Provide the same level of service for all customers. The idea here is that all customers, regardless of their current status, may upgrade to paid service, hence it makes sense to provide the same level of (assisted) service to all customers to get them to sign up for paid service. This is a common strategy for startups who simply must attract enough of a base to survive. It’s often not a sustainable strategy for the long run, as clearly paid customers expect higher value and a higher level of services that can be afforded for the masses.
2. Provide differentiated service to paid customers. The idea here is that paid customers are clearly more valuable to the company, even if today’s free customers may turn into paid customers tomorrow, or eventually. So while free customers are given a minimal level of (assisted) service they don’t get the same perks as paid cusotmers. Under this scenario the higher support levels could, in themselves, be a large part and sometime the main part of the incentive to move to a paid offer.
   Typical differentiations include the support channel (for instance paid customers can receive live chat or phone service while free customers only get email support) and the speed of answers, with paid customers being guaranteed a response within hours while free customers may wait for days.
3. Provide assisted service only to paid customers. The extreme version of the strategy above is to provide no assisted support to free customers, only self-service. In this situation self-service options are often lavish, with online troubleshooting and customer forums, but there’s no way that free customers can get individualized attention. The problem with this approach is that free customers never get a taste of how good the service can be if only they upgraded to a paid option (but then again the same can be said of the differentiated option above, where the quality of free service can be quite low.)

How do you choose between the three options? It’s really a strategic choice that must be done at the executive level and match the model for acquiring customers. And as always the decision can change over time, usually moving away from free assisted support.

Free Training with Support?

A well-educated customer is a better support user: more accurate problem descriptions, fewer problems to begin with, no more lengthy phone tutorials, a better chance that recommendations will actually be carried out correctly…  With that, some support organizations are including “free” training with their offerings. Here are some possibilities. Try them!

• provide self-service training on the support web site.
  Idea: provide short videos of training modules that can be played from the support web site. The videos can be taped on a relatively low budget and the quality doesn’t need to be very high for short footage, and you can repurpose existing videos such as webinars. They can be free for all users or reserved to holders of support contracts.
  Pros: relatively inexpensive for short videos or repurposed footage; very helpful for short topics (e.g. how to change a printer cartridge; how to set options); always available to customers; low effort and low cost for the customer.
  Cons: not practical for complex training; requires a good search function if you have many; could create conflicts with the training organization (although you could create short videos that do double-duty as advertising for longer courses)

• hold regular webinars on popular topics
  Idea: support staff (or others, if you can coax them to do it!) lead webinars on specific topics. They can be up to an hour in length and include a question and answer period
  Pros: relatively low-cost, especially if you can offload common questions that would otherwise require 1-1 assistance; support engineers will appreciate the variety, at least some of them will; low cost for customers; can be repurposed into self-serve videos
  Cons: requires some amount of infrastructure (registration, online system); more staff-intensive than self-serve; complex topics cannot be covered in an hour; requires a minimum number of customers to be worthwhile; some customers will not want to wait for a scheduled webinar

• include space-available training with the support contract, at no charge
  Idea: as long as space is available in regular training classes, why not allow customers to attend at no charge?
  Pros: great for in-depth training; uses training seats that would otherwise go to waste; may encourage customers to attend classes on a fee basis; makes the support offer more attractive
  Cons: it may make it difficult to sell training classes at the regular price; customers still have to travel to the training class and pay for the travel expenses; because the training is on a space-available basis it makes it hard for them to plan their time and they have to wait for months for a seat

• offer free reserved seats for training events with the support contract
  Idea: include a number of reserved seats in the support contract; the seats must be used within the year
  Pros: good for in-depth training; a wonderful addition to the support offer; customers appreciate being able to hold a reserved seat
  Cons: requires an arrangement with the support organization that will involve money transfers and some kind of tracking system; the training organization may oppose the scheme if there’s no appropriate compensation; customers may fail to show up since they are not paying for the training (hint: impose a no-show penalty like you would for paying customers, through which they forfeit their free days)

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.

But what do customers want?

A critical ingredient in creating and rolling out support offerings is customer input: what are the features that make a difference? what do customers value and will pay for? what’s missing? Extensive customer surveys take time and significant resources, neither of which may be abundant. But you can start with what you have: your customer satisfaction survey.

You have to go beyond the number and actually read the comments. It’s easier than you think: I just went through several months‘ worth of comments for a customer project and although the file was dauntingly thick it did not take more than a couple of hours to read them all. What did we find? That customers really want attention: they want a phone call rather than a volley of emails; they want regular status checks; they want clear and frank conversations when bugs won’t get fixed. (This was a high-complexity support organization where cases routinely require days or weeks to resolve.)

So what we learned in this instance is that the best investment was soft skills training — and that’s just what we’ll do. It turns out to be a lot cheaper than the extensive technical skills re-training the customer suspected would be required and a lot easier than having to roll out brand-new support offerings.

An unexpected bonus of reading the comments is that many are positive! We all need a pat on the back from time to time…

Revisiting the idea of fixed prices for support

We’ve talked about fixed pricing before on this blog (here and here), mostly as an alternative to the common practice of pricing support as a percentage of the base license fee, a standard approach in the high end. Although I’m not necessarily a fan of fixed pricing because I’m concerned that it may create some missed opportunities in the high end one area where fixed pricing may be particularly strong is in resisting discounts. As we know customers often obtain very significant discounts on software licenses. If you compute your support prices from the license price, a generous license discount will translate into an even more generous support discount (assuming that you calculate pricing from the discounted price.) So starting with a fixed price may help you avoid runaway support discounts.

Does premium support require an assigned support engineer?

The idea of assigning a support engineer to an account is simple and attractive: instead of working with a randomly-assigned person with each new case, the customer can count on working with the same person each time (or close to each time, as even assigned support engineers take time off.) The assigned support engineer gets to know the customer well, which speeds up resolution, and can often provide proactive advice on configuration and the like.

Experience shows that the idea of having an assigned support engineer is very attractive to customers and customers who purchase a plan that includes an assigned support engineer typically renew in higher percentages than customers with a standard support plan.

Before you rush to implementing such plans, however, think about how you will staff for it. If you have a particularly wide portfolio of offerings, will you be able to located someone, anyone, with knowledge of all the products a particular customer may be running? It’s always possible to assign someone who knows the main products the customer is running and can get help on the others but that can get awkward (and defeats the goal of fast resolution.) The other issue is more subtle: what if the customer has a large number of issues at once? Will resolution be hampered by the diktat to work with that one support engineer? With a regular customer you would simply parcel out the cases amongst several engineers but that would be more delicate under an assigned support engineer program.

I’m seeing companies experiment with small “account teams” instead where customers can work with a handful of individuals, which may deliver the best of both worlds: personalized service and flexible scheduling and specialization. Maybe that would work for you?