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 November 2005 issue of the FT Word. Spread the word: feel free to forward it to your colleagues.
Topics for this month:
· retiring older releases
· CRM for the public sector and non-profit sector
· a fun contest to name the upcoming knowledge management book
The Art and Method of Retiring Older Releases
Thanks to Phil Rogacki for suggesting this topic.
What to do with older releases? Supporting old version is difficult: knowledgeable staff leaves, or wants to work on newer products, and maintaining multiple test environments is costly. At the same time, withdrawing support from older versions may be a hit on revenue if customers are still using them and won’t upgrade. Some support centers try to finesse the issue by giving a “best effort” pledge for cases about old versions, but that can create nasty disagreements about what constitutes best effort. Let’s review cost-efficient, customer-friendly ways to handle the retirement of older versions.
1. Define a clear policy on supporting old releases.
Many vendors support the current version and one back, meaning, for instance, 3.2.6 and 3.1, with bug fixes available only in the current version (in this example, 3.2.6.) This means no back-porting of bug fixes. You may choose to develop a more relaxed release support policy to meet your customers’ needs. For instance, government customers often ask for longer support periods. The policy should match both what you can deliver and your customers’ needs. Whatever you do, make it clear.
2. Publicize the support policy.
Post the support policy prominently on your web site and send alerts to customers to warn them of impending end of support dates, also called sunset dates. Customers often need a lot of time to prepare for upgrades to give them as much notice as possible, especially if the upgrade is complex.
3. Don’t provide “unofficial” support.
There’s more and more pressure from customers against being forced to upgrade. This is leading some support centers to provide support for officially unsupported older releases. It’s a dangerous strategy since it creates an environment where customers will push the envelope in all kinds of situations. To reprise the example above, if you find yourself “unofficially” providing support for all 3.x versions rather than just 3.2.6 and 3.1, change the policy to say you support all 3.x versions and make no exceptions.
4. Don’t sell what you don’t support.
It’s not ok to take customers’ money for support contracts if they are in fact running unsupported versions. If customers are running on older versions they should be told at renewal time that they need to upgrade to receive support. (I would not offer refunds, however.)
5. Handle old-version cases carefully.
If a customer with a valid support contract calls with a question on an old version, it’s certainly fine to offer them a “best effort” answer, after telling them the version is not supported. For instance, if your cases are complex you could offer to spend up to 30 minutes on the case. After all, new releases are often quite similar to the old ones. Be warned that the definition of best effort is not always a subject of agreement if you have to terminate before a solution is forthcoming…
Always offer upgrade help on an old-version case. The customer may not be aware that the version is no longer supported.
6. Help customers upgrade.
If you find that lots of customers with valid support contracts are running old, unsupported releases, use a proactive approach. You can simply remind them to upgrade or you can offer complimentary upgrade assistance in the form of a webinar, a full-blown class, perhaps complimentary weekend support for upgrades on a designated weekend. Anything that can be scheduled is better than the emergency case that requires an emergency upgrade to become eligible for bug fixes.
7. Consider supporting “classic” releases.
Sometimes it’s best to go with the flow. If a lot of customers are running on an old release, maybe you can charge them extra to provide support (but not necessarily bug fixes) for that release. If enough customers sign up, you can afford to keep staff trained on the release and a running version available within the support center. You may even be able to charge more for supporting older releases, while incurring less cost if they are stable. (Naturally, you don’t want to make an unstable release a “classic”!)
CRM for the Public Sector and Non-Profit Organizations
Thanks to Hasan Dohogu for suggesting this topic.
Public sector and non-profit organizations are obviously different from commercial organizations. Can they take advantage of CRM solutions and what are the differences from their commercial counterparts?
1. There are many similarities.
All organizations, regardless of their purpose, have customers to serve, knowledge to preserve and enhance, relationships to develop, communication channels to monitor, issues to resolve, both specific to individual customers and generic issues, and various programs that guide the delivery of what they do. Some non-profits deliver very much the same services as commercial entities. Think of hospitals, for instance, or local governments that provide utilities such as energy or garbage service.
Cost cutting is a very universal theme. Customer satisfaction is or should be universal as well. Therefore, the goals of traditional (commercial) CRM are very much applicable to governmental entities and non-profits.
2. The terminology is different.
Non-profits may call their customers patients, patrons, donors, members, volunteers, clients, etc. They may collect donations rather than sales. They may sell memberships rather than subscriptions. But the basic principles are very much the same and indeed many CRM tools allow customizing such simple items as field names. Don’t let terminology dissuade you from adopting a tool.
3. What processes do you want to automate?
If you’d like to create a self-service site with FAQs and a search, traditional CRM tools will work well. If you want to keep track of members and whether their memberships are paid up, either a traditional commercial tool or one specifically made for membership-based organizations will do.
Even tasks that don’t seem standard for a commercial organization may be tackled in a standard tool. For instance, if you’re scheduling soccer fields for the local children’s soccer league, a standard scheduling package may work (but standard scheduling packages do not know that Santa Rita fields are marked for the under-8 crowd!)
Other tasks can be really complex to model in a mainstream commercial tool. For instance, if you need to share school grades confidentially with parents and students, you need the concept of student linked to one or several parents, a concept that is absent from tools that are not designed to work for schools.
Recipe for Success
1. Assemble an implementation team
2. Identify the processes you want to automate.
This is a great opportunity to redesign broken processes, with the customers (members, donors, clients, …) in mind.
3. Select a tool that best matches your process automation needs.
If your processes map well to a standard tool, great: you will have a choice of many commercial tools. If they do not but you happen to be in a market that’s large enough for specialized tools, such as schools, great again. If not, you will need some customization work.
4. Define minimal customizations that will allow you to meet your goals.
Customization that directly relates to your goals (#2) is wonderful. Anything beyond that is costly, risky, and useless.
5. Test each step along the way.
This includes testing with your real customers to make sure they can use the system (if self-service) or the system works for them, if your staff uses the system.
The 5 steps above should sound very familiar to commercial organizations who have implemented CRM tools!
FT Works in the News – and the Contest
The knowledge management book is off to the publisher… and we could use your help to find a good title. The working title is Transforming Support with Knowledge, which will probably become our subtitle as we search for a peppy, more alluring title. Would you like to play? Please send me your suggestions ( mailto:FT@ftworks.com). If your idea is selected as the title you will get your very own complimentary, autographed copy.
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