18 Sep User Support Isn’t Always a PICNIC
It’s easy to assume that a someone needing user support is not using the application correctly. What if there really is a bug?
We’ve all seen the acronyms used by support techs: ID-10-T errors, PICNIC, PEBKAC, and so on. On the one hand, they’re pretty mean-spirited (but kinda funny). On the other hand, support techs can legitimately be exasperated when rude, frustrated users scream at them to solve problems that aren’t their fault. Yes, some support techs really do have to walk users through the most basic of operations like making sure the computer and monitor are plugged in and powered on. On the OTHER other hand, it is the job of support techs to bridge that knowledge gap.
As consultants, we are often called upon to support our own or someone else’s software. We have to be the opposite of that acronymic stereotype. Users aren’t idiots; they’re experts in something we are not proficient in and vice versa.
Once in a while, we are on the receiving end of customer support, and these experiences can be real eye-openers. I remember one instance where we discovered an undocumented limitation of a mature third-party application.
Don’t get me wrong; the support techs were good people. They were not rude or patronizing, as the stereotype goes. They were just quite sure that the problem could be solved with the right combination of configuration settings. After all, this product had been in international release for a couple of years. Isn’t it fun to be an edge case? (Nope.)
Documenting someone else’s bug takes more rigor than documenting one’s own. In the case of well-established software, bugs are assumed innocent until proven guilty beyond a shadow of a doubt.
What should I do if I think I’ve found a bug? Document, document, document.
Start with the most basic information:
- What environment is running the software?
- Hardware specifications
- Operating system version
- What system privileges does the running user have? (Some applications require that the running user have at least local administrative privileges.)
- Where are the application and data files housed, and what privileges does the running user have on those file locations?
- What version of the potentially-buggy software is running? You might not be using the latest version.
- The bug in question may have been identified and resolved in a later release.
- What other elements of your particular computer and network could affect the software’s operation?
- Security software
- Network limitations or throttling by the connectivity provider
Once the groundwork is fully defined, move on to defining exactly how the buggy behavior arises.
- Start with how the application is opened, whether it starts automatically on system boot, is opened from the Start menu or task bar, or is opened automatically from within another program.
- Document every single keystroke and click!
- Take screenshots at every step.
- Better yet, use screencast software to record your actions and the application’s behavior in real time. There are plenty of free tools for this.
- Make this detailed log available when you reach out to tech support.
It is incredibly time-consuming to convince a software vendor that the bug you’ve found is real. Providing the support techs with full documentation speeds up the process by helping them rule out user error or misconfiguration.
In our case, we worked with several support techs at higher and higher levels to determine that our particular use case was not supported by the software. It hit a limitation that was not feasible for the vendor to change.Their documentation was updated to reflect this limitation, and we were able to move on and develop a work-around within the overall solution.
Sometimes a support issue really is a bug. If you think you’ve found a bug or an unsupported use case, documenting it rigorously will save a lot of time, both for you and for your support contact.