Tales from the Field: Real (but funny) stories told by MSP Field Techs!

In the world of computers, there is almost always an easy solution: user error. I’d like to clarify right now that this is not a manifesto about how “computers are more helpful than people,” where I start quoting lines from I, Robot and AI while completely missing the point of those films. User error is usually the issue with consumer-facing products because consumers aren’t interested in how something works, they’re interested in why their tool currently isn’t working. In their haste to get their task done, they often don’t stop to see if they’re the one at fault, so most of the time I immediately check in with them to see what they might have done wrong. Unfortunately, sometimes this approach backfires.

I was sitting there at my desk, writing a manifesto about how robots are more helpful than people when a customer, who we will name Ashley (because that was her name) asked me about the database. I was on-site checking on another person’s internet connection, and waiting for them to complete their own few start-up steps, and Ashley walked up to question me in my downtime. The database in question was a very simple one, set up to allow the consumers to check basic info on their clientele, such as names, product, and times.

Ashley approached me and said that classic line of “It’s not working”. Ah, such description! A phrase that both tells you everything and also tells you absolutely nothing. The phrase “it’s not working” is one that implies that the questioner’s life is currently being inconvenienced while they have nothing to do with the problem. Such a statement is so abstract that it could be considered poetry.

“Well?” she repeated when I realized I had spent an actual 30 seconds in real life thinking about the phrase. I suppose we were now even on the scoreboard of helpfulness.

“What exactly did you try to do?” I prodded, immediately going for the user-error approach. Our database was a simple one, and a person using a bland, useless descriptor immediately suggested that they were in the wrong, or at least didn’t understand the product.

“I tried using it.”

“Right. You tried using it. Well, why don’t you go back to your computer and restart it?” I offered one classic line for another.

“But it’s not working.”

“I understand. If it’s still ‘not working’” after a restart, come back and ask me about it.” I insisted that Ashley do her own basic work because of the database’s simplicity – it wasn’t a complicated schema, and I also hadn’t received a bunch of calls from other clients claiming that it was an issue. What else could it be? Of course, she came back again a few minutes later and insisted the issue was not resolved.

At this point, I resolved to get her to give me a better description, but she insisted that I check my own end of the system. I knew this was a little hasty to do, but I wanted to appease her in our own little negotiation, so I immediately began clicking on a few windows on my screen to look busy while asking her for the actual steps she had performed on her own end.

“I tried just doing a basic query.” Before I could respond, I noticed that my own query of the DB’s status description had returned “OFFLINE”. Ashley hadn’t been playing coy or being childish. She was 100% correct in telling me that “it wasn’t working.” I changed the value to “ONLINE” and told her that the issue was fixed. As she walked away, I sheepishly threw my manifesto into the trash can.