The FT Word – January 2004

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.


Happy new year and welcome to the January 2004 issue of the FT Word. Please forward it to colleagues you think may enjoy it.

In this month’s issue, two topics:

·          supporting legacy products

·          metrics for tier 2 support staff


Supporting Legacy Products

Thank you to Bob Mahesh for suggesting this topic.

Do you have to support products that are no longer actively sold or enhanced? If they are quite old, you may find that it’s quite difficult to maintain a good level of knowledge among the staff, as experienced users take their knowledge with them when they move on. And even if you hire new staff members, they may be reluctant to get the training required. Here are 8 steps to sanity.

1. Is it really a legacy product?

If your so-called legacy product receives regular enhancements then it’s not really a legacy product, even if it’s not actively sold. A good test is to look at the bug incident rate for legacy products. A legacy product, since it’s very stable, should have a very low rate of defects, certainly less than 2-3% of cases. A product with a large bug ratio is not a legacy product and needs active support (and active Engineering support!)

2. Keep turnover low

If you can keep the staff members who know the legacy product, you don’t have to worry about training new ones. I just worked with a client who boasted staff with over *10* years’ seniority. It sure makes it easier to support older products.

A good strategy is to allow experienced support engineers to learn new skills and support new products, but continue to pitch in for cases on the legacy product. That way, no one needs to stay stuck with an older, less exciting product if they don’t want to.

3. Capture the knowledge

Even if you think your support staff will stay forever, it’s a good idea to capture their knowledge permanently into the knowledge base. At a minimum, resist the urge to purge older documents that refer to the legacy product: they could come in handy! And if the document set is light, set targets to fill the gap before your skilled staff leaves.

4. Leverage the Community

With an older product, you probably have a set of knowledgeable, loyal customers. Try using customer forums or similar techniques to leverage their knowledge. It will keep the pressure off your support team.

5. Keep Training New Staff

Keep a sharp eye on the pool of support engineers who are able to handle a legacy product. As soon as it shrinks below comfort, train replacements; do not wait until you’re down to a handful.

It may be difficult to recruit staff willing to work on older technology. Try approaching alumni who may be willing to come back or work part-time to fill the need. And offer to train new staff on other products to give them diversity and a growth path.

6. Plan and argue for special staffing allowances

If the skills required to support the legacy products are very different from what’s required for other products, you will need to maintain separate staffs. Run two separate staffing models including for extended support hours and vacations.

7. Consider Outsourcing

A legacy product may be a good candidate for outsourcing if the issues are well-known and well-documented. The problem is finding someone with the requisite skills if the technology is really old: COBOL programmers, anyone? Several clients report good success with overseas outsourcing of legacy products. It seems that support engineers in other locales are less picky about working on the latest and coolest technology.

8. Adapt the SLAs

Legacy products typically get no enhancements. That may require modifying your customer contract. Also, if volume is very low and expertise scant you may have to discontinue 24×7 support. Think of it before that 3am call. As an alternative, customers may be willing to pay higher support prices to hold on to the level of support they have enjoyed in the past.

9. Think about sunsetting

Eventually, legacy products should be sunsetted (“killed”, in less polite terms). My experience is that it’s very difficult to get Marketing’s attention for something as unglamorous as sunsetting a product, so you may have to do it yourself. It’s worth it for older products with small customer bases that cost you more than you can collect in support fees.

Start with making sure that you would indeed save money. I’ve been surprised in the past to find that older products, because they were stable and therefore generated very few support requests, were more profitable than newer products, even mainstream ones. Include both Engineering and Support costs in the calculations: porting old products to newer operating systems can be costly. Once you have a clear ROI, create migration paths for customers (very important!) and give them plenty of time to migrate. Customers can be very reluctant to move away from a stable product.

Metrics for Tier 2 Staff

Thank you to Mel Rosenberg for suggesting this topic.

What gets measured gets done. Although tier 2 staff is typically more senior and self-motivated, it makes sense to measure what they do, too. But how?

If your tier 2 staff takes escalated cases from tier 1 very much as tier 1 takes customer cases, then use similar metrics:

·          volume resolved

·          customer satisfaction ratings

·          response time achievement (group goal)

·          resolution time achievement (even if you’re not publishing resolution time goals to customers)

·          contribution to the knowledge base, as measured by *published* documents

Of course, targets would be different. A tier 2 case is by definition more complex than a tier 1 case, so a tier 2 staffer may resolve only 10-30% as many cases as a tier 1 staffer. It’s normal.

If your tier 2 staff instead works on a consultative basis, helping tier 1 staff resolve issues without actually owning cases, goal-setting and metrics are more challenging. Here are some thoughts:

·         Find a way to keep track of cases the tier 2 staffer consults on. A subcase is good for that, if your system supports them. Otherwise, see if the transaction log tracks who touches various cases.

·         With that in place, you can measure volume. The effort required for tier 2 cases is highly but over the long run things even out.

·        You can also measure customer satisfaction on those cases the staffer helped with. Of course, much of the rating will be derived from the tier 1 owner, but good help should also make a difference. If you use this, pick a target that’s lower than a tier 1 satisfaction target: difficult cases rate lower.

·         Consider using an internal survey for measuring quality. This is a touchy topic since co-workers typically feel uncomfortable rating each other, but how else can you find out who’s approachable and who is not? To make it work, devise a bullet-proof way to keep results confidential, perhaps by having an outside group administer the survey. Contributions to the knowledge base, both articles written and reviewed, as well as the speed of review.

More metrics ideas can be found in the booklet “ Best Practices for Support Metrics.”


FT Works in the News

SSPAnews published an article I wrote entitled The Efficient Interviewer A Primer SSPAnews 12/16/03

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