Mar 142017
 

Icon of angry person making smartphone call

The high-tech industry in the United States spends billions of dollars a year staffing tech support departments, and we as technical communicators can help reduce those costs.

Although the reasons why customers call tech support vary 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.

Customers calling tech support just because they want to know how to do something indicates 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 it up.
  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, screen 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.

There is nothing we as technical communicators can do about reason 7. But there is something we can do about reasons 1 to 6 (and, I believe, we are obligated to as a profession), 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.

  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 and talk with some of 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!).

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.

  1. 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.
  2. 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 list 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.

  1. The documentation is badly written. It is not uncommon for a technical writer to inherit documentation 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!

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 my 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 boats!

* Read The “Fine” Manual—a common response from support personnel when someone asks a question that is clearly covered in the manual.

About the Author

Headshot of Jack MolisaniTwitter

Jack Molisani

Jack Molisani is the president of ProSpring Technical Staffing, an employment agency specializing in technical writers and other content professionals, and is the author of Be The Captain of Your Career: A New Approach to Career Planning and Advancement, which hit #5 on Amazon’s Career and Resume Best Seller list.

Jack also produces the LavaCon Conference on Technical Communication Management: https://lavacon.org

Jack is always happy to hear from readers, so if you have any questions or success stories to share, contact him at Jack@ProspringStaffing.com.