April 26, 2010
I’m delighted to announce the publication of Selling Value, the complete guide to designing, marketing and selling support packages — in other words, a compilation of this blog, with over a dozen case studies to inspire you to augment and improve your current support portfolio. The book is written with a light-hearted tone and a format that makes it easy to zero in on just the topics you need.
You can buy it here.
September 28, 2009
Now don’t get me wrong: I love pretty brochures — but surely there’s more to support marketing than glossy datasheets! Support marketing, to me, covers the entire business development side of support: analyzing the customer base, creating support offerings and organizing them into a coherent portfolio, pricing, marketing (ok, here come the pretty brochures), training the sales force, handling objections, managing discounts and changes to terms and conditions, and of course renewing.
Which means that if you put a brochure-writer in charge of support marketing it simply will not work.
[end of rant]
September 25, 2009
ASP, the Association for Support Professionals, just published its annual survey of support revenue. ASP reviewed the financial reports of 100 public software companies in August and found that services as a whole (support, consulting, training) provided more than half (56.9%) of total company revenues, across the board. And this is good, profitable revenue since margins are close to 60% (56.8%), with both revenue and margin percentages up since last year.
If we just look at support the survey found that it constitutes a very respectable 38.9% of total revenue with a remarkable margin of over 83.2%, so much higher than for other services such as consulting and training.
If you find that your executive team still looks down on support as an afterthought or worse, perhaps sharing these numbers would help?
For more information about the survey go here.
September 24, 2009
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.
August 31, 2009
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.
August 18, 2009
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.
July 31, 2009
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!