The FT Word – June 2004
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 June 2004 issue of the FT Word. Please share the FT Word with colleagues.
In this month’s issue:
· end-of-life policies
· web support ideas from the best in the business
End-of-Life Policies
Thanks to Neil Baron for suggesting this topic.
Are you supporting creaky old products for which you just don’t have knowledgeable staff? Are customers balking when told to update to the next release? Then you want to read this and glean a few ideas.
What’s supported?
Make sure you make a clear commitment to your customers of what products you support and how long you will support them. A typical commitment is to support “the most current release and one back”, which is actually a little vague: the most current release is probably clear enough, but what’s “one back”? The last dot release? The last main release? Clarify what you mean by giving examples with your own release naming scheme. Say the latest release is 4.3.2. Are you committing to support:
4.3.2 and 4.3.1
4.3.2 and 4.2.8, 4.2.8 being the latest subrelease for 4.2
4.3.2 and any 4.2 subrelease
4.3.2 and 3.6.7, 3.6.7 being the latest release 3 available
4.3.2 and any 3.6 subrelease
4.3.2 and any 3 release
Once you confirm what you support, define what happens if a customer runs an unsupported release. Say you support 4.3.2 and 3.6.7 while a customer’s running 4.3.1. Would you allow the customer to log requests? Would you offer assistance without forcing the customer to upgrade? (Do you have a reproduction environment to allow the support staff to help the customer?)
Does support include bug fixes? Taking the same example of supporting 4.3.2 and 3.6.7, would you fix bugs against 3.6.7, or would you expect customers to first upgrade to 4.3.2 before the bug is addressed? What if the bug exists in 3.6.7 but not in 4.3.2? What if the bug is critical? Customers typically assume that a “supported” release will include bug fixes, at least for significant bugs, so if that’s not the case you need to be clear about it.
Finally, will you provide support for old releases indefinitely? If you support 4.3.2 and 3.6.7 and you continue to enhance release 4, moving the current release to 4.4, 4.5, etc., do you continue to support 3.6.7 throughout the process? What if it takes a couple of years to move to release 5?
Be clear on what you support. It will save you much heartache going forward.
Saying Goodbye: Sunsetting Policies
Once you have a clear picture of what you support, you need to define how you will end support on a given release (i.e., when that release will be sunsetted). In the example above, if you release 4.3.3, customers who are running 3.6.7 cannot very well become unsupported from one day to the next. Many customers have complex testing requirements that mean it takes months to upgrade.
When defining a sunsetting policy, take into account your customer base. In heavily regulated industries, you may need to give customers five years or more to migrate to new releases. Also take into account the complexity of the upgrade. If upgrading requires migrating data and extensive rework, give customers at least a couple of years to upgrade. For an easy “refresh”, six months may suffice.
Notify customers of sunset dates and repeat the notification from time to time. Customers don’t like to upgrade and may leave the chore to the last minute. If you can offer incentives for upgrading early such as discount rates on consulting assistance, do so.
Cashing in on Sunsets
Be careful about renewing customers who are running old releases. If you take their money, they will expect to be supported. Reinforce the support policy with each renewal.
Supporting older releases may be a revenue opportunity. If you have a solid release with lots of happy customers, consider providing support for it beyond your normal timeframes. Since it’s a special deal, you can attach special conditions to it, such as: bug fixing only for critical bugs, higher pricing, perhaps different, shorter support hours. Since older releases are typically very stable and customers don’t muck with their systems too much, case load should be light and you may never have to fix a single bug.
Position extended support for older releases carefully. If customers feel that they are being forced to either undergo a painful upgrade or pay through the nose for support, they will rebel. Better extend the sunset timeframe than lose them.
Cleaning House
I regularly hear from clients who have never sunsetted any product, and now have to support dozens of products, some so old that no one knows how to use them anymore, and the source code may have vanished (don’t laugh: it happened to me once). Marketing groups are not very thrilled with the prospect of driving sunsets, which bring little glory compared to new releases, so you may need to drive the process. Proceed as follows.
· inventory the products and releases you are supporting
· define or confirm the support policy: what releases will you support?
· define or confirm the sunset policy. It’s fine to be lenient with existing customers who have been allowed to use old releases, giving them extra time to upgrade to the current releases, but tighten up the policy for the future.
· communicate the sunset times to customers. Offer incentives to upgrade when possible. For example, a client of mine offers free upgrade support on a few Saturdays each year, which customers love
· train support staff to remind customers to upgrade to current releases when they call on old ones. A light touch is best. (most important) implement a process to notify customers of sunsets for the future so you don’t have to go through the cleanup ordeal again
Web Support Ideas from the Best in the Business
I spent many hours this month evaluating web sites that had been submitted to ASP for the “Ten Best Web Sites” annual contest. I found the sites to be much more polished and effective than the ones I saw last year. I hope it’s a trend and not an accident.
Here are some of the lessons I drew from the exercises.
Be casual, not stuffy
Some web sites read like they are wearing a three-piece suit. They don’t invite to linger, to say the least.
Do: keep the tone chatty and casual, both in the site itself and in the knowledge base. Of course you want to be professional and certainly stick with proper grammar, but stay away from formality.
Integrate and link
Many sites have many, many options including knowledge base searches, troubleshooting wizards, access to the case-tracking system, downloads, etc. The best ones are not the ones with the most options, but the ones in which the options all work together. So if a customer just looked at a knowledge base document, why not offer to use a customer forum as well as start a new search?
Do: merge the silos of information even if it’s difficult since they are owned by various groups within the company.
Personalize
Many support sites have impressive knowledge bases with lots of documents and decent search capabilities. But with many documents come confusion. If your users log in to access the site, see if you can use their product information to show them only the products that are relevant to them (or ask them to choose when they enter the site).
Do: show personalized views of the same underlying knowledge base.
Pioneer multilingual solutions
It’s difficult and expensive to maintain a multilingual knowledge base. Some of the better sites I saw offered: “native” translations, down to the different capitalization and punctuation rules in other languages; a choice of languages offered for each document; access to English documents from non-English searches; and helpful hints to navigate the system, even if it’s clumsy, a la “if your search doesn’t retrieve anything, try English keywords instead.
Do: start small and build up; even a partially translated knowledge base is useful.
Test your site with real users
The best sites I saw were the ones that reported having worked with real users during the development phase. Coincidence? Perhaps. But it’s very difficult to anticipate what will be a challenge for a customer, especially if you have a lot of naive customers.
Do: test with real users, even if it’s only a handful and even if you do only a casual test. It’s invaluable to get real feedback.
Reuse and recycle
One of the site I saw had found web-based training events that the marketing group had recorded and put them, “as is” on the support site. They turn out to be very good tutorials for beginners, for a very low cost.
Do: bring down departmental barriers and gather up everything that can be useful to customers.
FT Works in the News
SSPA News gave me the first column in their new “Consultants’ Corner” weekly feature (yeah!) with an article entitled What’s support all about, anyway? How to clue in non-support executives to the realities of your world. SSPA News 6/8/04 http://www.thesspa.com/sspanews/060804/consultants.asp [ask me for a copy if you are not an SSPA member.]
Congratulations to the winners of the ASP “Ten Best Web Sites” awards: Apple Computer, Cognos, Hewlett-Packard, Interwoven, Iomega, National Instruments, RM (Research Machines), Xilinx, DataDirect Technologies, and Think3! It was fun to be part of the judges’ panel again. You can see more details at http://www.asponline.com/awards.html
Want to learn more about selecting and implementing a CRM system? See the latest FT Works workshop (If you had trouble with the URL in last month’s newsletter, try this one, it works!)
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
