The FT Word - August 2002

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 August 2002 edition of the FT Word.

In this month's issue, a nice mix of a strategic topic and a hands-on operational topic:

· local versus global support organizations

· using case types

Local versus Global Support Organizations

Should you strive for a global support organization, or is a local approach better? Can you mix the two? What factors are important when making the decision? Read on...

Let's start with the benefits of global organizations:

· they are more efficient: instead of reinventing the wheel in each geography, it's possible to leverage tools and processes across the board.

· they deliver consistent service worldwide (well, more than local organizations, that is). This is often a requirement of global customers who wish to purchase support, define SLAs, and receive consistent service throughout the world

Local organizations, on the other hand:

· do a better job of delivering customized service by being more attentive to the local culture, customs, and requirements.

· can implement changes faster because they are smaller and more nimble

So what should you do? Well, it depends..

1) If you have global customers, consistent product offerings worldwide, and a centralized organization in the rest of the company, a centralized approach is best. Share all the infrastructure including support offerings, tools, and processes. Even with a centralized approach, make sure to create strong relationships with the local teams and especially the sales force.

2) If you have both global and local pressures, consider a federated approach where the support organizations in the various geographies operate independently but share tools and processes. This can take the form of a "parent-led" organization, where the main (typically the oldest) support center creates most of the new programs and initiatives, or it can look more like a "peer-driven" where the various support centers cooperate on tools and processes and contribute to the development and sharing of best practices.

I prefer to implement the federated approach with a centralized organization (everyone reporting to the Worldwide VP of Support) and strong matrix reporting/cooperating to local management than the other way round.

3) If your markets are heterogeneous, with each area marketing different products to different customer bases, a completely local approach is probably the best. Even if you choose to do so, however, it's best to join forces on large investments including the support tools. I can think of very few situations where this approach would make sense, however, since there are typically many similarities across geographies.

Using Case Types

Thanks to Herb Rosenberg for suggesting this topic.

Many support-tracking tools include the concept of a case type, which is an attribute of cases that captures a high-level category for the case. Except for very simple systems, case types are populated via a pulldown menu, the values of which are completely customizable. And more often that not the tool allows the concept of a subtype associated to each case type for further refinement.

So what are case types good for?

1) Case types can be used for routing cases, either initially or in an escalation scenario. Here's an example of using case types used for initial routing. Using the following case types:

· customer service

· installation

· usage question

· performance

one can route the case to the support staffer with the proper expertise.

Here's an example of an escalation routing. Using the following case types:

· bug

· enhancement request

· documentation bug

· training bug

one can route the case to the proper organization outside support for additional processing.

2) On the other hand, case types can be used to drive case metrics such as

· what kinds of issues are we getting?

· are any types of issues becoming more or less popular?

· where should we target our efforts?

· how should we schedule staff to meet demand?

It's not unusual to use case types both for routing and metrics, of course.

So what are "good" case types?

1) They are used for a useful purpose, whether routing or metrics. If you are not currently using case types and don't feel a need to start using them, by all means remove them from the interface (or hide them).

2) They must be easy to enter and create minimal overhead for the support staffers. Don't force them to search for the proper entry in a 50-entry pulldown. Ideally, structure the case types so that no more than 5-7 values are displayed (use subtypes if you have a wide variety.) Make sure all staffers understand the value of correct entries.

Case types are a powerful analytical tool: use them!

Summer book sale

Time to finally read The Art of Software Support (and help me clean out the garage to make room for new book!) Through 9/15 only, the special subscriber price will be 50% off: $20 including taxes and shipping within the US (add $10 for overseas airmail shipments). More details on the book here

FT Works in the News

SupportWeek published an article I wrote entitled 10 Steps to Better Metrics that discusses practical ways to improve support metrics. You can read it at
http://www.supportgate.com/supportweek/20020730/article1.asp

Curious about something? Send me your suggestions for topics and your name will appear in future newsletters.

regards,
Francoise Tourniaire
FT Works
650 559 9826

Subscription Information

To request, modify, or cancel a subscription, please drop us a note. The mailing list is confidential and is never shared with anyone, for any reason.

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