Should software developers do customer support? Post your opinion in the Comments section below.
A ringing phone can be a developer’s worst nightmare.
If you’re lucky, it’s just a ticked off significant other. Or your mom calling because you haven’t called in a month. Or even someone selling a hot piece of property in the Nevada desert.
Then there is the type of call that makes most developers squirm -- a call from a customer.
Not just any customer, but an unhappy customer. Or worse, a confused or clueless customer.
The good news for most developers is that, typically in a structured environment for medium to large organizations, there is a customer support group that handles incoming questions from software users.
Thank goodness for that, because in my experience developers would prefer to have a root canal rather than speak directly to a customer. So imagine the discontent of a group of developers whose manager just plugged a phone in the middle of this small band of techies and proclaimed it the customer support hotline.
If my memory serves me, the quotes went something like this.
“You have got to be kidding me!”
“What a moron. I am not answering that phone.”
“I can’t wait to screw with customers. This will be fun.”
(I left out the obscenities to protect our younger readers. But they were numerous, salty, and at the level of your average drunken sailor.)
There were four of us developers squeezed into a two-person office. We all just wanted to code and be left alone.
But our manager was raining on our parade. He literally put the phone in the middle of the room on a little metal stand. His statement about the process for answering the phone was quite simple.
“Our customer support team won’t be trained on the new software release for a few months, so you all will have to share in supporting the application for now. Whichever one of you isn’t too busy should answer the phone. I’m sure you smart guys can handle this. Have fun.”
Fun? Like having a wart frozen off your nose kind of fun?
There was no guidance provided on how to keep track and prioritize issues. In his view it was a no-brainer. He just expected us to solve problems while on the phone. Seriously? We all just looked at each other when he walked out and let loose with the aforementioned colorful comments.
I was the most accepting of this inconvenience because I had been a help desk intern supporting scientists using a supercomputer. And in my experience scientists were absolutely the worst customers because they knew they had to be smarter than the help desk person -- resulting in an air of superiority and very little patience.
So that experience didn’t make me want to answer the phone. But I figured….how bad could normal business end-users be?
Turned out they were pretty bad.
When the phone first rang, my one co-worker joked “Hey, it’s your mother, you better answer it.” I shrugged and answered the phone. The conversation went something like this.
Me: “Help desk.”
User: “Uh, yes, hello. I need help. This new release isn’t working.”
Me: “What‘s the problem.”
User: “I don’t know. That’s why I’m calling you.”
Me: “I mean can you explain what isn’t working.”
User: “It’s just not working. The new release seems to have broken the reporting function.”
Me: “Okay, I understand you think it isn’t working, but can you provide me with some details.”
User: “No, I don’t ‘think’ there is a problem, I know it because it used to work and now it doesn’t.”
I tried to hide my exasperation. Really I did. But it wasn’t easy.
Me: “For me to help you, I need for you to explain to me what is happening on your computer that you believe – I mean is – causing the problem.”
User (with more exasperation than even I was feeling): “It just isn’t working. The IT guy installed the release and now it isn’t working the way it should be. I need you to come here and fix it because I need to provide reports by tonight.”
I’ll exceed my word limit in this article if I described the entire conversation, so I’ll save you the excruciating pain I experienced that day. To complicate my efforts, my office-mates were laughing the entire time and making obscene gestures.
Good thing the caller wasn’t my mother!
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.