The FT Word – February 2009

By Technical Support

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 to the February 2009 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription here.)

This month’s topics:

  • Metrics fest: what’s the best way to measure productivity? Quality?
  • Maximizing customer retention: while we can’t do much to acquire new customers, perhaps we can make sure the ones we have stay?
  • An accelerated version of Marketing WiseSM at the upcoming SSPA conference – and lots of other FT Works in the News updates

Metrics Fest

Many thanks to Doug Olson, Gary Piwowarczyk, and several others for suggesting this topic.

Metrics and in particular metrics that are tied to performance management are a perennial topic of interest for newsletter readers. Keep the questions coming!

1. Measure liberally but pick rewards-related metrics carefully

There is no end of metrics that can be captured via a properly set up support-tracking system and that’s wonderful! So if you want to know how many Latvian customers had questions about release last month, you can find out – perhaps not easily or quickly, but you can find out. That does not mean that it’s a meaningful metric. Moreover, if you suddenly decide to give bonuses to the support staffers who answered the most Latvian questions about you will undoubtedly notice a suspicious rise in such cases.

So you need to be considerably more clever when implementing performance metrics than when simply asking ad-hoc questions.

2. There is no one metric that captures everything

Any attempt to measure performance with just one number is doomed because it can be gamed. The classic example is to measure performance via the number of cases closed (or, worse, cases “handled”.) Can you feel the overwhelming temptation for the support engineers to grab the easy cases off the queue? To liberally “clone” a single case into many caselets? Worse, to cut off long cases and spawn new ones? To avoid quiet shifts like overnight or weekends?

Alright, you say, productivity is obviously bad. What about customer satisfaction? Similar tactics can be applied to maximize customer satisfaction. Start by avoiding hard cases like the plague (it’s often easy to tell when they come in.) Avoid difficult customers (they are well known in low-volume, high complexity support organizations!) Make sure to transition any case that feels un-perfect to someone else. On the other hand, heavily encourage happy customers the necessity to fill out the evaluation form. Yes, even good support engineers play these games.

The one-metric utopia comes, I think, from thinking about Sales where meeting quota is everything. But think about it: don’t you wish sometimes there be a “quality” metric for sales?

3. Group metrics or individual metrics?

Many support staffers, including managers, are allergic to individual metrics, with the valid concern that individual metrics kill teamwork. It’s true that unbridled competition kills teamwork (why do you think sales reps have a territory or work from a list of accounts?) However, if you believe that group metrics are fair, I advise you to speak to any 7th grader working on a group project (I have my own, private adviser on this.)

If you are concerned with teamwork, you can take two approaches. One is to specifically add group metrics to the individual metrics, so for instance, make 90% of the productivity measurement based on individual achievement and 10% based on group performance. Or you can root out potential competitive abuses. For instance, specifically ban “cherry-picking” off the queue. And naturally you can do both.

4. Productivity: customers, cases, or what?

When forecasting overall staffing levels you can (and should) forecast based on the customer base, aiming for an ever-decreasing support engineer to customer ratio. A May 2008 SSPA report noted an industry average of 19.5 customers per TSE, but please ignore the ratio and use your own, as the ranges are enormous.

When defining individual productivity goals, using customers per support engineer doesn’t work since support engineers rarely support a set number of customers on their own, and even if they did all customers are not born equal. Instead, use cases. Here again complexity varies greatly but over the long haul it will even out, as long as the support engineers are all pulling from the same pool of cases.

I strongly prefer counting solved (closed) cases and not cases handled, since it’s o so easy to “handle” a case ever so lightly to increase one’s number while adding absolutely no value from the customer’s perspective.

5. Customers are the arbiters of quality

Balance out productivity with quality, ideally with the results of a case-based customer satisfaction survey. There are many tricks to creating a valid survey but suffice it to say that you should keep it very short and aim for a response rate above 15%.

If it’s not practical to use a customer satisfaction survey, and by not practical I mean that customers won’t do it, not that you will need to work to run it, then use a quality monitoring program instead. Make sure that you have a large enough sample of cases from each individual if you take the quality monitoring route: no less than 5% of cases and more if needed to reach a reasonable total for each individual (I suggest at least 10 per quarter.)

6. Let’s not forget knowledge management…

Cases closed and the customer satisfaction rating work well for the case work side of the house but what about knowledge management? The advice needs to be a lot more nuanced here because it depends on the shape of the knowledge base as well as your knowledge management model. If you are supporting a very staid product for which the knowledge base is pretty much established, improving the knowledge base will mean refining existing solutions, merging similar ones, and removing obsolete solutions. On the other hand, if you are supporting a constantly changing product the effort must be focused on creating and improving. Also if you use KCS most support engineers will be engaged in creating solutions, but if you use a traditional expert model only a handful of support engineers will be creating.

Taking the assumption that you are working with an evolving product, if everyone can create solutions I suggest measuring links to the solutions created by the individual (ideally only citations, links made by others.) It’s wonderful to see how creating a few really good solutions can turn into a tool to resolve many cases.

If you have a strict review process (and you do not have a months-long review queue!) you can instead use a productivity and quality metric similar to what you use for cases. Clearly pure quotas are disastrous, as they encourage the staff to create lots of junk, but quotas plus the results of a review process are better balanced.

7. Nothing else?

You can certainly add other aspects. For instance meeting response times is a favorite (best done as a group goal unless your process for handling cases determines who meets response time.) Another good candidate is meeting resolution time targets – as long as you use a reasonable definition such as “resolve 80% of cases in less than a week”; don’t force 100% closure…

Remember that customer satisfaction rules: response and resolution targets matter little if the customers are not satisfied.

For more information about support metrics see Best Practices in Support Metrics.

Maximizing Customer Retention

Many thanks to Ram Ramadas for suggesting this topic.

Customer retention is critical for success: for one thing, departing customers take their money with them. They also may volunteer negative references, and as we know negative references are repeated more generously than positive ones. And replacing departing customers is costly, whether in pure acquisition dollars or in added support costs for implementation. So it’s important to hang on to customers. Here we consider what can be done from the support perspective to maximize customer retention.

1. Customers leave when they see a better alternative

Customers don’t stay just because they love support! Customers stay when they are reasonably satisfied with the product and do not have a better alternative. So if you happen to be the only provider of a particular product customers will stay with you because they have to and will do so despite poor service (think of your local utility: it’s a monopoly hence you have no choice) but if there’s a better game in town they will leave even if they are very happy with your service (this is what happens to mom and pop stores when a big box store comes to town.) Most vendors are somewhere in the middle of this spectrum: they have competition but there’s a cost to switching providers and whatever advantages the other providers may have are balanced by the cost of switching.

Certainly, all things being equal, customers are much less likely to switch when they love the service (note it has to be at the “love” level – simply liking the service doesn’t cut it.) This is what customer loyalty means: truly satisfied customers are much less likely to wander away – but again only if there is no obviously superior alternative.

2. Some customer defection may be a good thing

Some customers were mis-sold or changed their requirements since the sale and your product or service does not fit their needs. This includes customers who have unrealistic expectations for the product or for support. Assuming that your selling process is working well there should be very few customers with a bad fit – but those few customers can be shed without looking back, and some industry experts even suggest you can “fire” them.

Don’t go overboard with your firing: a customer who wants hot fixes for P1 issues is absolutely right and you should do everything you can to retain him or her; the customers who wants hot fixes on trivial bugs, or who are attempting to use a product designed for SMBs for a large enterprise application may not be worth retaining.

3. Deliver high-quality service

Although high-quality service in and of itself won’t prevent defections it’s still a necessary step to retention. So spiff up your delivery, go the extra mile, and inspire everyone on your team to do the same. This applies to all aspects of service from self-service to how customers engage with the support engineers to how the resolution process unfolds, to how you deliver fixes and upgrades.

4. Coddle the best customers

While you want to deliver good service across the board it’s particularly important to retain the best customers: the ones that contribute the most to revenue, be it support revenue or otherwise; the ones that participate in your reference program; or the ones that are beachhead accounts in a new geography or industry. These customers should be flagged in the support-tracking system and the staff should be instructed to treat them with extra care. You can also design a separate handling system for their cases.

Don’t go overboard: if every other customer is “special” the designation means nothing. Target the top 10% or so of customers.

5. Fix problems promptly and completely

Take action on complaints. Numerous studies have shown that customers are more loyal after a bad experience that was recovered well than if they had no bad experience in the first place. (This is not a good reason to create bad experiences in order to fix them!) On several occasions when I called a customer immediately upon receipt of a poor satisfaction survey I was able to make a new friend just because I had called so promptly (and promised to fix a few things too, but responsiveness scores big.)

6. Listen for signs of defection

The support team is in a unique position to partner with customers. Often customers will confide in support engineers that they are evaluating other products, or they are planning to start new projects with another product. Find a way to communicate this information to the account management team or the product marketing team if the trends are more general.

7. Sweat renewals

Support renewals are a prime opportunity to connect with customers but many vendors seem to approach them with all the warmth of overworked accountants (sorry, accountants: you’re all very kind when not overworked.) How about treating renewals as what they are: a piece of the account management puzzle. Start by asking for feedback; build a little rapport; then send the bill.

8. Reach out

At least with larger customers (see #4) it’s a good idea to have a technical account management program through which you contact the customers on a regular basis to check that all is well and to provide information and recommendations to enhance their use of the product. You may be able to package such a service (and sell it) as part of the premium support offerings, or you may choose to deliver it for free. (And perhaps the service will be provided from the sales team.) Being able to touch base with customers on a regular basis will increase customers loyalty and allow you to detect and address issues before they become too large.

9. Collaborate

Support should not and cannot be the only ingredient for customer retention and chances are that other parts of the company are seeking ways to maximize customer retention as well. Rather than creating your own initiative consider joining forces. One of the perennial complaints from customers is that vendors are too siloed. Surprise them by acting as a team, for once.

FT Works in the News

Lots of updates this month:

  • I will be presenting a one-day course about support marketing right before the SSPA conference in Santa Clara, CA on Monday May 4th. Want to build a better support portfolio? Increase support pricing? Maximize renewals? Find out more here and register for the course or the conference.
  • I will be presenting a breakout session about ROI for communities at the conference (Tuesday 11:30) with Tarik Mahmoud of Cisco Consumer Business Group (CBG – Linksys). This is a great opportunity to both learn about creating a community ROI and hear Tarik describe the wonderful use they are making of communities.
  • Insight published an article I wrote about a popular topic these days, cost cutting: Cutting Costs – Without Cutting Customer Satisfaction. You can read it here . You can find out more about cutting costs in the 20 Ways to Cut Support Costs booklet from the Smarter Support LibrarySM. •
  • ASP will be once again holding its Ten Best Support Web Sites contest this year – and I will again serve as a judge. Entering the contest is a great and inexpensive way to get some impartial advice on your web site, and naturally the winners get bragging rights. To enter go here . The deadline for entry is March 6th. (more information here )
  • Finally check out the new posts at Marketing Wise, the FT Works support marketing blog:  Support pricing in a downturn (nice companion to the retention topic above); Support offerings for SaaS; Fixed pricing for support offerings

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.

Françoise Tourniaire
FT Works
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

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.

Back to Newsletter Archive

Tagged under: