Advice to Support: A cautionary tale

Lost words and the “known issue”1918trainwreck

Here’s a cautionary tale about support documentation. Learn from it how not to provide technical support for “issues” that arise in your  product and what to do about them. Poor communications about so-called “known issues” is will damage your reputation and can make or break you. Here’s my story about known issues.

Back when MS PowerPoint was a new wonder application,  I bought in to the message and decided to use it to prepare a whiz-bang and lengthy presentation for the CEO of a client, one of the fast-growing interstate banks in North Carolina during the 1990s. I researched and then bought PowerPoint, imagining the “wow” moment when I previewed this magic to the client.

So I set to work. Five days, 30 slides and 5,000 words later, the project was looking great. Everything was in sync, even the nearly cool swooshing sounds and fades taking the viewer from slide to slide. The script was there right along side each slide. I was just finishing up my last revisions and did a “Save.”

But, whoa! The script disappeared! I tried all the tricks I knew to recover previous versions (remember always to start the day with a new, dated  file), but none had script. Mad as hell, I did something really stupid. I called Microsoft Support.

When I explained how their program had disappeared my words, the Microsoft automaton at the other end of the line deadpanned, “That is a known issue.”

“Known by whom?” was my question. At that point, the support person directed me to a Web page buried deep within the Microsoft vaults where, indeed, the “issue” was documented. I asked, “So, you expect all your customers to search your website daily for problems with the applications you sell?”

Answer: “Well, it’s a known issue.” I can’t repeat my response, but I’m sure you have a pretty good idea of where in the person of Bill Gates I thought PowerPoint should find a new and lasting residence.

The moral of the story—something Microsoft and too many software providers haven’t yet learned—is that when your product has an “issue,” you should alert people to the problem pronto and by every means possible. All software makers know who has bought and registered their products. They have the list of emails, and an email blast to all buyers with a refreshingly honest RE:—”Alert: You should know we made a mistake”—is an absolute necessity. Unfortunately, companies and their management are uniformly afraid to admit that they aren’t perfect. The best course, however, is to get out in front of a problem in your software before it hits the many means that customers have to communicate their rage.

It’s simple, known issues are not known until everybody affected by them knows about them. Merely, putting up a mention of a glitch on your website doesn’t do the job. It’s the way to lose customers and to become infamous. You don’t want to go viral as a screw-up.

To this day, I have a hard time concealing my resentments whenever a client asks, “Could you put it in PowerPoint?”

Tagged with: , ,
Posted in Communicate Your Technology, Technical Documentation

Leave a Reply

Your email address will not be published. Required fields are marked *


* Copy This Password *

* Type Or Paste Password Here *

%d bloggers like this: