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 October 2003 issue of the FT Word. Please forward it to colleagues you think may enjoy it.
In this month’s issue:
· support collaterals: what do you really need?
· support skills refresher: “working as designed”
Support Collaterals: What do you really need?
Do your support collaterals need a boost? Here are 7 principles to live by when creating or upgrading support collaterals.
1. Aim for 3 types of collaterals
An overview of support programs, ideally presented in a matrix format showing the various features on the left-hand side and columns for each offering, with checkmarks showing what’s included where. The purpose of the overview is as a selling tool, although it’s useful after the sale for customers to figure out what they are getting, since many times support users are not the same as support buyers. Individual data sheets for each support offering that list each feature of the offering and its corresponding benefits. Again, the data sheets are sales tools and also reference documents.
A Support User’s Guide that explains how to use support in detail. The purpose of the guide is to show the support phone numbers and web site, what to expect during a case, and any self-service information that’s appropriate. Although the user’s guide is not a sales collateral per se it is useful for more complex sales to show prospects what happens once they buy support. The overview is crucial, unless of course you only have one support offering, and in that case you may well be thinking about adding more. The Support User’s Guide is the less critical piece if you need to sacrifice something.
2. Short is better
While you may think that a 20-page User’s Guide shows how thorough and careful you are about support, many customers will conclude that it’s difficult to use support. The support overview should fit on a single page. On the hard copy, you can use the reverse page to have a pleasant blurb about support, recommend offerings for particular customer profiles, and perhaps highlight some of the more interesting features of your offerings.
The data sheets can be 1-2 pages each (so hard copies will be just one sheet) Support guides can go on for maybe 10 pages maximum. Don’t include information that changes over time such as detailed troubleshooting steps. Point customers to the web site instead.
3. List deliverables and SLAs
Answer the basic “What do I get?” question clearly. Don’t forget non-support features such as maintenance or access to the users’ group. If you have more than one offering, it should be very clear that higher-level offerings do, indeed, deliver more.
4. Include a “at a glance” section
For longer documents, include a quick reference section either at the beginning or the end. For instance, the users’ guide should have your phone number and URL clearly highlighted.
5. Make documents consistent
Make sure the offerings have the same names in all documents so there is no confusion. Use consistent layouts so customers can navigate them quickly. (Make sure to make the data sheets slightly different from each other, perhaps using color, so that customers and sales reps can easily identify that you have
6. Test the documents
Observe how new customers and prospects use the documents. Can they find what they need? Don’t just rely on the opinion of internal users or long-term customers.
7. Post everything on the web
Show the program overview on the support home site (or right off it), with the data sheets accessible from it. If you have a limited budget, dispense with hard copies entirely. If you do create hard copies, make them consistent in look and feel to product documentation
“Working as Designed”: How do you tell the customer?
This is the first in a series of support skills refreshers. I welcome your feedback on whether this type of topic is useful to you. Here’s the problem: the customer complains about a problem with the product, which appears to be a bug. After some troubleshooting the support staffer finds out that the “bug” is actually the way the product is supposed to work (and therefore won’t be fixed). What do you tell the customer?
This is a classic example of having to deliver bad news.
It would be embarrassing to tell the customer bad news only to find out that the problem will be taken care of, not to mention that an about-face will also encourage the customer to always push back in the future, so make sure that the decision is firm and takes into account such factors as the customer’s standing with the company.
2. Don’t delay
Once you know the news is bad, share it with the customer as soon as you can. Customer get very upset if they find out that information was withheld from them for any length of time.
3. Be firm
You may feel sorry for the customer, and you may even agree with the customer that it really should be a bug, but you need to be assertive and not allow the customer to think that a little pressure will result in a fix. Use a strong, assertive voice (slightly lower than your normal registry), take a few deep
breaths to steady your voice beforehand if needed, and speak a little slower than normal. Rehearse what you will say in advance so you can have a smooth delivery. Of course, bad news cannot be delivered in email, so you need to pick up the phone.
Even as you are assertive, empathize with the customer. Tailor your apology to the magnitude of the consequence on the customer. If the limitation was clearly documented and the workaround is easy, there’s no need to cover your head with ashes. Say something like “I’m sorry you won’t be able to do just what you wanted to do, I can see how it would be really handy.” If the limitation was not documented, it’s another ballgame entirely. Depending on the magnitude of the problem, you may want to ask your legal team for help on what to say. At a minimum, be very, very apologetic “I’m afraid I have some bad news on the issue you reported. I found out that the behavior is actually a part of the way the product work and even though it’s really in your way, that’s the way the product works. I wish I had better news”. If you need inspiration, think about how you would give bad news to a family member or a friend. How should a doctor tell someone they have a dreaded disease? Most “bugs” are a walk in the park compared to that kind of situation.
5. Focus on a solution
Don’t just say the product works as documented and hang up. Help the customer with workarounds or other inventive ideas. Most customers will adopt a solution willingly, even if it’s not quite what they wanted in the first place.
6. Get help
Sometimes the best way to show you care is to bring your boss along. If you anticipate a particularly difficult conversation, try a three-way call. Often, the simple fact that someone with a higher title is included diffuses anger and focuses the conversation on solutions rather than ranting. Bringing a development manager to the call can work too, if you can properly brief the individual beforehand and you are reasonably certain that appropriate customer skills will be used throughout. Especially with a technical customer, hearing the news from a technical perspective helps convince the customer that there is no other solution.
7. Take action
Undocumented limitations as well as limitations that are properly documented, but are a big pain warrant a friendly discussion with the Marketing and Engineering group. They should be addressed regardless of your wonderful skills at handling them with customers.
FT Works in the News
Sbusiness, the journal of the AFSMI, published an article I wrote entitled Stressed out A way of Life in Support Centers? in their September-October 2003 issue. SSPAnews published an article I wrote entitled Blameless apologies and other powerful support techniques. You can read it at http://www.thesspa.com/sspanews/091603/article1.asp
There’s still room in the Customer Service class I’m teaching at San Jose State University on Thursday (16th). See more information at http://www.ecmtraining.com/sjsu/courses.htm.
And I’m also teaching a 3-day Support Technology class on December 1-3 ( http://galaxy.sjsu.edu/servlet/servlets.catalogs.Catalog?PROGRAMNUMBER=2359&COUR SENUMBER=17221&CURRENTSEMESTER=13&page=PdPrograms). The location is ideal for Silicon Valley residents and tuition is nice and low compared to commercial seminars.
TechTarget aired a webinar entitled What do you want from CRM? on September 16th. You can still listen to a recorded version of it by going to http://searchcrm.techtarget.com/webcasts/0,289675,sid11,00.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.
650 559 9826