Home > IT Blogs > US Security and Technology > Tell us your Tech Support Horror Stories…
>>VIEW ALL POSTS  

US Security and Technology

»
Nov 1 2012   6:59PM GMT

Tell us your Tech Support Horror Stories…



Posted by: Harisheldon
A+, customer support, help desk, support, tech support

Going into the IT field, we all had to start somewhere.  Helping out at school on the website, fixing a friends computer, joining the schools computer club, but that was before you graduated to the job field.  You now have your A+ and you have just been hired as a member of the help desk and you are answering the phones from customers with technical questions and you are thinking that you are going to help someone repair their network when your first customer ask you the question, “I can’t here any sound, can you help me?”.  Your bubble has been burst.  You patiently talk the customer through a simple 10 second fix, but it takes 30 minutes to finally resolve the problem, sound familiar?  Here is your chance to tell your stories, be they funny, sad, or down right scary, we have probably heard them all, but let your frustrations out here and let all read of your adventures so that you can sit back and pick up that phone and begin your adventures again.

  Bookmark and Share     Comment     RSS Feed     Email a friend

Comment on this Post

Leave a comment:

TomLiotta  |   Jan 12, 2013  2:22 AM (GMT)

I have ‘horror’ stories that I could tell; but they each cover months of analysis, customer hand-holding and dialogs, IBM dialogs and numerous in-house and remote conferences. They have attributes in common: product updates with concurrent OS updates, homogenous networking, interactions of multiple applications, etc. Each one really needs to be a detailed Case Study rather than a simple comment.
 
But less “horrible” cases did occur. In one case, a customer had altered the system SNDMSG (Send Message) command to make the target user parameter unavailable. All messages were forced to go to a specific target. Our product installer blew out in a very bizarre way that made no sense to us until we discovered that fact. We never learned why any system would be crippled in that way, but did work out changes to avoid the problem in future installs.
 
A second customer had configured their AS/400 to bypass the IBM-supplied standard system startup procedure. This included ignoring the QSTRUPPGM system attribute that held the program name that ran the startup. The product installed fine, but it was necessary to execute a product activation during a phase of system startup before TCP/IP was started. It took some real digging to figure out why system startup kept skipping activation of our product. No errors were ever logged during startup; it was just as if the system never called our startup/activation routine even though it was clear that normal system attributes were properly set. A detailed analysis of work management finally showed that the standard auto-start entry in the controlling subsystem had been replaced with a custom one that took startup in a completely unexpected direction. Who ever expects to look there? And current staff for that customer had no info on why previous staff had done it. As far as they knew, it had “always been done that way”.
 
Tom