Got a problem that calls for Support?
Do not wait until the last resort.
Do not sit around and cavort.
Do not consider project abort.
Do not wait and come up short.
Call for Cliff and get a good report.
Who is Texaport Cliff?
Why, it's Cliff Anderson, the guy who has been providing Tech Support for over 25 years.
What are the golden rules of Tech Support?
- Listen to the customer and allow them to vent.
- Never make assumptions.
- Take notes with no descent.
- Ask questions about the event.
- What hardware, what firmware, what software and what who when where.
- What precise error messages did the software present?
- What lights are off, on and blinking without relent?
- Is the problem always or intermittent?
- Never make assumptions that you can prevent.
- If the problem isn't solved, explain your intent.
- Leave the customer with some workarounds you invent.
- Ask them some questions to answer to a greater extent.
- If the problem isn't resolved, duplicate the event.
- When a development problem is identified, promise assent.
- Define the problem and details, revisions, and logs to Development.
- Follow up until the problem is resolved 100 per cent.
Why is he a great Texaport guy?
Allow me to list the reasons:
- My experience ranges from board-level troubleshooting to debugging firmware to resolving system-level configuration problems.
- I learned COBOL, Fortran and 6502 in high school.
- I debugged a keyboard/display board and memory board from schematic prototype to production.
- I learned the following assembly level languages with a manual and compiler: 8080, 6502, 186, Z80, 68020 and 8X305.
- I have supported at least 90 products. Many of these products I supported from Beta to Obsolescence. These include protocol converters, channel interfaces, firewalls,
remote controller, biometric entry systems, VOIP PBX systems, CDMA and GSM/GPRS GPS devices.
- I have solved problems on PCs, Macs, IBM Mainframes and Midrange Systems.
- I have written hundreds HTML pages by hand, in notepad, for fun.
- I am able to quickly rule out problem causes and narrow down to the root problem, be it hardware, software or configuration.
- When a development problem is identified, I have the skills to clearly define the problem and provide the details to the development group.
- I work well with engineers and sales people.
- I relate to everyone from Baby Boomers to Gen-Xers.
- I am meticulous in documenting procedures and guides.
- I never make assumptions.
- Most importantly, I am diplomatically honest and I know how to listen.
|
What causes most problems?
Communication
Nearly every troubleshooting problem can be broken down to a communication problem. Whether the hardware isn't communicating,
the software isn't transmittng or translating correctly. The firmware is telling the hardware something wrong. It is some sort of a communication problem. Sometimes it is a configuration problem
in which case the User Manual or User Interface did not communicate well. Either the user did not understand the instructions that the user interface conveyed
(which might indicate that the user interface is not intuitive or the wording or training could be improved). If the unit is broken, it still is not communicating.
No matter what the connection protocol and hardware, whether it is some sort of cabling (RS232, Dataproducts parallel, Centronics parallel, V.35, Twinax TDLC,
Coax cable (ArcNet, Token Ring, Ethernet) or over the air (Wireless wiFi, CDMA, GSM/GPRS, GPS) or it is a device to device communication breakdown.
This allows you to break the break the problem down to see how far the signal (or message) got. Sometimes signals transmit but the response path is broken.
You have to ask did anything happen? (Screen changed, lights blinked, etc.). This is how you narrow down the cause of the problem.
Device-to-device breakdown Causes
Hardware
- Poor soldering
- Component failure
- Excessive voltage
- Exposure to elements
- Corrosion
- Distance (and this can be too long or too short, too far or too close)
- The strength of the signal and the signal-to-noise ratio
Firmware
Translates the hardware signals (keyboard or other input) to the hardware output. It is software imbedded in hardware.
- Number of data bits
- Number of start bits
- Number of stop bits
- Speed or baud rate of transmission
- Character code (EBCDIC, ASCII, baudot are most common)
- IP address
- Subnet mask
- VPN port filters
Software Misconfiguration
This varies depending on the questions posed to the user. Any question not answered or answered with the wrong number of characters could be at fault.
- Number of data bits
- Number of start bits
- Number of stop bits
- Speed or baud rate of transmission
- Character code (EBCDIC, ASCII, baudot are most common)
- IP address
- Subnet mask
- VPN port filters
Structure of a Tech Support call
This is the basic structure of a tech support call.
- Greeting, identify yourself.
- Allow person to explain, if necessary. Listen, take notes. Write questions.
- Ask open-ended questions. Listen, take notes. Write questions.
- Take control of call by asking closed ended question. Write questions and answers.
- Ask enough questions until you have some that they have not or cannot answer.
What is the problem? Example: System keeps stopping.
- Why is their site unique? Example: We have a bad Internet connection or we have
lots of data, etc.
- When does it occur? Example: Morning, noon, night, after you enter the address, when
someone is doing something at the same time.
- Where does it happen? Example: After you press Enter.
- Review what is known and not known.
- Ask them to verify what is questionable. Do not allow assumptions.
- Find answers to unknowns (Example: what version software, explain how).
- What is the best way to reach you? (Always get email)
- What I will do.
- What I will need from you.
- When can you expect to hear from me.
- How you can reach me.
Cliff's References
Upon request.
Email Cliff:
My name is Cliff, drop over sometime.
Cliff's LinkedIn profile
|