The FT Word – November 2008
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 November 2008 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription by clicking here.)
This month’s topics:
- Problem management – going beyond begging Engineering for a fix
- The strategic use of support communities – leveraging communities besides getting customers to answer each other’s questions
Problem Management
Many thanks to Nora Chen for suggesting this topic.
Let’s start with a bit of terminology: we will talk about problem management when we refer to working with defects or enhancement requests, and case management when we discuss managing customer issues. Specifically, a customer issue (case) may be associated with a defect or enhancement request – although most are not. And a given defect or enhancement request may be associated with one or several customer cases, although some are not, e.g. bugs that were found as part of the routine QA process.
1. Define a reactive problem management process.
Since some proportion of customer cases will be triggered by a defect or an enhancement request, every support organization must have a mechanism to address such issues. Specially, the process must address:
- How to report a problem (from the Support side)
- How the problem is handled from the Engineering or Marketing side (often it’s Product Marketing rather than Engineering that makes decisions on enhancement requests, and in some cases Product Marketing owns all problems, including defects.)
- What’s the likely outcome to the customer, including whether the customer is likely to receive a hot fix (patch)
2. Define an internal SLA.
Problem management processes are useless without an SLA (service-level agreement). Typically Engineering organizations are very busy with concerns other than fixing customer bugs so it’s important to define a reasonable agreement about how quickly they will address such issues. A good strategy is to define a two-level process, one for run-of-the-mill issues and another, expedited one for critical problems. The critical process usually runs around the clock while other issues can wait.
Note that you need to go further than what we would call response time and also define resolution scenarios. For instance, for critical issues the Engineering organization will assign an appropriate contact within an hour and deliver a patch if needed (and no workaround can be found) whereas for other problems the response would be a business day or two and the fix will be lined up for the next maintenance release. I’ve found that it’s often difficult to get agreement on the principle of an SLA because the Engineering organization is (rightly) concerned about not being able to meet it 100% of the time. Naturally we in Support have no such qualms…
3. Avoid “happy few” bottlenecks.
Should every support engineer be able to report problems to Engineering? Should every support engineer drive issues through Engineering? Probably not brand new engineers, and if you work with a tiered support model only level 2 support engineers should be allowed to communicate with Engineering, but resist the lure of restricting the privilege to just a handful of senior support engineers (as, most probably, the Engineering team will suggest.)
The best mechanism is one where support engineers earn the right of submitting problems by doing it right over time. A support engineer who submitted ten (say) valid bugs in a row can dispense with approval but if he submits a couple of problematic ones he goes back to mandatory approval status. (If you like the KCS model of knowledge management, it’s the licensing idea.)
4. Let Engineering define and control its internal processes.
Since we are so good at managing customer issues (we are, right?) it can be very tempting to show Engineering how to manage problems. Don’t! You can volunteer to help and you should leverage your personal relationships if you have them but let Engineering make the decisions and accept them as long as the outcome is within the SLA that was defined. In particular I’ve found that many support managers and executives have very strong views, both pro and con, about the wisdom of having a Sustaining Engineering team within the Engineering organization. Not surprisingly, Engineering executives also have their views on the matter and I doubt you will impose yours. So sit back and focus on getting appropriate response and resolution on issues rather than worrying about controlling how things get done.
5. Use the Engineering group’s tracking tool for problems.
The Engineering team always has some kind of tracking system for problems since it needs a way to track problems discovered during QA, so it makes sense to use it to track issues reported by customers. (I worked with a client once that actually maintained two problem-tracking systems, one for internally-reported bugs and one for customer-reported bugs, and everyone there was very confused: don’t do it!)
What’s needed from the Support side is
- Access to the tracking tool to enter new bugs and search existing bugs (read access for everyone in Support; write privileges for the subset authorized to report bugs)
- Access to reporting tools for the problem-tracking tool (for measuring SLA performance)
I very much like the idea of reporting enhancement requests side by side with bugs and tracking them in the same tool even if different organizations prioritize them. Certainly enhancement requests are much less precise than bugs and often need to be considered in logical bundles with others, or abstracted to another level, but it’s a great help to track them together with the bugs when it comes to reports and also going back to the customer with a solution.
6. Conduct regular root cause analyses.
A good reactive process for problem management is excellent but not sufficient if you’d like to really make a difference in your productivity and in customer satisfaction. You must seek to uncover clusters and patterns so you can train your staff, write more useful knowledge base articles, and work with the Engineering team to deliver effective solutions. While you can get interesting results solely through appropriate case closing codes, a useful root cause analysis requires a skilled support engineer to sift through the busiest case categories and isolate the key trends.
7. Hold joint review sessions with Engineering.
The dreaded “bug meetings” are very useful. Each week, review both the SLA metrics and the outcome of the root cause analysis, focusing both on a handful of individual critical customer issues and some less critical, but more widespread problems. By keeping some attention on the non-critical issues you can avoid unnecessary pain on customers and the support team.
Don’t expect to be fully in charge of managing problems. It will always be a joint effort between you and the Engineering group. Your role is to always be the voice of the customer.
8. Redouble proactive efforts when the going gets tough.
Sticking with a proactive joint approach is particularly important if you have a large volume of bugs, one that overwhelms Engineering’s ability to deliver solutions in a timely manner. We tend to get frantic when the Engineering backlog (and customer’s impatience) grows and to add layers of escalation management. It would be better to strategize what can and cannot be done. For instance, Engineering may be able to refocus some additional resources to fixing customer bugs while you can have some sobering conversations with customers with less critical issues (better set expectations early that a workaround is all we can do rather than let them wait fruitlessly for a fix.) Along the same line, better fix a problem that affects many customers even as critical customers are waiting.
The Strategic Use of Support Communities
Support communities are a wonderful tool to allow customers to share experiences and solutions. What’s not always clear is whether and how the vendor should insert itself in community conversations. On one end of the spectrum, some vendors use communities as a substitute for all other channels. If you do that, clearly you will be present in more community conversations. At the other end of the spectrum, some vendors actively discourage staff to participate in community discussions. What’s the best way to position yourself, the vendor, within communities?
1. Fulfill your support commitments.
If you have chosen to deliver all support via the community, treat it as you would any other channel. Define a target for response time (don’t make it too tight, or else you will discourage customers from answering questions) and aim to respond if no one else does. If your customers can contact support through other means you can be more lax but you may still choose to answer some questions to build interest as you launch and on an ongoing basis.
2. Monitor the forums to keep them clean.
Regardless of your level of reactive involvement you must monitor forum (community) communications to spot objectionable posts and educate the authors about proper etiquette. (You can also deputize customers to do that.)
3. Mine the forums to spot trends.
A more important reason to monitor the forums is to spot trends: are customers complaining about feature X? Are customers working around the lack of feature Y? Are customers inventing cool ways to use product Z? All that would be great fodder for knowledge management and input to Engineering and Product Marketing. Be a hero, be the voice of the customer.
Note that input from the forums may be of even better quality than what you can find in cases reported to the Support team. In particular, customers are very unlikely to contact support for minor issues so they may not even show up in your root cause analysis.
4. Respond on key issues.
Forums are a tool for customers, by customers. You should not hover (visibly). You should not censor (except for foul-mouthed posts, as noted in #2). You should not take over. However, you should not be invisible. If there are 239 responses to the “Why I hate release 3.2” thread, the Product Manager for release 3.2 should post a calmly-worded, comprehensive response – whether or not you have a completely vetted strategy for how you will address the issue. Just say that you understand the problem, you apologize for the pain, and within [insert timing here] you will have a statement of purpose posted on the forum.
5. Use the forum to communicate out – sparingly.
While the forums should be mostly customer-driven it’s fine to use them for proactive communications. Steer clear from pure commercial messages: they will be badly received by customers, who may decide to stay away from the forums altogether. Select appropriately important themes: a major new release, new pricing, a critical corporate change. Use a conversational style: if it reads like a press release, it won’t fly! And be prepared to get comments back (and respond to the most important ones, perhaps via regular updates rather than blow-by-blow.)
Note that the Marketing team may not be aware of the forums as a communication channel with the customer base, and it may not be comfortable with it. Gently suggest opportunities to use the communities and provide oh-so-gentle coaching on tone and content. This two-way communication idea is wonderful, but there is a learning curve.
FT Works in the News
SSPA News published an article I wrote about support pricing, Key Tips for Support Pricing. You can read it at http://www.thesspa.com/sspanews/October08/article7.asp
Still revising (and cutting) your budget for next year? Instantly re-plan with new assumptions and correlate budget to productivity and other key support metrics with Budget Magic, the latest FT Works booklet and spreadsheet templates for all kinds of support organizations, regardless of the resolution model you use and whether you operate as a P&L or a cost center. More details and ordering information at http://www.ftworks.com/BudgetMagic.htm.
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
