The FT Word – May 2007

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

It’s this time of the year when we start a new volume of the FT Word. Welcome to the May 2007 issue and thank you for being loyal readers, some you of since day 1. Please forward this issue to a colleague or two who could use this kind of information. Subscription information is at the end.

Are you planning to be in San Diego early next week? There are still a few seats available in the workshop I’m leading on Sunday 6th on the topic of knowledge management ROI. To register visit http://www.thesspa.com/conferences/sandiego/registration.asp. (If you already registered for the conference and would like to add the workshop, call 858 674 5491.) Do it now so I can bring enough manuals for everyone!

The description of the workshop is at http://www.thesspa.com/conferences/sandiego/training_day.asp#payingForKM

Topics for this month

Using support data to push product and documentation improvements
Handoff strategy for Follow-The-Sun support

Using Support Data to Push Product and Documentation Improvements

Thank you to Pat Makielski for suggesting this topic.

So you are supporting a product that happens to have a few bugs too many. Or the documentation is lacking – or is altogether pitiful. Cases are piling up, predictably, to match the bugs or the documentation problems. What can you do to turn the situation around?

One of the key ideas of support is to be proactive rather than reactive. Rather than wait for the cases to come in and solve them one by one, it’s best to get ahead of the problem and do what we can to prevent cases in the first place. There are several lines of defense:

Working with Engineering and Marketing to ensure that products are ready (i.e. as bug-free and user-friendly as possible) when they launch. This is a pre-release activity and the savvy support executive knows to request and provide support participation in the support planning process.
Making sure that customers have the tools they need to be successful with the products. This includes documentation, implementation assistance, training, etc. Again, it’s a pre-release activity.
Regularly analyzing incoming cases to detect trends in customer requests and devising and implementing remedies to address the issues before they create yet more support requests. The remedies could include changes in the product, in the documentation, or in services other than support, as well as the always-popular additions to the knowledge base.

Today we will focus on the last point: the product is launched, the release is released, what can we do about issues we discover afterwards?

1. Properly log all cases

This seems obvious, but if support staff routinely fails to record certain requests then the requests will be essentially invisible and it will be very hard to prevent them. This is common with “easy” requests, which are the most likely to be ignored at logging time. While easy requests are easy to resolve, they do consume staff time as well as create a burden on customers. No issue is too trivial to fix if it affects lots of customers (and look at it from the bright side: if it’s an easy request, it probably has an easy solution!)

The main reason why issues are not logged is that it takes too much effort to log them, especially for those easy requests with quick answers. Scrutinize and streamline the logging process. Better log fewer details and capture all the cases. More on this in the next point.

2. Adopt or improve resolution categories

While a proper root cause analysis requires thinking by skilled support staff (more about that in step #4), a solid set of resolution categories is a good start. We’re talking here about post-facto categories, often called resolution or root cause categories, not about the routing categories that are used to classify requests when they are made. Typically, routing categories include the product name and the type of question being posed (say, ProductX/installation or ProductX/tuning) whereas the root cause or resolution categories target the reason for the request, and typically cannot be determined until the case has been worked on for a while.

Resolution categories should, at a minimum, distinguish between defects and how-to questions. A more inclusive list would read something like this:

Product defect
Documentation defect
Enhancement request
Configuration
Hardware failure
Third party product
Customer education [that is, lack thereof, often called User Error]

Of course, you can add more, including “Insufficient documentation” to distinguish it from documentation defects. But don’t go overboard: experience shows that support staffers who have to pick among more than 10 choices or more than 2 levels of categories routinely pick the top choice both for speed and because they can’t be bothered to read through all the choices. More is not better. So if you want to have categories of the type Hardware failure/hard drive, that’s fine, but Hardware failure/Hard disk/XYZ type is probably too much, especially if there are 15 different kinds of hard drives.

3. Leverage links for finer categorization

Especially in large support centers the combination of the resolution categories and the routing categories may not be enough to classify cases. If you have 3000 cases caused by bugs, it would be nice to be able to tell which bugs affect large numbers of customers. Since most support organizations have a way to link cases and bugs, that should not be too hard. (If you don’t link cases and bugs today, start now: simply log the bug number with the case record for a quick and easy workaround to a full-blown link.)

What if you have 3000 cases that relate to Customer Education on Product X/tuning? That should be a signal that tuning is important and/or difficult, but who wants to wade through all those cases to find out what area of tuning is most problematic? Well, if you have knowledge base documents that discuss various areas of the tuning process, and if cases can be and are linked to the documents used to resolve them, you can simply follow the links and quickly find out where the problems lay.

4. Perform regular root cause analyses

Here comes human ingenuity. You can run all the reports you want from steps 2 and 3, but it still takes someone knowledgeable with the products to make the determination of what’s really important. Some of my clients skip to this step immediately. In other words, they don’t use resolution categories or links to knowledge base articles; they simply ask the staff what’s important this week. This is a reasonable strategy for smaller organizations – as well as the best cop-out for larger organizations that don’t have great tracking systems, great tracking discipline, or both.

Regardless of how you get to it, the root cause analysis consists in ferreting out the most important causes of cases as well as any new trends. It answers questions such as:

What are the top 10 bugs causing us the most headaches (through a combination of severity and how widespread they are)?
What are the top installation issues?
Where do customers get lost in the documentation?
What causes the cases that require level 2 intervention?

Although it would be wonderful to conduct full root cause analyses of all cases on a regular basis, who has that kind of bandwidth? Target what’s most important for you and your customers. Most organizations perform regular sanity checks for general root cause analysis (such as: our normal percentage of cases related to bugs is 7%, are we within the ballpark this month? for the new release?). They also perform detailed analysis for new products, or products known to be troublesome, or products that are found to exceed the simple limits through the sanity check.

5. Create ROIs for top issues

No need to get fancy there. If your average case costs $50 to resolve and you got 1000 cases last week on a particular bug, that bug is costing you $50,000 a week in support costs alone, not counting customer aggravation and threatened lawsuits. On a less dramatic scale, if you get 10 cases (and spend $500) answering questions about how to install the product on a Linux box, perhaps that’s worth a new knowledge base document.

It’s fine to use more detailed cost information if you have it. For instance, if cases escalated to level 2 cost $100 rather than $50 and all bugs require level 2 intervention, use the $100 figure to cost bug-related cases.

6. Work with Engineering or Marketing to implement the solutions.

Many support organizations have standing meetings with the Engineering team to review bugs. The meetings are often dominated by the crisis of the moment (severe defects causing severe customer escalations) but there’s no reason why you can’t sneak in a few less severe issues that cause smaller-scale problems to large numbers of customers. The cost estimates you developed in step #5 should help you create eloquent justifications for why it’s a good idea to attack less severe issues.

Beyond financial impact, always suggest positive solutions to the issues. It’s much harder to refuse to implement a fix if it’s already written and on the table.

Until then, you can always create a good knowledge base document to give workarounds or other information. The ROI will help you focus your efforts in the most critical areas.

Transfer Strategy for Follow-The-Sun Support

Thank you to Ram Ramadas for suggesting this topic.

Follow-The-Sun (and off-hours support in general) is a very popular topic for FT Word questions, probably because it is very difficult to provide quality off-hours support without a very large worldwide staff. This time, we focus on the transfers between center that occur as one center closes and the next one opens.

1. Define clear guidelines for transfers to avoid dumping

In most cases, each center handles all cases that came in during their shift, both by phone and electronically, and even the ones that came in at the very end. Having a clear deadline makes it very easy to decide who owns what.
Transfers are best avoided, both for customer satisfaction and productivity. Therefore, whenever possible, the center who is working on the case should finish up the work even if it takes a small amount of overtime.
If a case will require significant amounts of work that would be beyond the scope of reasonable overtime, work it to a logical point and transfer it. I have a number of clients who transfer cases who need time-consuming reproduction work to an offshore center to be worked during the time. This is a good use of less expensive labor and it works because the boundaries of the work are clearly defined.
Only transfer actively-worked cases. If a case may need work overnight, simply give a heads-up to the next center but don’t transfer it if you’re simply waiting for the customer to get back to you.

2. Do one bulk handoff

Most support organizations choose to simply place the cases to be transferred in a special input queue for the next center. This is perfect for cases that have no special severity, such as the reproduction cases described above.
For severe issues, do a live handoff, with or without the customer. Simply call the next center and give a briefing on what needs to be done. If there’s an escalated customer involved, hold a brief conference call with him or her on the line.
An alternative is to send an email to the next center listing the cases that need attention. Because the email lives outside the tracking system it’s problematic (but, of course, required if you are using different tracking systems in different geographies – a big no-no!) Leave all the handoff details in the cases themselves, not the email, so they can be referred to later.

3. Review transfers after the fact

Arguing about the wisdom of transferring particular cases through Follow-The-Sun is not a fruitful activity at the time of the handoff. Like disputing whether the customer can really log a P1 case, it’s best to simply accept the handoff and come back later if there is a problem.
Review handoffs on a regular basis, perhaps weekly or monthly (you will have to do it daily at first or if there are lots of issues.)
Look for a regular volume of handoffs – any spikes need to be analyzed as they potentially spell trouble.
Research a handful of individual cases to check that they followed the transfer guidelines.
Look for any cases that were transferred more than once. They are obviously a problem from the customer side and could signal some dumping activity on the part of certain support centers.
Allow centers to report disputes on transfers and research what went wrong. The goal is always to make future transfers smoother.

FT Works in the News

SSPA News published an article I wrote entitled Paying for Knowledge Management in its April 2007 issue. You can read it at http://www.thesspa.com/sspanews/_07April/article3.asp. For more information about this topic, see the Collective Wisdom book at http://ftworks.com/index_files/page0033.htm.

And the last reminder to join me at the SSPA meeting in San Diego coming up this week. You have two choices

A full training day on Paying for KM: Building Honest ROIs that stand the Test of Time on Sunday 6th. You will leave with a template and plenty of ideas on how to justify your KM investment. Information at http://www.thesspa.com/conferences/sandiego/training_day.asp. There are still a few seats available as of this morning. You can register at http://www.thesspa.com/conferences/sandiego/registration.asp or call 858 674-5491.
A presentation entitled Money and the Web: Making more and spending less through online support. It will be Monday 7th at 3:15pm.

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