It turned out the user hadn’t read the updated documentation about a new procedure required to set up reports. In the tech world, this is sometimes knows as a “user error.”
We used to categorize user errors as ID-Ten-T, which was a hidden jab at the user because when spelled out it becomes ID10T or "idiot." Many developers must feel this way because there is a Wikipedia entry for “user error.” This cartoon immortalizes the frustrations of developers and customer support folks throughout the computer age. I imagine there are a few Dilbert cartoons on the topic.
As our support phone started to ring more often, the less interested the bunch of us were in answering it. And our manager was smart enough to not set this phone up with voice mail. It would just keep ringing.
I can hear it in my head – “beep boop beeeeeep.” Blah, the memory gives me chills even today.
Once they did answer, my teammates weren’t as patient as me. Some of them got into screaming matches. Many of these “conversations” resulted in hang-ups – on both ends.
Until one day our manager visited us with a disapproving look on his dour face.
“I’m getting a lot of complaints that the phone isn’t being answered. And I’m hearing you aren’t very nice when you do answer. One gal said she was called ‘clueless’.”
We all starred into space hoping he would realize his grave mistake and just take away the phone. No such luck.
Instead, he said we had to answer by the third ring and he didn’t want to hear more complaints.
Trying to make the best of it, we created our own system of taking turns and tried to be helpful – and not (overtly) condescending. But it didn’t last – management finally threw in the white flag. I’d be lying if I didn’t report we all did a happy dance when that damn phone was finally removed. I’m sure the end-users did their own happy dance.
This all happened over 20 years ago. Today, the times are a-changing.
It is becoming the norm for developers to start their own companies with very little support resources because the costs have dropped dramatically due to open source, freeware and affordable apps hosted in the cloud. Plus, for mobile app developers, many of them are one-person shops and therefore must provide their own customer support.
We couldn’t afford a customer relationship management (CRM) system back then to track and learn from support calls. But today you can use a CRM for free or for a low monthly fee from the cloud. There are also low-cost tools that allow developers to quickly diagnose a root cause or see it for themselves using a remote access tool.
However, there is no substitute for well-trained customer support professionals with well thought out procedures to ensure end-users receive the best assistance. But the question is: should developers do this customer support? My view is that, until an issue is escalated to a third or fourth tier of support, developers should focus on writing and testing code.
Otherwise, be prepared for more ID10T classifications, from both the users and the developers.