The FT Word – March 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 March 2008 edition of the FT Word. Please forward it to colleagues who would enjoy it. (To subscribe, contact us.)
On this month’s topic list: knowledge management, customer management, and a special invitation:
- How do I increase knowledge management usage and participation?
- Avoiding P1 abuse: what to do when customers insist something is an emergency when it’s not?
- Will you join me for Marketing Wise, my newest workshop focused on support marketing, on May 7th in Santa Clara, CA? More info here.
How do I increase KB usage and KM participation?
Thanks to Michelle Rivers for suggesting this topic.
In Support, Big is Beautiful. This is true of assisted support, where larger queues are more efficient and easier to manage than smaller, specialized queues. And it’s also true for online support. So what can be done to set the support staff to use the knowledge base and to contribute to content? Often the initial enthusiasm surrounding a knowledge management project fades over time. How can we keep going for the long term?
1. Increasing the usage of the KB will increase knowledge management activity, and vice versa.
If the support staffers use the knowledge base they will find it more natural to add to it when they stumble over a new piece of information— and naturally a knowledge base that’s more comprehensive and more accurate will be used more. So increasing KB usage and increasing KM participation are two mutually-beneficial initiatives.
2. Keep the executive and management support strong.
Knowledge management is a very long marathon – actually, one that never ends… So you need to keep executive attention on it for the long haul, not just during the exciting first rollout. This means keeping KM alive through conversations and personal contacts – and providing a few well-chosen metrics that tell the value of KM such as self-service usage and customer satisfaction with the knowledge base.
3. Continue to streamline the process & tools.
It takes a whole lot of incentives and arm-twisting to get people to use a bad system. Make it easy to contribute articles and to update articles. Tune the search engine (and upgrade the search engine if needs be.) Refrain from creating convoluted rules for what does or does not belong in the knowledge base – and certainly refrain from imposing complicated formatting mandates. Remove any obstacles in the way of KM from the contributors’ perspectives.
4. Keep training.
Most KM initiatives have a training component but that often fades away. One of my clients with a wonderful KCS initiative that was carefully laid out over a one-year period was surprised to find that “basic” questions such as what to do if one finds an error in a published document are still being asked after a year’s worth of rollout. Train the new hires, and keep training the old guard.
5. Include knowledge management in hiring profiles, job descriptions, promotion criteria, job objectives.
Anyone who is expected to participate in knowledge management should have KM included in the job objectives and metrics. If KM is a part of the responsibilities of each support rep, as is often the case, work with the line managers to make sure it remains visible and valued.
6. Beware of straight quotas!
I have worked with several customers who used to have a quota for submissions to the knowledge base through which each support engineer was supposed to contribute a significant number of new articles each month. The good news, I suppose, was that the quotas worked: most support engineers contributed the minimum number of articles required. The bad news: quantity can and does work against quality. Many, perhaps most of the contributions under the quota system were of poor quality, duplicates or part-duplicates, “stub” articles with nothing in them – all contributing to poor performance of the search engine and a dismal quality of documents.
Quotas can be effective but they need to be married with some measure of quality, for instance by auditing a sample of new articles. Low quotas (a few articles per month) seem to work better: with less pressure, support staffers appear to be able to concentrate on creating useful articles.
7. Beware of the 100% link fallacy.
In the same vein, support organizations sometimes dictate that each and every case must be linked with a knowledge base article, whether existing or new. This creates the same quality hazards as unmanaged quotas – with the added headache of bad links. Resist the 100%-link utopia. Not every case is worthy of documenting. Rather than imposing any level of links, it’s best to simply run link percentages for each individual rep and focus on the low percentages to see whether there would be opportunities to improve.
8. Reward authors.
The simplest way to reward authors is to simply reward quantity: the more you write, the more you are rewarded. That works well if you have a handle on the quality issue, as discussed above. If you’re willing to go a little further, weigh productivity with usage. Articles that are used often are probably good in some essential way, so reward authors on the popularity of their articles rather than the number of articles themselves. And if you can make that distinction, make the rewards based on other people’s usage of their articles.
Also a great way to keep it fun and interesting to everyone is to have a random drawing and prize for anyone who wrote a new article.
9. Reward updates.
If your knowledge base is mature you may have reached the point where updating existing materials (including removing obsolete information) is as or more important than creating new articles. Measuring updates is tricky since it’s simply too easy to change one (irrelevant) word in an article and claim an update. So use the same techniques as for new articles: audit quality; don’t rely on quantity alone.
10. Reinforce usage – but again avoid quotas.
People vote with their feet – or their fingers, in this case. If the support staffers believe that good information can be found in the knowledge base they will use it. Forcing them to do a knowledge base query each time they solve a case is silly. Indeed, you will get queries, but they won’t necessarily mean anything — and you will alienate your staff at the same time so don’t do it! Instead, reinforce the use of the knowledge base during escalations: “Did you check the KB?” is a great first question, together with a quick demo of how best to find results. KB usage should also be a part of any case review session, modeled by the senior support engineers and the managers.
Last idea: ask for feedback and act on it. Even a very informal, hallway survey on what makes the knowledge base good or bad is excellent, assuming that you are willing to listen to the answers, however painful they may be to you, and to act on them,
Avoiding P1 Abuse
Thanks to Somaraju Chilukuri for suggesting this topic.
You carefully defined P1 issues as system down, but customers freely use the P1 designation for all kinds of problems that do not fall under that designation: their systems are not down, or it’s only a test system that’s down so production is not impacted. What should you do to regain some discipline?
1. Clearly define priority levels.
In the example above, you may want to reconsider the posted definition. If it says “system down” and you mean “production system down”, clarify! Make sure that all your documentation, online or not, reflects the change.
2. Gently remind customers when they overstep the bounds.
This is an issue of customer skills training with the support staff. If a customer declares a P1 and the system is not down, the support rep can gently point out, in a neutral tone of voice, that P1 is reserved for system down situations and that the issue at hand does not seem to qualify as production down. “If you had a genuine system down situation we would drop everything to help you. Thank you for letting us help customers who need it the most first.”
3. If the customer protests further, go ahead and handle the case.
Arguing with some in crisis is pointless: the brain is not fully engaged when emotions are raging. The best course of action if the customer insists is to simply handle the case, especially if the initial priority determines nothing more than the initial response time.
4. Flag the case to a manager so s/he can address the issue with the customer outside of the crisis.
Once the crisis is over customers will often agree that they overreacted and adjust their attitude the next time around. It’s a good teaching moment.
5. Consider overhauling your priority definitions.
We are so used to defining P1s as system down that we fail to consider that a seriously-impaired, but not down system can have pretty much the same impact on the customer’s business as a system that’s completely down. Ditto for issues that block a new implementation or rolling out a new release. Customers are much happier with a customer-centric definition of priorities: P1 can be severe impact to the business, P2 is moderate impact, P3 low or no impact. That way, a customer with an implementation issue that’s completely blocking progress can declare a P1 without creating heartburn all around – and for good reason. And no, customers who are given the power to define their own priorities do not abuse the system (at least if they can expect a response within the target time, see #6.)
From the support perspective the impact of letting customers control the initial response time is not that great, especially in a complex support organization where the bulk of the resolution effort dwarfs the initial response time. And think of the bad vibes and wasted time you save by avoiding confrontations with customers!
6. Meet response time targets consistently.
In my experience, support organizations that have a good record of meeting response time have few problems with customers trying to jump the queue. (Much like there’s little cheating in the grocery store express lane when the other lanes are not too busy.) Meeting response time is relatively easy to do: simply assign individual to mind the incoming cases throughout the day. If you meet response times consistently, that is, above 90% of the time, you will experience much less queue jumping.
Conversely, if you’re struggling to meet response times, it’s pointless to fight with customers about priorities: fix response time first and then address “cheating.”
7. Target low response times.
To reinforce the point above, initial response times should be matched to customer’s needs. If your fastest response time is 2 hours you’re asking customers to wait a very long time if they have a pressing issue, so you are much more exposed to complaints. A good strategy is to have at least one support offering with a response time of an hour or less (which can be priced at a premium.) If a customer on a lower-lever plan complains you can suggest an upgrade, which seems to be a very successful way of quieting the intensity of the complaint.
FT Works in the News
Are you planning to attend the SSPA conference on 5/5-6 in Santa Clara? I hope you can make time to listen to Don Frye of The MathWorks and me as we tell the story of how The MathWorks implemented Knowledge-Centered Support (KCS) with a small team, enormous planned turnover, and no investment in new tools. The talk will be Tuesday 5/6 at 2pm.
And immediately following the conference please join me for a one-day workshop, Marketing Wise, that covers everything you always wanted to know about support marketing. Marketing Wise is for you if
- Your customers are unhappy with your support offerings. They complain about slow SLAs, high prices, unrealistic end-of-life policies. It seems that customers simply don’t see the value of support.
- Your sales team is struggling to sell support even as product sales are going well. It seems that the main “strategies” for selling support are to give it away or to agree to devastatingly tough SLAs.
- You find that you are giving away a lot of free support, whether it’s multiple “free” calls about installation problems that turn into lengthy handholding sessions on how to use the product, or emergency onsite visits for customers who should have engaged an implementation team.
- It’s getting tougher to get customers to renew support contracts. Treating renewals as a cash cow just isn’t working any more.
We’ll talk about best practices for designing, marketing, selling, and renewing support, and offer live mini-makeovers for your support portfolio. This is suitable for support managers and executives, not just support marketing specialists. Space is limited so we can have an interactive session. You can find more details and register here. Email me if you have any questions. Hope to see you there!
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.
