Tamara Wilhite is a technical writer, industrial engineer, mother of two, and published sci-fi and horror author.
I've worked for more than a decade in IT tech support on everything from shop floor data management software to CAD software to Sharepoint. I've worked in software testing, software documentation, software training, first level and second level tech support. Here are a few real world tech support stories that inspired my IE in IT blog with the IISE, after these experiences demonstrated that process improvement was an obvious necessity in IT.
The Wrong Expert
I was dealing with an unfamiliar error and asked one of the system administrators for advice. He said, “Go ask that big brain in the sky for an answer, not me.” I cited the chief system guru’s name. “No, not him, Google. Go Google it.”
Prove You're You to Get Support
When modifying someone’s permissions on a key system, it was necessary to verify the person’s identity. One day, I received a phone call from an unfamiliar phone number, claiming to be a customer and requesting additional privileges. I said I’d verify. I called the user’s listed phone number and didn’t receive a response. I called her manager, and she said the user should be at her desk sometime later today.
The unfamiliar number called back. “You have to up my authority and reset my credentials, too, because I am having problems logging in.”
“Excuse me while I research this.”
I called the user’s boss who said she was probably in the office, and coworkers said she was working today. The customer hadn’t responded to my voicemail, but the phone number where the caller claimed to be her wasn’t her work phone, cell phone or even personal phone number.
This was a classic example of phishing, where someone called in to a help desk claiming to be an employee and requested credentials so they could then log in as the employee. I hung up, called the employee and left a voicemail to inform her of the issue, informed her boss and closed the ticket I’d created for the matter with a note for security.
My boss called me into his office. “Why haven’t you helped X?”
“Someone from an unknown number is claiming to be her, asking for reset credentials and additional privileges. Per security protocols, I left the locked account locked and notified everyone.”
“She was at a customer site and needed additional privileges for a demonstration. She then locked the account due to attempts to log in with an admin account and failing.”
“I’ll tell X. Then he’ll have the fastest closure of a security incident this week.”
What Does It Take to Make It Work?
The controls in the sound booth at church where my husband works as the AV director did not seem to be working correctly. The man trying to get the right combination then exclaimed in frustration to my husband, "What does it take for this thing to work?"
"An act of God," my husband replied.
Proactive Administrative Assistance
One of my tasks working on the help desk was monitoring systems for unusual activity and reviewing reports for repeated login failures. Customers were often surprised that I’d call them for multiple repeated logins, asking if they needed assistance resetting a password.
Sometimes they admitted fat-fingering it or saving an old password that then failed to work after they reset their own password. In other cases, they were glad for the help. On more than one occasion, I called other administrators to remind them that the admin passwords had changed and that’s why they couldn’t get in. Hey, it’s a legitimate issue that counted toward the ticket count, too.
A Gap in the Process
“Why are you creating a ticket for necessary changes to the user documentation?”
“I can’t find any other way to let you know it needs to be changed, and you’re the one who does all the updates anyway.”
After that, we developed a clearer way to collect suggested edits from users to the documentation.
So That's Why It Isn't Working
My children learned early that Mommy fixes computers. When picking up the children from daycare, one of the staff asked if I’d look at the computer in the preschool room. It had been acting up, and now it wouldn’t come up at all. The screen and keyboard looked fine, which is amazing given how much damage three to five year olds could do. Then I opened the protective box that surrounded the hard drive - and found it empty. “I think I figured out why the computer won’t turn on.”
I Know Where You're Going
I periodically wrote first level helpdesk scripts for various engineering software applications. These ended up being used by the group that took over the first level tech support calls routed to our group if it needed to be escalated. On more than one occasion, I would call in an issue and hear the person start the script.
At this point, I would say something like, “Go to around step 15 and you’ll see that you need to route this ticket to queue ABC. It will go to so and so to be resolved. But since I cannot input this ticket for that group, I’m calling you.”
After a moment of confusion, the front line tech support person asked, “How do you know that?”
“I wrote the script.”
Well, That Works, Too
“With that kind of error, you’re going to need to refresh –“
“OK, I hit the reboot button.”
“I meant refresh the browser session, but that will work, too. It just takes longer.”
When I was working as a software tester on a system interface between two tools, I realized that the language barrier had resulted in an error. And no one else thought it was worth the cost to fix when we’re trying to get data imports and reports to work correctly. But every time I did a data import, it put up the bright notification box “pooling data”.
Incentives and Their Impact
The downside of measuring the productivity of software testers and developers by the number of defects they document is how often they’ll record documentation errors, corrections and advice as software defects. These were rarely “screen shot on step 8 of procedure is now out of date” but “grammar error on first sentence of step 10” or “I think this wording would be more clear”.
When Customer Service for Problems Creates New Ones
In my effort to help customers who reported problems to me that weren’t my job, I would regularly input ticket for them to the correct group. One of the downsides of trying to input tickets for users who called me when we outsourced first level tech support to another company was the sheer number of mistakes they made due to misunderstandings. Once in a while, they misunderstood and listed me as the person with the problem instead of the customer because I was the person “reporting” it. In other cases, they tried to assign the ticket I’d had created for the user to the user, which in itself generated significant confusion.
The record was having five tickets assigned to me that I had input for other people in one day. “You don’t understand, I’m not the one with the account problem. You have five different users with this problem, and none of them is me.”
My personal record was both submitting the most tickets to one specific support team and closing the most in my department in the same month, and no, closed issues weren’t all the ones that I sent to the other team. Then they finally decided to train their people better to reduce the misrouted and incorrectly assigned calls.
Out of Touch
I needed to input a ticket with the software vendor and ran into a double bind. Their website was down. I tracked down a customer service phone number, and the number took you to a recording directing people to the website. I finally tracked down a sales department phone number and reached a human. I tried to describe the problem.
“Ma’am, we’re in sales. I can’t help you with tech support. Have you tried –?”
“I tried your phone number and it says go to the website. I tried the website and it is down.”
“That’s still a technical matter.”
“Your company has no working way to reach help for a support issue – the reason I tried these other avenues in the first place. At this point, I consider it a customer service failure.” She documented the issue and sent an internal email to one of their technical support staff.