On 14-May-07 15:48:11, Brett Parker wrote:
On Mon, May 14, 2007 at 04:40:58PM +0100, mephi wrote:
My Virgin BB package is Linux un-friendly, I phoned them up to report a fault and they asked me what version of windows I was using.
Trying to persuade them that you've got a problem with their kit gets you nowhere because the person at the end of the phone can't go through their scripts...
That's simple though - "yes, clicked that, yes, done that, yes, that doesn't report anything wrong. No... oh sod this, I'm lying to you, I haven't got windows infront of me, here's what the problem is, please pass me on to second line support who *might* have half a clue."
Then if they won't pass you up the chain ask to speak to their mangler... it's all fun as long as it's an 0800 number ;)
Which prompts me to post the following long, but delightful, essay on calling technical support (which dates back to Feb 2001). I copy a posting to the Seattle Linux List.
Happy reading! Ted.
================================================================= Date: Tue, 06 Mar 2001 08:58:35 -0800 Sender: owner-linux-list@ssc.com From: David Ruggiero jdavid@farfalle.com To: linux-list@ssc.com Subject: [SLL] Highly OT: musings on tech support
[Highly OT, but so brilliantly written and achingly familiar that I thought others would enjoy it. LA is a former OS hacker/software company CEO/published poet. Feel free to hit the big "D" if you're not interesting in somewhat philisophical musings on the nature and practice of getting tech support to do its job. -jdr]
---
From: LA Heberlein la@heberlein.net Date: Sat, 03 Feb 2001 20:44:12 -0800 Subject: L.A.'s Journal: February 3, 2001
Different periods of history reward different sets of skills. In nineteenth century America, it was important to be able to work with animals. In the mid-twentieth century, out in the country where I grew up, probably the most valuable skill was to be able to fix a variety of machines. Today, the skill that stands out most vividly for me is to be able to get a technical support representative to address your problem. Luckily for me, I have spent most of the last fifteen years on the telephone to tech support.
The problem is that when you call, the tech support representative -- won't have any idea what you're talking about -- will deny that there could be any problem with their product -- will try to find some other party to blame and tell you to call them -- won't help.
Now, in fairness to the tech support rep, I understand his situation. He -- has been on the job for three days -- received no training -- gets called over and over all day long -- by people who have never used a computer before -- receives consistently abusive treatment from helpless, angry frustrated people -- gets no bonus if he solves your problem
I have worked tech support. It's not fun.
The truly winning solution, at the dawn of the twenty-first century, is to avoid telephone tech support as you would avoid a root canal. Luckily for you, telephone tech support is an ugly cost center for technology companies, and it's in their interests to help you avoid it if they can.
So, several years ago, most companies started making available to you, directly over the Internet, all the reference materials that are available to their tech support reps. Instead of talking to a minimum-wage teenager who's looking in the known issues database, you can just hit the web and browse through the known issues database yourself. Works better for everyone.
Except that once in awhile, you come to a problem where you really do need the assistance of the people on the other side. You've tried everything else, you've determined conclusively that it's their problem, you can demonstrate it, and there's no workaround. For example, writing systems software often means using a piece of hardware, or a calling interface, in a way it's never been used before. So the manufacturer never tested it for that and has no idea it's broken. Your mission is to get them to understand and admit it.
Here is how you do that:
1) The hardest part is finding time to schedule the call. You don't want to spend forty-five minutes on hold, then have to break away for something else right when your call is about to be answered. Make sure you have a quiet environment, a clean calendar, a speakerphone, and a stack of magazines, or mail to sort, fingernails to clip, desk to clean.
2) Do your homework and have all the technical details sitting organized in front of you.
3) Be the politest, friendliest person the tech support rep has talked to all day.
4) This is the key. Be very precise in your use of technical vocabulary. It is extremely important not to bury the tech support rep in things he does not understand, confuse him, and make him think you're some off-the-wall weirdo. But he has to immediately understand that you're not somebody who can't figure out how to use the mouse. Think while you're listening to hold music on the speakerphone and sorting your mail about exactly which four technical terms you will use in your first sentence that establish you as an authorized inhabitant of this branch of space. Start low. That is, begin the conversation with relatively untechnical vocabulary.
5) To every excuse, evasion, denial, or attempt to push you off somewhere else, answer, slowly, not defensively, not aggressively, but like you would with a good student, "yes, I tried that, and the result was . . . " or "but that can't be the case, because . . . " If possible, seem as though you are praising the student for having given a good answer, but then challenging them to go back to the problem for a deeper look.
6) At each iteration of #5, increase the percentage of technical vocabulary in your conversation.
7) Refuse to get off the telephone, no matter what the tech support rep says to try to get rid of you, until you get your answer.
Number seven is the hardest for a shy guy like me, who doesn't want to be a bother, for whom the most important thing in life is to be polite. As soon as I can tell I've overstayed my welcome, I think I should be going now. No. At exactly the point where the tech support rep has decided there's no way to help you, and is ringing every "end of conversation" bell you've ever heard, that's when it's most important to hang in there.
How you know you have won: The tech support rep says, "can I put you on hold for a second?"
This means he has gone to ask somebody who actually might know. You may not have actually won, in the sense of getting what you need, but you've conquered the first level. The second level sometimes includes getting handed to a new person, and I don't have to remind you that one object of the second level is to get that person's name, phone number, and email address.
There's usually a moment, in the escalation involved in step #6, where it's handy to have one line that functions as a clincher. So that after you say that line, there is nothing the other person can say. It is crucial to deliver this line without any sense whatever of self-importance, no brag, no bluster. No "Do you know who I am, young man?". That never works. You have to understate the clincher. Deliver it like Cary Grant.
I happened to have the good luck fifteen years ago, when I took my first job that required this sort of telephone credential-establishing, to meet the guy who had had my job before. (It was David Ruggiero -- good friend fifteen years later.) He said, "The problem is that the guy on the other end of the phone is an IBM Customer Engineer, and he's used to always being the authority on this machine, and he's never met anybody who knows more about it than he does, but unfortunately, you do, because the Pick implementation on the Series/1 does all sorts of things IBM never envisioned, especially the boot sequence, where what Dennis does is just listen for the first device to talk to him, and then calls that the system console. So if a device is generating spurious interrupts, we're going to think that's the system console, and you'll never get booted. And the FPMLCC card will generate interrupts if the Berg connectors aren't tight."
"So you tell the IBM CE this, and he won't believe you. He'll say, 'It passes all our diagnostics.' And you say, "Well, yes, but your diagnostics don't test it in continuous receive attention interrupt mode.'"
I didn't follow more than about twenty percent of this, but I could tell that David had just given me the magic line, so I made him repeat it for me and wrote down the words "continuous receive attention interrupt mode."
Great phrase, right out of Zippy the Pinhead. And be damned if the very first call I got wasn't a Series/1 that wouldn't boot. I told them the problem was almost certainly the Berg connectors on the FMPLCC card. They said they'd tightened them three times already. I said, well, I know it's a drag, but I want you to go back and push down on every one of those Bergs one more time. The guy says, let me put the IBM CE on. The IBM CE comes on the phone says, listen, dammit, there's no problem with those Berg connectors, we ran the diagnostics and everything's fine. Okay, this is your moment. Pause two beats. Smile into the phone. Talk like Jimmy Stewart. "Well, of course you did. But, you know, the diagnostic suite doesn't test that card in continuous receive attention interrupt mode."
Total silence. The crowd sits stunned as the bronco puts all four feet back on the ground and walks quietly back to the stall. Wow! Five minutes on the job, and if it were that easy every time, I never would have quit.
Tonight's problem was G's laptop. When she uses it at the studio, via a dial-up line, she can't reach our mail server, to send outgoing email. I thought first it was probably an IP mask conflict, because the laptop also has a network card in it, and I have had problems on my laptop before, going back and forth between a dial-up and an Ethernet environment. But I looked, and that's not it. Then I figured, with a slap to the forehead, that it was probably an SMTP relay problem. That's not a bug. That's a feature! The mail server is intentionally not letting her in, because, when she comes in via a dialup line, she's not one of us, she's an outsider, and we can't let outsiders send mail through our SMTP server. I felt dumb for not having realized this, because the anti-relay feature was an important feature when we put it in the mail server, and I can't believe I'd forgotten it already. However, when I checked the mail server, though, it turns out I'd left that security device turned off. (Of course. The system administrator on that server is me. Don't tell your friends, but I tend to turn security devices off, having the attitude that every security device I have ever seen presented more inconvenience to the owner than it ever would to a potential intruder.)
So what was it? I actually had to go in and look.
I tried to Telnet to the SMTP port of any mail server, from G's laptop, and I couldn't get there. Somebody is blocking that port. It's not anything on the laptop itself. It has to be the network. The Internet Service Provider is blocking SMTP. Why would they do that? A security thing, probably. (See!) They don't want their users spamming the world.
At that point, I had two choices. One was to call tech support at the ISP and try to get them to fix it. The other was to just cancel the account and sign up with a different ISP. It is a sad commentary on the state of tech support in America, that I really didn't even consider the first choice. Who wants to go through the whole tech support thing? The sitting on hold, and then they won't have any idea what you're talking about, and then when you carefully explain it to them, they'll just deny it. It's easier to just go get a different ISP.
So it sat for a day. Most of my projects tend to get a long, steady dose of serious attention, then be abandoned for a long time. This one, though, was for G, so after a day of neglect, she asked about it. And tonight while she was out at a birthday party for a friend and my daughter was at a rock concert, my plan was to work on The Book. So given that alternative, of course I called tech support.
I'm reading this interesting book on Greek history, and it was Prairie Home Companion night, so I got a chapter read and listened to the monologue, and then this nice tech support rep came on. I told him the problem. He didn't understand. I explained it to him, being careful to slowly escalate the technical level of my diction as I went along. When he finally understood what I meant, he told me that they did not block access to SMTP. Even after all these years, I almost, class, at that point I almost said, oh, thanks, sorry to bother you, and hung up. Wrong answer! Remember? Of course he denies it. That's what he always does, right after not understanding it.
So I walked him slowly through what I had done to demonstrate to myself that he must be blocking that port. "What mail server are you trying?" he asked. "Well, I tried it with four of them, just to be sure," I said, which was the truth, but he thought I was just being evasive, and he asked me to name one. So I spelled him out the name of my mail server, and then, just for the chance to show off, I recited the IP address, and said, "and when I hit port 25 on that machine from a system connected to your network, nothing ever gets there."
He paused for a moment, and I could tell that he wanted to believe me, but there was no percentage in that for him. His job was to get rid of me, and he knew how to do that. "What you need to do," he said, "is to call the system administrator of that mail server."
Okay, now what's important here is how you say this, and the timing. Wait at least two beats, and understate this as hard as you can: "I _am_ the system administrator of that mail server."
There's just this magical silence, when you say, "but your diagnostics don't test it in continuous receive attention interrupt mode," or the local equivalent, which tonight happened to be, "I am the system administrator of that mail server." You say it very quietly, and then the line goes dead in a way that is like a bell ringing. There was this moment of wonderful, round, victorious silence. Then he said the magic words: "Do you mind if I put you on hold for a minute?"
Slap the table. Say yes! You're an old man, you may never get over this flu alive, you appear to have no marketable skills or information the world might value, and at this point I'd make pretty good odds against your chances as a rock 'n' roll star. But you can still get a kid on the tech support line to ask his boss a question for you.
He came back in two minutes, told me he had found out how to unblock that port, and it should be working within an hour. At that point, what you don't do is ask why, what you don't do is try to get him to admit that what he just told you directly contradicts what he just told you before, what you do, is you give him a real big thank you. You tell him how really very much you appreciate his help.
======================================================================== Contributions/Posts To: linux-list@ssc.com To Unsubscribe: linux-list-request@ssc.com, "unsubscribe" in message body Report Problems to: owner-linux-list@ssc.com List archive at: http://www.ssc.com/mailing-lists/
--------------End of forwarded message-------------------------
-------------------------------------------------------------------- E-Mail: (Ted Harding) ted.harding@nessie.mcc.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 15-May-07 Time: 00:21:06 ------------------------------ XFMail ------------------------------