The FT Word – February 2007
The FT Word
The FT Word is a free monthly newsletter with support management tips. To subscribe, send us email with your email address. The subscription list is absolutely confidential; we never sell, rent, or give information about our subscribers. Here’s a sample.
Welcome
Welcome to the February 2007 issue of the FT Word. Please forward it to your colleagues who are interested in support issues. Subscription information is at the end.
Topics for this month:
- building a coherent support portfolio
- appropriate metrics for level 2 or backline support
- a new FT Works workshop at the SSPA conference in San Diego
Building a Coherent Support Portfolio
Thank you to Bob Kindel for suggesting this topic.
So you have done your homework and created some good support offerings. How do you know that you have a good portfolio, that the offerings fit well together and make sense to customers?
1) Does each offer in the portfolio (each support package) make sense for a particular segment of your customer base?
For instance, it’s great to offer a super-premium option with an onsite dedicated support rep, but if your customers think that $10k is just about the maximum they would pay for support, it won’t fly. Generally speaking, any package that has failed to attract any customers for a reasonable period of time is suspect.
2) Is the number of packages reasonable?
Having too many packages is common in larger companies as well as companies that grew through acquisitions. Lots of people create support offerings and none is ever taken off the list! Customer studies show plainly that having many alternatives delays and sometimes blocks the decision process, and makes for a less satisfied customer. It’s true for jam (the original study) and it’s true for support packages.
A common reason for having lots of packages is that there are many options that are prepackaged under different names. In this situation it’s usually best to stick with a handful for base packages (say, 3-7) and then allow options to be added. Think of an ice cream parlor: you choose the flavor and then you choose a topping. You pay a set price for each size with an extra charge for the topping. The pricing is simple and easily understood. (But of course you should not offer 31 flavors of support!)
3) Are the support packages well differentiated from each other?
You should be able to describe the difference between package A and package B in one short phrase. For instance: A provides business-hours support, B provides 24×7 support. If you can’t describe the differences succinctly, chances are that the sales reps can’t, and therefore customers will be confused (and will likely buy the lowest-level package, since they cannot understand the reason for the premium price.)
4) Is one offering “killing” another?
A good way (but not the only way) to structure support portfolio is with so-called Russian-Doll packages that build on top of each other. In this situation, beware of overwhelmingly attractive features that pretty much remove all attractiveness from the packages lower down the line. For instance, if you support enterprise customers and your basic package is self-service only, chances are you won’t well many of it since customers want to be able to contact support. In this situation, I would argue you can remove that lower-level package entirely.
5) Does pricing match the perceived differences in features?
If business-hours support cost $2k and 24×7 support costs $20k, customers will balk. A similar issue occurs if support for product A costs 15% of the license and support for product B costs 30% of the license
Eliminate pricing inconsistencies and find clever ways of working around required gaps. For instance, in the second example of product A and product B, the pricing difference could be absolutely appropriate if B is a low-cost product that requires loads of support. One way around that is to use a different name for support of product B.
6) Does the sales channel know how to position and sell the portfolio?
A common reason for a particular support package’s failing to attract any customers is that the sales team never presents it to prospects! It may be that the support package is ill-designed to begin with (see all the points above) but it could also be that the sales reps just don’t feel comfortable presenting its benefits. Make their job easy! Create selling materials, be they online, a glossy handout, or a PowerPoint presentation, depending on how your support is sold. Train the sales team to match prospects to likely packages and to present the benefits of each package.
Remember that most sales reps are comfortable selling the product but less comfortable selling services, so give them that extra assist.
And don’t forget the killer question: is the sales team appropriately compensated for selling support? This is particular important if you have little control over the sales team, perhaps because you are using a distributor or other sales channel.
For more information about creating support offerings, see Managing Support Strategically and 10 Commandments for Support Pricing.
(And I’m thinking of writing a full-length book on the topic of support marketing. If you have suggestions or encouragements, please drop me a note)
Metrics for Backline Teams
Thank you to Pankaj Bhardwaj for suggesting this topic.
I would argue that metrics for Frontline or level 1 teams are pretty well understood: mix some productivity measure such as the number of cases closed or handled with some measure of quality such as the results of the customer satisfaction survey. Add a dash of internal productivity such as knowledge management contributions or professional development, and you’re in business.
But what about Backline (or level 2) teams, who help Frontline by answering their questions but don’t necessarily own cases, or not many compared to the overall quantity of work they do?
1) If Backline reps simply handle cases escalated from Frontline, measure them as you would Frontline.
Yes, their cases are more complex but they are still cases and can be measured the same way. Measure productivity and customer satisfaction – but don’t expect they would ever match Frontline’s number, certainly not for productivity (it will be much lower) and even for customer satisfaction, which is likely to be lower since the problems are more complex and take longer to resolve.
2) Try to measure assists.
If Frontline’s requests for assistance are logged into the system (maybe through a chat request, or a subcase) then you can capture them in your metrics and you can measure Backline on the basis of its productivity.
If you’re not currently tracking assistance requests, you must decide whether to implement a tracking process, which will take time and effort not just to implement but to use in the long term. If each assistance request takes a while (i.e., it’s not the 2-second “Is patch 123 out yet?” variety), tracking is probably worthwhile. The benefit is that not only can you track productivity, which is wonderful in itself, but you can also link Backline’s performance to the outcome of the cases themselves. Read on…
3) Capture their customers’ satisfaction.
This is where point #2 above becomes really useful: if I know that Joe helped on cases 5, 8, and 13, I can then use the customer satisfaction ratings for cases 5, 8, and 13 to measure Joe’s performance. Granted, the ratings are very much influenced by the Frontline staffers who handled cases 5, 8, and 13, but over the long run Joe’s impact on how the cases were resolved would be felt in the ratings.
If you cannot link cases to the Backline reps, or you do not have a customer satisfaction survey, try surveying the Frontline staff instead. It’s often tricky to get candid evaluations of intra-company performance, so that would be a second choice.
4) Capture Backline’s non-support activities.
Backline reps are often asked to perform all kinds of other activities, from leading workshops to testing new releases. Their goals and objectives should include these other activities in the proportion of the time they are expected to devote to them.
FT Works in the News
For the third (or is it fourth?) year in a row I will be a judge for the ASP’s Ten Best Support Sites competition. Entries are due 3/1/07. Each participant receives a detailed report (full of pithy comments by people like me) on how to improve their web site. A great deal for $185 (and no, judges are not paid so this is a disinterested recommendation!) More details at http://www.asponline.com/awards.html.
The SSPA has announced its lineup for training days at the upcoming San Diego Conference and I will be speaking about “Paying for KM: Building Honest ROIs that stand the Test of Time”. Please join me! Information at http://www.thesspa.com/conferences/sandiego/training_day.asp. (And please send me your ideas for what you would like to hear during that day of training!)
Curious about something? Send me your suggestions for topics and your name will appear in future newsletters. I’m thinking of doing a compilation of “tips and tricks about support metrics” in the coming months so if you have favorites, horror stories, or questions about metrics, please don’t be shy.
Regards,
Françoise Tourniaire
FT Works
www.ftworks.com
650 559 9826
About FT Works
FT Works helps technology companies create and improve their support operations. Areas of expertise include designing support offerings, creating hiring plans to recruit the right people quickly, training support staff to deliver effective support, defining and implementing support processes, selecting support tools, designing effective metrics, and support center audits. See more details at www.ftworks.com.
Subscription Information
To request a subscription, please drop us a note. The mailing list is confidential and is never shared with anyone, for any reason. To unsubscribe, click here.
You may reproduce items in this newsletter as long as you clearly display this entire copyright notice. Contact us if you have questions about republications.
