The FT Word – August 2008

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

This month’s topics:

  • The Net Promoter Score – what does it mean for Support?
  • Integrating the Knowledge Base and the CRM System
  • Trends in Fee-Based Support – a new ASP report with a contribution from FT Works

The Net Promoter Score – What does it mean for Support?

Thanks to Shailendra Jadhav for suggesting this topic.

What is it?

The Net Promoter Score was introduced by Frederick Reichheld in a now famous 2003 Harvard Business Review article entitled The One Number You Need to Grow (2003.) His claim was that, by simply asking customers their likelihood to recommend the company or product to others, and by counting the so-called Promoters (who are highly likely to recommend), subtracting the Detractors (who are highly unlikely to recommend), and leaving out the so-called Passives in the middle, one could get a strong predictor of the financial success of the company.

The Net Promoter Score or NPS, widely appealing both because it makes intuitive sense and because it’s so simple, has been adopted by many companies large and small – and has also been subjected to criticism pointing out that it may not be as reliable as touted. (Quite a shock, for all of us cynics, to learn that one number may not actually predict everything…) It’s also been reused, adapted, and mangled so that many users don’t quite remember what it means or even how to compute it, just that’s it’s the one number that matters.

How is it used in support?

A number of support organizations have adopted the NPS as their customer satisfaction quality measurement, computing it from the result of a question such as, “Would you recommend XYZ Support to others?” (pretty much the original question Reichheld asked.) Others simply ask the standard, “What’s your overall satisfaction level with Support?” (so a customer satisfaction question, not a referral or loyalty question) and use the NPS technique to compute their score, typically subtracting the percentage of responders in the 0-6 range (detractors) from the percentage of responders in the 9-10 range (promoters). The Passives, those with a 7 or 8 rating, are excluded from the computation. So for instance if 40% of customers rate 9 or 10, 5% rate 6 or lower (and 55% rate 7 or 8), the NPS would be 40 – 5 = 35.

Note that the 0-10 scale is an integral part of the NPS concept, subject to much debate amongst its detractors.

What’s useful about NPS?

Recall that NPS was originally designed as an advance indicator of a company’s ability to grow. So at least in theory, and ignoring the critics of the approach, using NPS in a support context would also allow us to predict future support revenue. In reality, because support revenue is tightly constrained by the products or services being supported, I’m skeptical that NPS scores can work in the manner advertised for support loyalty scores.

What I do like about the NPS concept is the idea that “good” customer satisfaction is pretty meaningless, that we must target the “excellent” levels of customer satisfaction. It also seems very reasonable that customers who give us mediocre ratings are in need of attention.

So what’s the benefit of using an NPS approach compared to a standard average rating of customer satisfaction? In my experience, moving from a customer satisfaction target measured as an average to one measured NPS-style sharply focuses everyone on both avoiding the low scores and going for those very high scores. Avoiding low scores is a wonderful thing (and actually if you think about it the best way to improve an average is also to get rid of the low scores – it’s just harder for laypeople to realize it.) I personally find the quest of the 9’s and 10’s exhilarating, but beware of nasty side effects: it could lead to cherry-picking, dumping, or the old favorite: arranging that grumpy customers never get the survey!

Many support organizations will choose to stay with an average metric because it’s easy to compute and easy to explain and that’s just fine. If you do, take the time to explain to the team how the very low scores impact the average (and, to a lesser extent, the very high ones). You will end up with pretty much the same outcome as with the NPS.

Last note: the numbers for averages and NPS cannot be compared easily. You could be running at a 8 average, say, but a 50 NPS (actually a 50 NPS would be very good for a support organization.) And movements up and down the scale are also quite different. Before you brag to others about your customer satisfaction ratings, make sure you’re using the same computational method.

Let me know: are you using NPS-style computations and how is that going for you?

Integrating the Knowledge Base and the CRM System

Thanks for Barry Waters for suggesting this topic.

Feeling hemmed in by your CRM’s built-in knowledge management capabilities, you decided to splurge for a “real” knowledge management system and inevitably you now want to integrate the two. How far should you go? What are the must-haves for the integration?

Consider the lifecycle of a support case

A question comes in and the support staffer’s first instinct, assuming the topic is not already familiar, is to check the knowledge base. This is your first potential integration point: automatically querying the knowledge base using the information that’s already entered into the case such as the case description and the basic environment description. Now imagine the search is successful: to help the customer navigate to the solution let’s link it to the case: second opportunity for integration. And if the search was not successful giving the support staffer a mechanism to create a solution based on the facts of the case helps productivity: third opportunity for integration.

If you are in the situation where support staffers are using both systems sans integration, observe a few of them for an hour or so: it will quickly become clear what types of integration would help them the most. (I’m a great fan of observing users rather than making them describe what they want – their fingers tell a more accurate story than their mouths.)

Consider customers’ needs

Many knowledge management purchases come about because of a desire to increase self-service and case deflection. So what integrations should be considered from a self-service perspective? One idea is to perform an automatic search of the knowledge base when the customer creates a new case: if a palatable answer is found the case can be closed on the spot (or never opened in the first place.) And naturally the idea of linking cases and solutions is a help to customers, both while the case is open and later on, as a reference.

Automatic (or manual?) search on case description

The idea of conducting automatic searches based on case description applies equally well to self-service and assisted service. The standard approach is to feed the case description to the search engine. As you can imagine, this works quite well if the description is solid, not so well if the description is a laconic “error”… And, perhaps counter-intuitively searches don’t work very well with long, convoluted descriptions, and especially if you insist on matching other case elements to solutions such as a product version number. So what should you do?

For self-service searches, where you have little control over customers’ entries, consider using only the case description (and no other attributes) for the search. Allow customers to refine the search. (And avoid forcing customers, especially paying customers, to search before logging a case. It’s frustrating for savvy users.)

For searches by support staffers, you must let them refine the search. For a very low-cost approach, simply providing a one-click access to the search page from the case screen is a start.

Linking cases and solutions

Linking cases and solutions is handy while working cases but its main benefit may come after case closure: links help gauge the usefulness of individual solutions. In theory, a solution with multiple links is one that’s more useful than others. (You must have a process for auditing links, otherwise it’s likely that some will be made in error and others in response to silly policies such as “every case must have at least one link”, which has the expected effect of creating lots of links, not all of them legitimate.)

Allow cases to be linked to multiple solutions. As long as the links are audited there’s no reason to restrict cases to just one solution.

Creating solutions from a case

There are two options here: one is to scoop up the case notes into a draft solution for scrubbing and editing; the other is to allow the support staffers to create solutions in the knowledge base as they work on the case, essentially using the knowledge management tool as a note-taking environment for portion of the case to be retained. In an ideal world, the second option of a fully integrated screen where the CRM portion is displayed alongside the knowledge management portion is a wonderful productivity tool. As a more affordable alternative, a way to capture notes and other attributes for scrubbing is very useful. You can see how a high-volume support center with lots of new issues would particularly welcome the completely integrated approach while a support center that treats mostly repeat issues, or one with low volume, could make do with the “scoop and scrub” approach.

Integrating to measure knowledge management success

Clearly the benefits of integrating the CRM and the KM tool translate into higher productivity for the support staff: instead of having to switch between two systems, it’s faster and less error-prone to navigate them seamlessly. (Don’t get too excited, though: the productivity increase due to the integration itself is unlikely to be more than a couple percentage points, much lower than the introduction of a better KM tool.)

Can the integration lead to better metrics: yes when it comes to contrasting the effectiveness of various solutions through the case-solution links. As for measuring case deflection, it’s more complicated: how does one measure what did not happen? Certainly if you perform an automatic search as customers log cases you can capture customers who search but don’t log cases, but it would neglect customers who searched without attempting to log a case at all (more deflection), as well as customers who picked up the phone so they would not be subjected to the automatic search (less deflection). Case deflection is best accomplished by looking at more holistic numbers such as incident rates.

FT Works in the News

The Association of Support Professionals published a new report entitled Trends in Fee-Based Support, which contains two write-ups I contributed on the topic of collecting customer feedback and migrating from free to fee-based support. You can find more support marketing write-ups on my support marketing blog, Marketing Wise.

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

Back to Newsletter Archive

Tagged under: