One summer while I was home from college, I worked as technical support for a satellite TV company. As far as customer service jobs go, it was great. It paid a pretty good starting rate (about $14/hour in 2016 dollars), with decent benefits and opportunities for advancement. The call center was in a building which used to be a shopping mall, and the facilities were very nice. Overall a good place to work.
Now, if you’ve ever worked retail, you know how… colorful the general public can be. Working in a national call center, where anyone in the entire US will call if they have a technical problem meant chatting up the all the most special people this great nation has to offer.
In a few short weeks on the job, I’d had more ridiculous conversations than I would have ever thought possible. Some examples:
- Guy called from his bathtub asking for help with his signal. His TV (a CRT in those days) was sitting on the edge of his tub, plugged in. I could hear the water swishing during the conversation.
- Lady whose cat vomited on her receiver and bricked it. This was the third time it had happened, because the cat liked to sleep on it and she didn’t want to shoo the cat away.
- People who called to complain about other companies for some reason.
- People who hadn’t paid a bill in 3 months wondering why they’d been disconnected. They were often incredulous that they would need to pay to get the service turned back on.
- Angry people reporting that we’d fraudulently billed them for some adult PPV movie at a day and time they were out of the house. More than one ended like this: “Was there anyone home at the time?” “Well, just my son, but he’s only 13, why would he order… uh… ew… um, let me call you back click”
Anyway, the experience has had a lasting impact on how I approach customer happiness. Understanding how diversity of experience and expectations affects the ways people relate to and use a product is crucial for customer retention.
One call in particular stands out in my mind as a solid teachable moment. The pattern actually comes up from time to time in support, enough so that I’ve given this class of issues a name: “Dish on a Pole Support.”
I Watch Mah TV With a Dish on a Pole
One day I get a call from a guy who was having trouble getting a signal to his receiver. This is probably one of the most common issues people have, and we had an entire troubleshooting script devoted to it.
By this point, I’d learned to ask a few probing questions that weren’t on the script. Questions like “can you flick your light switch a few times and tell me what happens?” might sound silly and unrelated, but when you’ve had multiple people call you in the middle of a power outage to ask why they can’t get a signal, you learn to never underestimate the public’s lack of technical understanding.
In this case, I heard a steady background noise, which sometimes is a bad connection, but often turns out to be weather-related. So I asked my first question: “What’s the weather like out there? Rain, hail, high winds, anything like that going on?”
“Oh, no sir, nothing like that.”
Now, sometimes people know where that line of questioning is going, and they lie for some reason. Like, maybe I’ll set DISABLE_IN_STORM=FALSE somewhere and things will magically work again. But for whatever reason I took his word and just jumped into the script. The guy was able to run diagnostics and read off numbers, but the numbers he was reading back were weird. I had to have him read them back a few times to confirm.
During training it was never fully explained what these numbers actually meant, just that they should be within some particular range. This guy’s readings were not only well out of range, but were fluctuating. I’d never seen it before and had no idea what it meant or what to do about it. It wasn’t even listed as a possibility in the script.
After 45 minutes of back-and-forth (which absolutely killed my daily stats), I finally told him he would need to schedule a technician to come out and fix it. The customer hemmed and hawed and asked me if I could just read him the proper orientation angles so he could try adjusting the dish himself. Side note: it’s very tedious to try and distinguish azimuth from elevation over the phone to a person with a questionable knowledge of spatial geometry.
During this part of the call, he asked some questions that didn’t make sense. So I asked a clarifying question: “where is your dish located?”
“Oh, I have it on a pole outside.”
“A pole? What kind of pole?”
“Like a 8 foot pipe. It’s in a bucket of concrete, but sometimes it come loose and spins a bit.”
“Your dish is mounted to a pole that rotates on its own?”
“Yeah yeah, but like only sometimes.”
That’s when I did what I should have done in the first place: pull up a weather map of his region. Turns out a goddammned tornado passed within a mile of him in the last hour. The connection wasn’t bad, I was just hearing the signature freight train-like sound of a tornado passing in the background.
“Sir, I’m looking at a weather map right now and it shows a tornado in your area?”
“Yeah, I heard the siren ‘bout a hour ago.”
“So… when I asked about weather, why didn’t you tell me there was a tornado outside?”
“It’d passed by then.”
“sigh can you go look at the dish for me please?”
slight pause
“Aw holy hell, the tornadah ripped out mah pole!”
I facepalm so hard, the call center goes quiet for a few seconds…
Trust No One
The sad truth is that we’re aren’t all technically sophisticated enough to consider the ramifications of mounting a satellite dish to a freely rotating pole. And it takes a, er, dedicated man to not let something as trifling as deadly weather interrupt his enjoyment of Wheel of Fortune. Most of us would view an incoming tornado as a matter for immediate concern, but this guy just doesn’t give a f*ck.
I’m only being somewhat flippant here. If he’s genuinely not concerned about the tornado, then it’s natural that he wouldn’t think it important enough to mention, or that it would stand out in his mind as perhaps causally related to losing the satellite signal.
There’s a reason “trust, but verify” is a thing. So as much as I’d like to fault the guy for being an idiot of the highest caliber, the truth is I could have saved us both nearly an hour if I’d listened to my gut and checked the weather to confirm his report at the start. Remember: anything you don’t verify is a potential root cause!
Don’t Forget the Doc Brown Effect
Imagine for a moment that you work in the service department for the DeLorean Motor Company, and you get an angry phone call from a customer complaining about the car constantly losing power. After a lengthy back and forth discussion and some confusing diagnostics, the customer suggests that perhaps the time circuits are bleeding the flux capacitor of its “1.21 jiggawatts”. He asks if he brings the car in will you’ll verify that’s the case and provide a fix or workaround. Unfortunately, you can’t hear him over the sound of your brain exploding.
Welcome to the Doc Brown Effect: with customer support, you need to be mentally prepared to face all the ingenious ways people will find to use the product, and expect people to break it in ways you never imagined it being used in the first place.
See, people are tinkerers, and they are adept at accomplishing their goals by finding new and innovative uses for the resources at their disposal. This isn’t a paean to human nature, it’s a positive way of saying that the world is full of half-assed systems built using makeshift tools that kinda-sorta work in spite of everything. It’s fundamental to who we are, and sometimes it makes product support a nightmare.
Going back to the satellite dish, I was operating on the assumption that the customer had his equipment in a standard configuration. Most people have dishes mounted to their roof or the side of a building, and in thousands of calls I took during my tenure, I only came across two or three exceptions.
Generally, people are aware that their configuration is non-standard and make a point of telling you that from the get-go (like the one guy who had his dish mounted to an RV). But there’s no real reason why someone might think that their setup would matter. I mean, if it works initially, then it must be a viable solution, right?
Never assume that the customer is using the product as intended.
Dish On A Pole Support
Most of the time supporting a product is pretty straightforward. When people do the wrong thing, they tend to all do it wrong the same way. This is a good thing, because A) you can reduce your response times with solid documentation and canned answers, and B) these clusters highlight where you need to focus on making the product better.
The downside is that we develop heuristics predicated on our interactions with the average user, which makes us vulnerable to the inevitable “dish on a pole” user – the one who is using the product in a radically unexpected way and doesn’t see fit to report that or other pertinent details. As far as they’re concerned, they’re no different from any other user and they expect fast and effective support.
When these users invariably make their way into the queue, it will be a complete time sink. Tickets will drag on for days (if not weeks), only for you to discover, after many man hours of investigation, that they are doing something ridiculous and expect you to work out the bugs or adapt the product to fit their use case.
In my younger days, I would have offered to help, done some research and maybe even provided some code reviews and pull requests. But unfortunately, this sends a bad signal about the scope of your support. They will simply come to you with more and more issues that are less and less related to your product. You effectively become one of their engineers (without pay) at the expense of time you could be spending on your less demanding users.
Bottom line: learn to identify the DOAPS and wish those users well as you send them packing. It’s never worth your time.