Answer of the Day

Answer of the Day – D M Goldstein, Nov 2022

Have you ever been given an answer by a service provider that just didn’t make sense? That provider could have been a car mechanic, a doctor, a software technical support engineer, or any of a million other roles. The answer just felt like they were reciting off a script and not truly listening to your problem. It’s possible they were just giving you what I’ve come to think of as, “The Answer of the Day.”

This is a common phenomenon; the department gets a series of very similar complaints which all have either a common cause or a common solution, and suddenly every problem seems to sound like that one. I’m reminded of the adage, “When all you have is a hammer, every problem looks like a nail.” They fail to see that “One of these things is not like the others,” to steal a line from “Sesame Street”.

Squeaking Brakes

One of my earliest encounters with this phenomenon was with my mother’s car when I was a teenager. She had just bought an economical car and her brakes squeaked horribly. She brought it to the mechanic at her dealership who, without inspecting the vehicle, dismissed her with the comment, “All disc brakes squeak.” My mother was not car-savvy and took this as a legitimate answer. A few months later her car rolled down the driveway into the street. Upon inspection it was determined that this was because her brakes had no pads. The squeaking she had heard was metal-on-metal, the caliper scraping against the rotor in the absence of the brake pads. The dealer’s mechanic was incompetent and presumptuous. Many customers may have had minor concerns about brake noise, but his failure to investigate this complaint was inexcusable.

Placebos

The next time I encountered this was freshman year in college. I wasn’t feeling well and went to the school’s infirmary. I’ve always joked since then that the doctor must have just read an article that one out of four college students is a hypochondriac, and I was the fourth one to walk in. He took a quick look at me and sent me away with a placebo. Well, placebos don’t work if you’re actually sick, so a few days later I returned to the infirmary. Without even asking what was wrong with me, the doctor on duty led me to a different room and showed me to a different doctor who looked up at me, then looked at the first doctor, and in unison they both said, “Mono.” It was so obvious that they didn’t even have to probe further. They were correct, and I was provided with proper treatment. How could the doctor from my first visit have missed this if it was so obvious? The answer again is, “Failure to investigate.”

The Problem of the Day

This can happen with Software Technical Support. Sometimes a bug gets released in the product, or there is a problem at the data center, and suddenly there are a lot of customers calling in about it. There can be a tendency for the staff to start seeing every incoming customer issue as related to that problem. Everything from “the system is slow” to “my data is wrong” and from “my reports won’t run” to “I can’t login” all suddenly look like the same (often unrelated) root cause or remedy. As with the car brakes and the mono, if you don’t actually look at and investigate each problem then you are setting yourself up to be a victim of your incorrect assumptions.

Addressing the Problem

How can a service provider avoid this trap? There are several required components, and they revolve around culture and training.

Stop, look, and listen: The first step is training your team to triage each new issue. In my examples above, the common thread is that the “first responder” failed to assess the problem. Instead, assumptions were made that “this problem” was just like “all those other problems.” It takes a little more time to investigate each new problem report, but it avoids the trap caused by incorrect assumptions.

It’s not fixed until it’s fixed: It’s not enough to answer a question, even if your answer is technically correct. People come to service providers to solve problems. Until and unless you solve the problem, and confirm that it is solved with the customer, then you are not done. This seems like it should be common knowledge, but sadly it gets overlooked by too many providers. In my article “Managing Technical Support Teams” I wrote:

If somebody asks, “Does this road go to San Jose?” then a correct answer could be, “No.” But that is also a completely useless answer. The Lesson: Always try to answer the problem, not just the question. A better answer might be, “No, this road goes to San Francisco. This other road goes to San Jose. Where are you trying to go?”

Change the casters: This goes back to my early days when I worked for a computer hardware company. In addition to the above paragraph about solving the problem, there is another rule that, “It’s not enough to fix the problem, you must also fix the customer.” We had a customer who had had a series of problems with their computer-room-environment system. Our engineer had replaced several boards during his efforts to resolve the issue. The customer said, “You have changed everything in this cabinet except the casters.” At first, we thought this was a humorous comment, but the customer was serious. They were not going to be convinced that their issue was resolved until those wheels were swapped out. On a different occasion we had an engineer show up in a customer’s computer room and repair a head crash. The customer subsequently called the Branch Manager to complain; the engineer never checked in with the customer before leaving to let them know the problem had been resolved. If there is no communication between the service provider and the customer, then how will either of them know whether or when a problem has been resolved? Just like “Answer of the Day” responses, the lack of closure and confirmation means the problem from the customer’s view remains unresolved.

Unconscious habits

There are people who have habits that they might not be aware of or consciously control. It could be smoking or over-eating or anything else. For the smoker or over-eater, there may be a subconscious hand-to-mouth need that rationalizes itself if a cigarette or snack is in that hand. I’m not accusing all smokers or over-eaters here; I’m saying that this may be true for a subset of those populations.

For the over-eater, the question is, “Are you truly hungry, or do you just think you’re hungry?” Their brain might be saying, “I’m sitting watching TV and therefore I should eat,” even if their stomach is saying, “Hey, we just had dinner and I’m full.” They may have conditioned themselves to believe that they are hungry, and therefore they should eat. That “I should eat” response is just like the “Answer of the Day” – the person is getting a signal that feels like the hunger signal and is acting on it in error.

This is not an article or lecture about diet. This example is another illustration of things to look out for. Beware of seeing one signal and misinterpreting it as another one. “Any time a customer sees ‘this’, it’s because they have done ‘that’,” can be flawed reasoning and result in giving an “Answer of the Day” kind of response. Be careful to avoid one-size-fits-all answers; not all problems are generic that way.

Watch for the signs

Knowledge management and customer self-help systems are wonderful. Providing proven answers to common problems is a time-saver for customers and a cost-saver for providers. But watch for signs of “Answer of the Day” resolutions. If there is an article that either is suddenly growing in popularity or is referenced often, you may want to spot-check the issues it is being used to resolve. Make sure that it is a true and accurate fit, and not just a blunt-force hammer hitting everything that resembles a nail. Having a prompt, “Did this article resolve your issue?” at the end of every article is a useful tool. Looking for boomerang questions that come back to Support after the article has been provided is another feedback mechanism to determine whether that article is being misapplied.

Most importantly, make sure that every new issue is being triaged and investigated before stock resolutions are being provided. Some of these things are not like the others.