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 February 2005 issue of the FT Word. Please forward this issue to your colleagues.
In this month’s issue
· looking for root cause
· low-cost CRM solutions
· join me at the upcoming SSPA conference in San Diego: I’m presenting a special pre-conference seminar. See http://www.sspaconferences.com/sandiego/training.asp#session1
Looking for Root Cause
Root cause is the Holy Grail of many support organizations. If we can figure out why customers are calling and address the problems once and for all, then case load goes down and customer satisfaction goes up, the perfect world.
In some areas of our lives, we insist on finding root cause. For instance, the National Transportation Safety Board investigates all plane crashes, reconstructing each crash in detail, and reviewing all data available about the crash. Even with such an exhaustive approach, the NTSB can’t always confirm the exact causes of a crash (but, to be sure, air travel is very safe partly as a result of the NTSB investigations.)
Support cases are rarely as dramatic as plane crashes, but the same principles apply: collect data, reconstruct the sequence of events, and eliminate causes systematically based on evidence. However, with limited resources and the need to take care of the incoming case load, you cannot conduct a full root cause analysis for each and every case that comes your way. What can you do?
Use category tracking
You should be able to gather basic category information for each and every case. Most tracking systems support a two-tier, customizable categorization system. Many support centers use case types to route cases to specialized subteams, but they can be most useful for root cause analysis as well.
Select a few categories (no more than 10 if at all possible) and a reasonable set of subcategories for each category. Don’t be tempted by the false precision of having hundreds of categories available. Most support staffers will sacrifice accuracy for speed (and, if there are many, many categories, the nuances between them will go undetected anyway.)
Categorizing cases is a far cry from root cause, but it will allow you to conduct basic analysis, a la “40% of the cases for the new release are about compatibility problems, so we’d better review the compatibility matrix”.
Use knowledge base linking
For well-understood problems, the knowledge base could be your low-cost root cause analysis solution. Ask the support staffers to link the cases to the knowledge base document(s) that best exemplify the problem they encountered. And voila: you can run reports to your heart’s content on how many times a specific issue occurs.
Balance the ultimate search with customer satisfaction
Here’s a real support dilemma. Sometimes, the fastest way to resolve a case is to tell the customer to reboot — it fixes the problem, but you may never know what caused it in the first place. Or you give the customers instructions, but they change a few other factors while they are at it so it’s never clear what actually fixed the problem. And of course there’s always the situation where looking for the real root cause would require customers to run time-consuming tests they are simply not interested in pursuing.
Err on the side of customer satisfaction. If the customer wants the fastest fix possible regardless of how you got there, that’s what you need to deliver.
Interestingly, some customers are as fanatical as the NTSB about finding root causes and you may find yourself on the other side of the debate, having to convince a customer that there’s simply no way to get to a final root cause, at least without massive amounts of effort and no guarantee of a clear outcome. Even the NTSB sometimes says, “we don’t know for sure.”
Find your Top 10s
Rather than systematically searching for root cause for each and every case, focus on large or time-consuming categories. If 30% of your cases are related to installation problems, there must be improvements possible in the installation process. If the percentage of performance tuning cases jumps suddenly after a new release, you probably need a solid knowledge base document on tuning. And if you’re spending $10k per month replacing disk drives that turn out to work quite well, you should improve your diagnostic checklist.
Do some manual analysis on the top 10
Sometimes, categories or even knowledge base links are not enough. You may have large numbers of cases in a given category, even linked to a particular issue, but you may not know exactly what causes the problem or how to mitigate it.
At that point, you will need to expand some manual effort on analyzing closed cases. This must be done by a senior rep, but if the categorization is done well and you only focus on the top categories, it should not take too long. If you do have a lot of cases, don’t hesitate to use sampling techniques. Analyzing 5% of the 2,000 cases of bad disk drives last month should yield excellent results, almost as good as looking at each case.
By the way, many of my clients report disappointing results with manual analyses, saying that they simply confirmed what the senior reps already knew, gut feel. To which I say: you have great senior reps! They really know what’s going on. The advantage of doing the analyses is that they carry the day much more effectively when it comes to allocating resources, especially from groups outside Support.
Use short-term “dives”
Sometimes, a post-close analysis is not enough because too few details were gathered during the resolution. While you don’t want to overwhelm the support reps with detailed analyses on each and every case, it’s perfectly appropriate to hold short-term projects around specific issues. For instance, you could ask the reps to gather very detailed categorization information (Is it performance tuning for a new or existing application? Is it performance tuning for the database or the UI? Has the customer read the knowledge base document prior to calling?) Or you could ask them to use a custom data-gathering form for that particular problem. The idea is to keep the exercise just long enough to gather solid data, but short enough so the reps actually do the work in a reliable manner.
Do something with the data!
Never forget why you are doing all this work: make changes to decrease the incident rate of frequent problems, including lobbying for bug fixes and product changes. View these efforts as long-term, but with proper data you should be able to make changes for the better.
Low-cost CRM Solutions
Thank you to Charlie Gibson for proposing this topic.
If you’re in the market for a tracking system but have a limited budget, there’s hope. And if you already have a tracking system but need a different one for a new project, a short-term effort, or simply because your IT group would take too long to customize the one you have for the new requirements, free and low-costs systems are worth a look. Here’s a sample.
The Open source Ticket Request System (OTSR) includes a customer web interface, email support, an FAQ, and even a bug reporting capability via Bugzilla. Quite a nice package, and certainly the right price. See http://otrs.org/
Request Tracker is another open source possibility. It focuses on the actual tracking process and includes nice capabilities for routing and escalations. Great for complex support. See http://www.bestpractical.com/
ProblemTracker offers a full environment including self-help. It’s available in ASP as well as licensed products. http://www.problemtracker.com/
I also like TeamTrack, now under the Serena umbrella. http://www.serena.com/Products/teamtrack/home.asp
Bottom line: just because your budget is limited doesn’t mean that you have to make do without a (decent) tracking system.
FT Works in the News
Please join me in San Diego in March at the SSPA conference. Come early on Sunday 3/20 and attend a special one-day workshop: “From Support Models to Support People: Make the Right Strategic Decisions for Your Organization”. We’ll explore the intricacies of P&L for support, build staffing models, discuss organization models, create goals and objectives for the staff, and, of course, think about metrics. See more details at http://www.sspaconferences.com/sandiego/training.asp#session1
I will also present on selecting knowledge management tools with Matthew Gulbranson of Nokia, who will keep me honest on what really happens in selection efforts. See http://www.sspaconferences.com/sandiego/breakout2_execinsight.asp#gulbranson.
SSPA News published the first of two articles I wrote about running support as a business. It’s Running Support as a Business or How to make your CFO Love you SSPA News 1/11/05 http://www.thesspa.com/sspanews/011105/article4.asp
And finally, the Association of Support Professionals, ASP, is listing this newsletter in its Directory of Support newsletters at http://www.asponline.com/newsDir.html. We’re famous! Please keep suggesting new topics so we can keep up with the best.
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.
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.
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.