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 July 2007 edition of the FT Word. Forward it to a colleague!

Lots of best practices this month:

10 best practices for proactive communications
10 best practices for support communities

Best Practices for Proactive Communications

Thank you to Rick Morris for suggesting this topic.

Following up on last month’s topic about Sustaining Engineering, here are some ideas on how and when to share information with customers in a proactive manner – whether it’s Engineering data or not. Most people’s first idea of proactive communication is an alert: a short email message that lets customers know about a critical bug – or perhaps a fix for a critical bug. Alerts can be wonderful in getting information out quickly, but only if they are sent to the right person (who cares about a bug in another product?), speak straight (is it a bug, or are they trying to make me believe it’s a feature?), and are timely (don’t tell me about the bug after I found it the hard way. And there’s much more to proactive communications than bug alerts.

Well executed, proactive communications can decuple the perceived value of support while minimizing case load. Who would not wish for that? Here are 9 best practices for proactive communications.

1. Inventory content types for proactive communications

Don’t obsess about bug alerts and neglect the rest. There are many kinds of information that may lend themselves to proactive communications.

alerts for (critical) bugs and their fixes
lists of outstanding bugs (waiting for a fix) for a particular version
announcements of new releases, maintenance releases, service packs
downtime notifications
new knowledge base documents
revised knowledge base documents
newsletters, which can mix many of the other topics listed here
support contract renewal notices (a highly-customized example of proactive notification)
reports on support usage
new product availability
company news such as personnel appointments, new offices, etc. (don’t duplicate communications from other departments!)
new support offerings, or changes in existing offerings
new or improved support processes

While you may not choose to use all of them, it’s useful to inventory the ones you want to use as well as the ones that are easiest to manage considering the tools you have at your disposal.

2. Offer personalized information on the web site

You may not think of information on your web site as proactive communication, but it is! When customers come to your site, whether they have to sign in or not, you can provide information right there, without the customer having to search for it. Ideal candidates are “Hot Issues”: the most popular knowledge base documents (giving rise to the most cases and/or accessed most often) and any new documents created in the past week or month (or, better, since the last time the customer visited the site.) It’s best if your system can create the lists dynamically: there’s nothing sadder (and more often ignored) than lists of documents that were “new” six months ago…

This strategy is naturally much more powerful if you can personalize the information. If customers log into the site, perfect: just show them the documents appropriate for their particular products. Otherwise, cookies may be useful at remembering what choices the customers made in prior visits.

3. Allow customers to register for individual documents and knowledge base categories

Some tools allow users to subscribe to specific documents or categories of documents so they get notified (automatically, by the system) when changes occur. This is a very handy mechanism. For instance, if you create a document to highlight a particular defect, any updates to the document reflecting new workarounds or fixes automatically and immediately get to customers.

Some vendors manage their release announcements that way: customers subscribe to the document that shows the release schedule and get a notification when a new one becomes available.

4. Offer RSS feeds

Same idea, different channel: RSS (“Really Simple Syndication”) feeds can be added to product pages, categories, anything that you can tag. Here again, let customers manage their registrations.

5. Push information – but personalize it and allow customers to manage their subscriptions

For some information it really makes sense to maintain distribution lists and to push the information manually. Newsletters, bug alerts, changes in the support process all fall in that category. A wonderful approach is to offer customers the ability to manage all their subscriptions from one place. If you have many product lines, allow customers to select what they want to be kept informed about. So a customer may sign up for bug alerts for the one critical product she uses, but only a periodic newsletter for the other ones.

6. Stay within the law

If you intend to use email, be aware that the US government (and many others) has regulations against spam that may affect proactive support communications. If customers sign up for the proactive communications, you are in the clear. Bug alerts and the like are also excluded from regulations as they fall under support communications, not marketing. But be careful with product announcements unless customers can decline them: they are likely to run afoul of anti-spam rules. Consult your friendly lawyer to make sure you are not unwittingly breaking the law.

7. Use the knowledge base to create newsletters

Custom-made newsletters are wonderful but who has the time to create them? Many organizations simply run a report of the most popular KB documents, select a few, and voilà, the newsletter is ready. Here again it’s best to customize by product or product line. And the newsletter itself should be a document, accessible via searching, and perhaps featured on the home page as a best bet.

8. Mine training, casual conversations, and engineering interactions for technical content

All the ideas so far don’t help with creating content in the first place, which is often the problem when it comes to very technical content. The Engineering team is unlikely to write documents for customers’ consumption (although it doesn’t hurt to ask) so mine your interactions with development engineers. Some of my clients use wikis to communicate with the Engineering team and have found that judicious reuse of wiki conversations is a perfect source for technical documents. Other popular inspirations are brown bag sessions with Engineering and formal or informal training.

Be generous in recognizing contributions to the knowledge base from Engineering. Try giving awards on a regular basis to the best contributors, in as public a setting as possible (company meeting, company newsletter.) This will give visibility to your efforts, please the recipients, and encourage others.

9. Work with Engineering to overcome sharing concerns

A big roadblock to sending alerts to customers is a concern, widespread in Engineering and Marketing groups and some Support groups, that we simply can’t tell our customers our product has bugs. How silly! All software products have bugs, and many customers react angrily when told that it’s a “known bug” when reporting a problem. You may need to use some friendly persuasion with individuals throughout your company to convince them that telling customers about bugs is a good idea. Create some reasonable guidelines. You certainly don’t need to formally warn customers about every bug, only critical bugs.

And target customers as best you can: while customers appreciate getting alerts about critical bugs before they encounter them, being on the receiving end of a torrent of bug reports for products or releases they do not use is likely to generate some quality concerns for no good reason. Personalization is key.

9. Orchestrate

While you don’t need a large team to manage proactive communications, it’s very useful to designate a point person to coordinate the program and ensure that it remains vibrant and coherent. Naturally, larger teams will need more hands.

10 Best Practices for Support Communities

Support communities are typically thought of as forums, but they may also include other collaborative tools such as wikis and blogs. The idea is that users can contribute to the community rather than simply use the community to get answers or ideas (although the ratio of contributors to users is typically very, very small.) Support communities are the embodiment of the Web 2.0 idea for support and as such deserve plenty of attention and inventive experimentation.

1. Recognize whether you have a valuable potential community

Communities are cool these days, but it does not mean everyone should have one. Communities that work well have enough traffic so that even regular users find something new on each visit. Before you start, ask yourself the following basic questions.

Do you have enough potential users? A few dozen customers are less likely to form a vibrant community than several hundreds, or thousands.
Are customers likely to use the community? If your customers are very closed-up about what they do they likely will not participate. For instance, many vendors report that partner forums don’t work well because of competitive concerns.
Are there members of the community that have a built-in benefit for answering questions? Most community contributors do it for the glory, but it does not hurt if you have a few members who want to raise their profile. Third-party consultants are a great example.
Are there competing avenues for support? Communities are perfect for the long tail of content, for instance small products, orphaned products, unsupported languages – and in such situations the size of the community matters less. On the other hand, if there is an existing, popular forum hosted elsewhere, perhaps your forum won’t be that attractive to potential users.

An interesting (and frustrating) feature of communities is that they are hard to pilot: starting small may mean not getting anywhere. Make sure you have a critical mass.

2. Seed answers, especially at first

The purpose of a support community is to be self-supporting but it works even better with a little help from you. Allow messages to sit for a while so they can generate answers from other users and consider providing answers if no answer is forthcoming after 24-48 hours. Yes, it means that users will be getting support “for free” but at the same time the forum exposure could save you quite a few requests – and it’s great for customer satisfaction.

3. Monitor, but don’t be heavy-handed

You will probably want to remove obscenity-laden postings, but I would be wary of so-called communities that don’t ever allow negative comments about the product or service. Don’t whitewash: you will gain the users’ trust.

4. Use ratings and reputation

In an open forum where no one is a designated expert, it’s important that users can have a feel for whether they can trust a specific piece of content. A great way to do that is to allow a rating system a la eBay through which posters can identify answers to their questions. Contributors who generate more answers can then be identified as such, and users will put more weight on their postings. And I would identify staff members as such. It does not make them experts per se but it seems to generate more trust in the system than hiding them behind an avatar.

5. Include the forums in the search universe

Forums are an “early alert” mechanism and they often include answers that have not yet made it to the knowledge base (see point #7 below)

6. Mine for feedback

Communities are a great way to get the pulse of what users are thinking. Simply trolling through the postings gives an accurate idea of whether installation is too hard, or what customers are really doing with the product. They can also give hints on how to improve your search environment when you see what (non-standard) terms customers are using to describe their problems.

7. Mine for knowledge

The question/answer format of forums makes it easy to create knowledge base documents that will be easier to search. Free solutions for the picking! Manually pulling popular topics into the knowledge base is a great strategy even if you can only do it in a few areas. With sophisticated knowledge management systems you can automate the mining.

8. Cultivate power users

Thriving communities have one common characteristic: they are nurtured by the users themselves rather than by the vendor. Power users don’t need to be paid (actually, giving them more than token recognition could create IRS issues) but they do need to be recognized. Be creative: let them post a profile on the web site, give them access to early products, etc.

9. Be legal

Get your legal team to provide appropriate wording for the forums, including no liability on posted content and no ownership by posters on the content they post.

10. Don’t try too hard to monetize the forums

Communities pay off, but exact metrics are difficult to create and should always be viewed with some circumspection. My favorite metric is the percentage of answers provided by users rather than the vendor (clearly, higher and increasing percentages are better).

One interesting idea would be to make it easy to purchase products from the forums, since forum users are more likely to recommend the product than other users. There’s still a lot of room to experiment…

FT Works in the News

I’ve been asked to participate as a judge in SSPA’s Fall SSPA Recognized Innovator Awards. I look forward to sifting through inspiring applications next month.

FT Works has added a new workshop to its line of support training: Customer Service Skills. This is a one-day version of the always popular Tech Support Skills workshop especially designed for Customer Service teams and covering the same customer-oriented topics: email skills, phone skills, customer styles, and stress management. Learn more here and here. (And we now have three trained instructors so we can schedule your workshop even faster.)

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

Back to Newsletter Archive