|
|
|
|
||
|
Why Customers Call Tech Support
and by Jack Molisani
Overview The high-tech industry in the United States spends billions of dollars a year staffing tech support departments, and technical writers can help reduce those costs. Although the reasons why customers call tech support varies widely
based on the type of product, for simplicity I am summarizing that
customers call tech support because either there is a problem with
the product, or because they just want to know how to do something
with the product. Why Customers Call Tech Support Customers calling tech support just because they want to know how to do something is an indication of one or more of the following: 1. There is no user documentation for the product. 2. There is documentation but the procedure the customer wants is not in it. 3. The procedure is in the documentation but the customer never bothered to look for it. 4. The procedure is in the documentation and the customer actually looked in the manual, but couldn't find the needed information. 5. The procedure is in the documentation but the procedure is wrong (missing steps, screens have changed, etc.). 6. The procedure is in the documentation but the procedure is so badly written that it couldn't be understood (different from #5). 7. There is no applicable procedure because the product
can't do what the customer wants it to. What to do? Technical writers can do something about reasons 1 to 6, and what's great is that many of the above situations can be fixed for very little time and money. Here is the list of problems again, and some sample solutions. I have also included a list of books at the end of this article that give detailed advice on how to handle the problems covered in this article. (Note: I wrote this article for the person who will be doing the writing. If you don't have a good tech writer, I can help find one for you—my contact info is at the end of the article.) 1. There is no documentation: Well that's easy—write some! Granted, you may need to "sell" your company or client on why they need user documentation, but showing your boss this article would be a good start. Then show your boss how much the company spends on tech support. Good technical communicators save companies money. We just need to convince them! 2. The information is missing: That's easy too—just add the missing procedures. 3. RTFM *: OK, now we are getting into an area that may be a little more difficult (but hardly impossible) to fix. Suppose you have worn your fingers to the bone making sure that every conceivable procedure is addressed in the user documentation, and customers are still not looking for the wanted information. Before I give you a glib solution, let me just say, Find out why. Do a small usability test, talk with your customers. It could be the RTFM customer tends to throw the doc away with the packaging. In such cases, ship the documentation chained to the product (just kidding!). * Read The "Fine" Manual—a common response from support personnel when someone asks a question that is clearly covered in the manual. But seriously, it could be that RTFM customers are simply intimidated by the big words and complex diagrams on the manual cover so they think they won't understand it so never bother to look. In that case, get a graphic designer to create more "user friendly" cover art. Perhaps you have crammed so much information on every page (shame on you!) that the customer can't confront reading the text. Perhaps the "typical" RTFM customer for your company has English as a second language or has a low literacy level. In this case, consider using less text and more "visual language" in the manual. Did your company try to save money by totally replacing the printed documentation with online documentation? Well, perhaps shipping a quick reference guide that covers common procedures and includes references to the online documentation will help the online-shy reader. In other words, don't assume that customers will read your words just because you wrote them. Investigate what users are doing with the "Fine Manual" and handle accordingly. 4. The reader can't find the information: You can solve this problem by making the information more accessible—include a table of contents, a detailed index that includes gerunds and synonyms (not just features), etc. Also, apply good structured documentation and manual design theory so users can easily navigate through the text to find the information needed. 5. The documentation is wrong: In a perfect world engineers would tell us every time they make changes before the product ships. Unfortunately, this is rarely the case so unfortunately what used to be a correct procedure doesn't work now. If the engineers are making changes and not telling you, it's your responsibility to acquire the information you need by getting on the distribution of applicable emails, meeting notifications, etc. Keep screaming "look how much we are spending on tech support!" to your boss until he/she gives you the backup you need. Then make sure you document the changes when you do get them! And what can you do if changes are constantly made to the product after the documentation goes to the printer? Well, consider using a form of online documentation that automatically checks your website and displays the correct, current procedure. This can be a complex and costly solution, but considering how much it could save in tech support costs, it might be a viable solution. 6. The documentation is badly written. It is not uncommon for a technical writer to inherit documentation that was written by the engineers themselves (shudder!). Well, you should know what to do with that: rewrite the existing procedures using numbered lists, screen shots, active voice, decision tables, etc.
Finally, once you have fixed the problems we just covered, be sure to check with tech support for before-and-after metrics. One reason is that once you fixed one problem (say, there was no documentation), other problems can come to light (such as there are now missing procedures in the doc you just wrote). Another reason is that you need to show your boss and senior management how effective your changes were at reducing tech support costs. Not only is this important for "selling" the next phase of changes you want to do, you also want these numbers to hand when it's time for your annual salary review! Again, let me emphasize how important it is to gather before-and-after metrics. One project we did for a client reduced their support calls by a whopping 95% for one complex product they sell. That project alone not only ensured we'd get more work from that client, but it helps us close new clients. When we did the surveys for the Year 2000 Pan-Pacific Conference, the number one complaint technical communicators had about their careers is that they were not appreciated by their boss or upper management. So, as a closing note on this article, let me ask you to personally do your part to show the world just how much value we as a profession do bring to the organizations for which we work. Remember, a rising tide lifts all the boats! Afterword I'm always happy to hear from my readers, so if you
have any questions or need help improving your company's documentation,
please contact me at info2008@prospringstaffing.com
or at 888-378-2333. About the Writer Jack Molisani has been a project officer in the Space Division of the USAF, the manager of training and documentation of a multi-million dollar software firm, and currently is the founder and president of ProSpring Inc., a technical communication and placement firm, and LavaCon: the International Conference on Technical Writing and Project Management. Jack teaches courses on how to reduce support costs through better documentation and training materials at Cal State University, is a regular speaker at the Society for Technical Communication (STC) and WinWriters international conferences, and was the chairman of the year 2000 STC Pan-Pacific Conference. He can be reached by phone at 888-378-2333 and by email at info2008@prospringstaffing.com
|
|
||
|
||||
|
HOME | STAFFING | CLIENTS | JOBS | RESOURCES | CONTACT
|
||||