The FT Word – February 2006

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

Welcome to the February 2006 issue of the FT Word. Please forward it to a colleague!

Topics for this month:

· backlog metrics

· implementing new offerings into an existing customer base

· Collective Wisdom is out! For everything you always wanted to know about knowledge management, click here.

Backlog Metrics

Thanks for Josh Baxter for suggesting this topic.

How old is too old? How should we measure our backlog and what’s a good target for it?

We all have the intuition that cases do not get better with age. Indeed, if we can swiftly diagnose a customer’s problem and provide a solution, chances are that the customer will be satisfied with the performance of the support organization. Unfortunately, it’s not always possible to provide solutions quickly, for a variety of reasons:

· we are ill-equipped to deal with the overall volume of cases

· we don’t have a good system to swiftly respond to inquiries

· we allow cases to languish unchecked

· we have poor diagnostic tools built into the products

· the specific issue requires an Engineering fix, and that takes time

Before we look for solutions, what’s a good way to measure backlog? My recommendation is to look at the backlog in comparison to incoming load, expressing the result in time. In other words, if you normally get 40 cases per day and you have 400 cases in the backlog, that would be 10 days worth of backlog (rather a lot). If you normally get 400 cases per day and you have 400 cases in backlog you have 1 day’s worth of backlog (a wonderfully low number.) The advantage of comparing the backlog to incoming is that you automatically compensate for volume variations over time. Note that, since incoming cases have a mix of difficulties while the cases in the backlog are, on average, more difficult (otherwise they would be resolved already!) this measurement underestimates the effort required to resolve all the cases in the backlog. But that’s ok: it’s a metric not a project plan.

So what’s a good goal for backlog? It depends on the complexity of the products you support. If you support low-complexity products, you should not have more than a couple of days of backlog. Since cases are simple, they simply should not sit for long. On the other hand, if you support high-complexity products, a couple of weeks of backlog would not be inappropriate.

If you’d like to further analyze the backlog, you can look at the age of the cases in the backlog but I would not rely only on the age as a reliable measure. After all, if you had only one case open, but open for a year, average age would be awful, but it’s a lot better than a sea of month-old cases. Look at age only after you look at volume.

And one final word: don’t fiddle with the definition of backlog. If the customer got an answer, but asked for the case to remain open for “testing”, the case is open. If the case is waiting for an Engineering fix and unless the customer has agreed to closure, it’s open.

Implementing New Support Offerings into an Established Customer Base

Thanks to the anonymous reader of the newsletter who suggested this topic.

If you are introducing new support programs, what to do with the existing customers? This is particularly tricky if you are introducing the new offerings to control support costs so you may be in a position to downgrade the level of support customers currently enjoy.

Plan for existing customers as you develop the new program

If you have a handful of customers, it’s fine to focus on new customers as you define the new support offerings, leaving the transition to be done manually after the fact. If you have a large customer base, and especially if you have a lot of long-term customers, consider their needs and requirements as you create the new program. If you can design one or several of the new offerings to approximate the existing ones, it will be easy to transition existing customers to the new program.

Check existing contract commitments

If you promised customers in writing to provide 24×7 support, or expedited response times, you have to deliver against your commitments– or renegotiate. Experience shows that many contracts are quite vague about specific deliverables, so you should be able to change established practice.

Consider grandfathering existing customers – or not

The apparently easy way out with existing customers is to simply grandfather them: allow them to keep the very same level of support they have enjoyed. While this makes for a smooth transition for customers, it may not be what you want. For instance, you may be over-delivering on commitments, and continuing on the same model makes little sense (and only makes a change more difficult.) The other problem with grandfathering is that it can make for a very large number of different offerings, which are hard to track properly.

Grandfathering can make sense if you have reasonable offerings in place, but don’t jump to it automatically.

Plan a good information campaign

Existing customers must understand the logic and features of the new offerings as well as how they will be served in the future. Anticipate likely questions and provide answers proactively.

Roll out new programs at renewal time

There’s no reason to roll out the new offerings at an arbitrary date for all customers. Rolling out at renewal time gives you more time to renegotiate when needed. Show customers their options: the basic level of support and also the higher levels. Some customers will choose the higher levels of offerings even if it means a higher price.

Implement price changes gradually

If the program switch results in high increases for some customers, implement the increases gradually to build goodwill and minimize tough negotiations. A good approach is to show the customer the new price, but to offer a discount to a reasonable level (no more than a 20% increase), building up each year until you get to the new level.

FT Works in the News

Collective Wisdom: Transforming Support through Knowledge, or everything you always wanted to know about managing knowledge in support centers, is officially out and I’m expecting the first boxes from the printer’s this month. For more information and to order your very own copy, click here. Many thanks for the many readers who contributed ideas for the book.

SSPA News published an article I wrote entitled The Six Big Trends for 2006. You can read it at http://www.thesspa.com/sspanews/january06/article5.asp.

(And thanks to readers for putting not one but two of my articles on the “top 10” list for 2005, at #2 and #7: http://www.thesspa.com/sspanews/December05/article1.asp#top10)

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.

Back to Newsletter Archive

Tagged under: