Good support is that gem of technical trivia that hits the bull’s eye on the first shot—a precision-launched silver bullet that notches a perfect score and in slap-down style declares match over, what next?
Bad support is an infinite loop of phone calls, emails and web forms that leave you drifting aimlessly for weeks at a time far from your destination of problem resolution. This barrage of communications is of no value except to Maxtor, Seagate and Western Digital, who profit from the sale of hard disks where the unending discourse is archived due to corporate anal retention policies.
And ugly support, well that’s just bad support delivered with an attitude.
Those of us in the business of bits and bytes need to be acutely aware of how users perceive our support endeavors. You may say, “Why me? Support is someone else’s job. I’m in . . . [choose-you-own-non-support-discipline] product development, marketing, management, keyboard polishing and mouse alignment, etc.”
But if you’re reading Datamation, someone’s going to think you know computers even if it’s just Uncle Waldo asking over a holiday dinner why his password is rejected when he types a string of asterisks.
To ensure your ‘customer’ gets the best possible help, here are ten secrets of successful technical support:
1. Crisp, Clear, Concise Communication
Your college roommate may understand the admonishment:
Dude, bad juju about yr mouse not sync’g with Vista after a snooze. It happens! Yr drivers cool, right? Could be a Bluetooth thingy. Have you revived the AA’s in that rodent? MS has a hotfix that could save the day. Give it a whirl.
That advice will likely be meaningless to a broad audience, including someone from the other side of the globe whose primary language is something other than English. Or someone who is on day two of a new job that includes a Bluetooth mouse.
Dispense with text-message slang in favor of clear, concise prose:
The failure of the Bluetooth mouse to re-connect following hibernation under Windows Vista has been reported by other users. Ensure your drivers are up to date. If you have other Bluetooth devices, check to see if they reconnect after hibernation. Check the batteries in the mouse and replace them if they are weak. If the problem persists, try the Vista hotfix that Microsoft has posted at http://support.microsoft.com/kb/941997/en-us.
2. Waste No Time
We all have probably been on the receiving end of trivial, time-wasting, you-must-think-I’m-a-hockey-puck advice. In the medical profession, it’s the classic “Take two aspirins and call me in the morning.” In the computer industry, it’s “Restart the computer,” “Reinstall the application,” “Replace the power plug,” “Rewire the building,” or some other worthless admonishment.
In most cases this type of advice does nothing but get its giver a day closer to retirement while the recipient is left grappling with the original problem.
Strive to give users information that will advance the cause of solving the problem instead of some cliché response that merely wastes time and heightens frustration.
If an immediate answer to the user’s dilemma doesn’t come flashing before your eyes like pop-up ads for Netflix, at least give the customer a sense of what’s happening behind the scenes with regular updates. Perhaps you’re searching a knowledgebase, trying to reproduce the problem, waiting for a response from the author of the code or convening a committee of Nobel-prize winning scientists. Whatever you’re doing, post regular updates rather than leaving the user wondering if you’ve become untethered from the worldwide telecommunications network.
Next to prescription narcotics, periodic status updates go a long way to alleviating the frustration of a distressing situation.
4. Remote Session
In the distant past (a few years ago to be exact but in the computer business anything more than 30 minutes qualifies), the best options for diagnosing a remote user’s problems were telephone calls, log files, and emails (with screen shots, if you were lucky).
Today if the problem computer is connected to the Internet, you can investigate the crime scene by examining the computer through remote session software.
Without a remote connection, you may be faced with an ad nausea exchange of telephone calls and emails to diagnose a problem as simple as the user attempting to run a Windows 2003 Server-only product on Windows XP, something that would likely have been apparent within seconds of establishing a remote connection.
Make a remote session the top gun in your arsenal of troubleshooting ammunition. Everything else is small arms fire.
5. Assume Nothing
When your life evolves around a niche software product such as JGSCMPHACLSE (Java Graphical SQL Client for MySQL, PostGreSQL and HypersonicSQL with Automatic Class Schema Evolution), it’s sometimes easy to forget that not everyone spends all their waking hours keying and clicking in the world of JGSCMPHACLSE.
When a user calls to report that a Java I/O exception message appeared after she clicked the Edit button within the Properties dialog of the Advanced tab of the Options panel of the Configuration module of the SQL Query component of JGSCMPHACLSE, don’t assume that the user flawlessly executed all of the steps leading up to the failure point.
On the contrary, cross-check and double-check all preceding steps and prerequisites. You don’t want to find yourself spending two days debugging the Edit button within the Properties dialog of the Advanced tab of the Options panel of the Configuration module of the SQL Query component of JGSCMPHACLSE to then learn that the user was attempting to run the product on Java 1.4 but the minimum requirement is Java 1.6.
Your mantra here: verify then analyze. Verify the operating platform and version; verify the software product release number; verify the service pack levels of the operating system, the product and any required third-party components.
You may be tempted to assume that the user/administrator has already performed this type of due diligence before lodging a support call but when a system consists of a dozen or more myriad applications and an enterprise includes hundreds more, something as trivial as a version mismatch can easily escape the wary eyes of even the most astute system administrators.
6. Do No Harm
Practitioners of computer wellness must share at least one tenet with the healers of human maladies – do no harm.
When you’re ripping out DLLs, hacking the registry and editing system parameters, it can be easy to make matters worse either through a mis-keyed entry or an insidious side effect from a change in the system state.
To help guarantee that your prescription for a cure won’t be worse than the disease, try to preserve the current condition as much as possible. While it may be impractical to clone the problem computer in toto, at least backup system directories, record settings and parameters that you’ll be manipulating, and copy files that you’ll be modifying.
In the event that the fix doesn’t do its job, you can fall back to the original problem state and concoct a plan B for restoring wellness.
7. Map the Trail
If you spend days navigating unfamiliar barren land, dead-ends, box canyons and deep crevasses, chances are you’ll draw a map and write a journal. The next time you need to make that journey, you’ll have a direct path to the destination rather than a random walk of false starts, futile side-trips and ceaseless backtracking.
So too with the journey of solving a technical puzzle. When you finally reach the promised land of problem resolved, take time to draw a map and record a journal and attach those notes to the problem record or ticket. The next time you or one of your colleagues is dropped into this ‘unfamiliar terrain’ via a desperate user’s cry for help, the directions from your previous trek will guide you to the destination without bushwhacking new trails.
If web-based forums and knowledgebases helped set your compass straight, consider reciprocating by contributing your own hard-earned experience to the information pool. You needn’t become a guru-level member of a forum but a short note describing what worked for you (and what didn’t) will help those who may have to follow your footsteps. And if some desperate user opts to check that forum or knowledgebase before calling you, well, that note may have just saved you from answering a support call.
Remember the old proverb “Give a man a fish and you feed him for a day, give a man a stick of dynamite and you feed a village.” Or is it “Give a man a fish and you feed him for a day, give a man a fleet of trawlers and you feed a nation.” Whatever. In any case these pearls of fishing wisdom apply to computer support as well as to angling, and I’m not talking about weaving fishing line with vintage-1995 10Base2 Ethernet cable.
When you answer someone’s question, give them more than just a list of esoteric instructions that traverse a narrow path to the problem solution. Give them the what, how and why of the solution, so if the problem manifests itself again—perhaps under slightly different circumstances—they’ll recognize the symptoms and solve it themselves.
Here’s an example of giving without teaching:
You observed an “Error applying transforms” error message while attempting to run an Adobe Reader update.
To fix this problem, run the kb404307.exe utility from the Adobe website.
And, the alternative, giving and teaching:
You observed an “Error applying transforms” error message while attempting to run an Adobe Reader update.
A problem in the Windows registry may be present if the “Acrobat 8.1 Japanese OCR Update” and/or “Adobe Acrobat 8.1.2 Security Update 1” have been applied to Adobe Acrobat 8 or Adobe Reader 8. Affected users will not be able upgrade to the latest version or repair or uninstall the existing version while this problem persists. This problem does not affect the correct functioning of the installed application, and no other application is affected.
To fix this problem, run the kb404307.exe utility from the Adobe website at http://ardownload.adobe.com/pub/adobe/acrobat/win/8.x/8.1.2/misc/KB404307.exe.
In the latter case, the user has a better chance of being self-sufficient should they encounter the same or a similar problem.
9. Follow Up
After you’ve spent 40 days and 40 nights trying to resolve a user’s problem, you owe it to yourself and your technical support compadres to find out if the proposed solution solved the problem.
If the user hasn’t responded, you may have to switch roles—you badger the user instead of the user badgering you. Don’t assume that the proposed solution solved the problem because you have heard nothing. Perhaps the user no longer cares about the problem because he has retired to an island in the Caribbean after winning the PowerBall lottery or she has been reassigned to another job or – God forbid – your software has been jettisoned in favor of a competitor’s product.
Take a few minutes to follow-up and get a final update. Leaving the problem discourse open-ended is like taking a rain delay in the bottom of the ninth inning and never finishing the game.
10. Make It Better
You’ve contacted the user. You’ve seen the smoking gun. Perhaps you’ve even pulled the trigger on your own computer to see the damage firsthand. Now, depending on your role, the nature of the problem, and the structure of your organization, you may have to set aside the hat of code troubleshooter to don the fedora of code fixer.
Before breaking out the repair kit, you need to take the vows of good design and well-crafted code. The fact that you have been helping some befuddled user is often the consequence of poor design and sloppily written code. You don’t want to propagate bad practice. And if you’re not sure what constitutes good practice, leave the job of fixing the code to someone else.
Good practices in software development and maintenance include writing code to prescribed standards. Use alignment, indentation and comments in a manner consistent with the existing code.
While the primary goal of software is to accomplish an intended function, just as important is that it be maintainable since maintenance accounts for 80% of its lifetime. And to be maintainable, it must be readable.
With regard to function, well-written programs check return codes from all calls to operating system functions and APIs. You may be tempted to skip a check of the return code from a call to write a record to a file your program just created because you know the file will be relatively small. But that snippet of code that has never failed in your test environment may not work so well in version 17358 of the operating system (or on some media that has yet to be dreamed of).
Readability and checking return codes are just two items from an extensive list of software best practices. Become a learned master of the software craft so the hours you log at the keyboard unraveling code, fixing faulty logic and reassembling source modules will result in working, bug-free programs and happy users.
Giving support and getting support is part and parcel of the job of Edward J. Joyce, a principal software engineer at CA, Inc.