Things your boss/coworkers/customers ask you to do that never, ever, work

Bonus points if they ask you do do something that has the exact opposite of the intended effect!

Note to self: hit Submit Key AFTER finishing cut & paste.

Okay, here’s my response to my own question. As mentioned in a thread I’m too lazy to search for, I used to work as a Relay Operator–that is, I would help deaf, hearing-impaired, and speech-impaired persons communicate over the telephone. The disabled person uses either a web-connected computer or a TTY device to connect with the RO’s computer and gives a number to dial; the RO makes the call, announces Relay, and reads what the disabled person typed and types what the hearing person says.

ROs operate under fairly strict ethical guidelines; they have to speak anything that is written, and only what is written; and they must (generally) type every word they hear; they must follow the instructions given them by the disabled person as long as those instructions are logically possible; and they may not make choices on the caller’s behalf. Doing any of those things is called a Relay Ethical Violation; get caught doing that repeatedly–say, three times in 3 months–and you’re fired.

But the process is quite tedious when the disabled person is trying to negotiate an automated system to, for instance, to someone in the T-Mobile billing department; the RO has to make the call, record the automated system as it speaks, and listen to the recording at a reduced speed (to make sure to catch every word) while typing the message for the DP. Seekihg to speed things up, the DP often sends, “RO, don’t bother typing the recording, just get me a live person and don’t relay anything till then.”

This never, ever works. Instead what happens is this:

DP: “RO. call 1-888-111-1111, don’t bother typing the recording, just press the button for a live person and don’t relay anything till then.”
RO: (sighing) Ok. Dialing 1-888-111-1111.
(dials)
Automated recording comes on. RO types: (RECORDING) (listening for your choice)
RO listens to recording, which is for, say, T-Mobile. The system asks, first thing, for the caller’s account number; and the RO has nothing to put in. So he disconnects and

RO: Sorry, your choice was not available. List options?
DP: Press for live person.
RO: Sorry, your choice was not available. List options?
DP: Is there a choice for live person?
RO: I apologize for any inconvenience. There was no choice for a live person. Would you like me to list the recorded options?
DP: Ok.
RO: (hits playback on recording tool and types automated msg, then adds make selection ?)
DP: Ok. My phone number is 314-159-2653. Enter that and then press for live person.
RO: (calls back & enters phone number)
New tree of recording begins. It offers three choices: press 1 to talk to someone in customer service, 2 for someone in sales, or 3 for someone in tech support. Since any of those may lead to a live person, and none of those uses the phrase “live person,” RO must do this:
RO: Sorry your choice not available. List choices?
DP: Press for live rep.
RO: (sighs) Sorry for any inconvenience. There were several choices that might lead to a live rep. Would you like me to list the choices?
DP: I said PRESS FOR LIVE PERSON!
RO: Sorry for any inconvenience. There were several choices that would lead to a live person and I am not allowed to make the choice. Would you like me to list the menu options?
DP: DAMN YOU!!! Why will you not do what I say do?!?! Fine, list the menu!
RO: (lists menu)
DP: Press 1 and then get me a live person.
RO: (calls back, works through menu, presses 1)
New menu begins; it asks for the last four digits of the customer’s social security number so it can pull up account info and won’t proceed until it gets that info)
RO: (sighing) Sorry your choice not available. List choices?
DP: Damn it! Why don’t you ROs ever do what I tell you to do? Fine! List the fucking choices!!!

The T-Mobile calls come through quite frequently. Elapsed time from beginning of call to getting to a live person (or in the live person queue) if the DP tries to save them, as above: maybe 10 minutes. Elapsed time if the DP lets the RO relay the recording step by step: maybe 2 minutes.

If the RO knows that calls to T-Mobile (or any other menu system they’re familiar with) normally end in tears or profanity, is there any reason they can’t just tell the DP that “live person” isn’t an option and that they’ll have to step through the menus level by level before starting the call?

As for “Well, that didn’t work right…” goes:

Not long ago, I had someone request access to a server that most people are not allowed to access - normally we tell people this and they calmly go away and work with the system administrators to get things done on this server.

I told them they couldn’t have the access. They complained. Loudly. They complained to my manager. She was amused that someone was unhappy that I was doing things correctly. The requester came back saying everyone else in their group had access. They complained to the server owner and the server owner’s manager. These people were also amused that someone was unhappy that we were doing things correctly.

The server owner said “Nope. You can’t have this access, and neither can the rest of your group.” and directed me to yank all of their IDs. :smiley:

Definitely not allowed. It’s what the FCC calls “functional equivalence” and “transparency”; a relay call is supposed to be as much like using the phone the normal way as possible, and the RO is not allowed to refuse a call, give advice, or offer suggestions; this is called “inserting self into call” and is a big no-no.

Particularly in the T-mobile case, this rule is remarkably stupid, because T-Mobile’s sidekick device is very popular among deaf persons, and thus their automated system is much easier to negotiate–IF THE DEAF PERSON WILL ACTUALLY READ THE MENU. Basically if you just give your T-mobile phone number and the last 4 of your social (for security purposes) you can get through to a live person pretty easily. Every operator is dying to say “Ok. it will speed things up if you give me your t-mobile phone number, the last four of your ssn, and say whether you want billing, tech support, or sales. Do you want to do that now?”

But doing so would get them fired.

Well, how about instead of typing “your choice not available, sorry for any inconvenience,” just straight out type the options, as they would hear them if they called, like the rest of us. I mean, we would all like to speak to a live person, straight out–right?

If you were really transparent you would disregard the “get me a live person” just the way the automated phone transferer would disregard it if you spoke that phrase into the receiver. If you played this right, the DP might not even know there was a live person attached to the keyboard at all.

Silly rabbit! :smiley: You are applying logic to rules set up by the United States federal government–specifically, the FCC. While I entirely agree with your suggestion on a practical level, guidelines do not allow for it.

I didn’t phrase my OP as I did by accident. If the DP merely types “live person” at the beginning of the call, ROs are allowed to interpret that as either “say ‘live person’ when asked for for a selection” or "press the ‘live person’ option when given a list of choices. After doing either, the RO start relaying the automated menu after doing so. However, if the DP types “press for live person,” the RO may not say ANYTHING, because he has not been directed to do so by the DP, and thus is “taking control of the call,” according to the rules, just as if he had decided to hang up in the middle of a call because he found the text customer’s voice annoying. Worse, if the DP types “I don’t want to see the recorded message, that takes too long, just get me a live person” (neither of which is uncommon), but there is no appropriate option, the RO cannot relay the menu options unless the DP gives the okay. That, again, is taking control fo the call away from the DP, and grounds for termination if he’s caught doing it too often.

I think this is the sort of thing you are asking about Skald:

Some years ago we had a very zealous and process heavy Quality Assurance department (made up of people who thought that writing software was in some way similar to the mass production / assembly line manufacture of motor vehicles*). Processes were documented in excruciating detail and the software engineers were expected to follow the processes, otherwise code / jobs could not be signed off and proceed to the next stage.

When some of us Senior Analysts discovered that part of the coding / testing phase was actually (and by necessity) iterative (but not allowed to be iterative in the processes-that-must-be-obeyed) we arranged a meeting with QA, explained the situation and made recommendations for updating the processes to match reality.

QA’s response? No, we’re not changing the process documentation. :confused:

End result: either follow process as documented (but fail to create software), or make software, but fail process, and hence be unable to get sign off for moving it to next stage… or ignore process altogether (including sign off point, by using admin privileges to force jobs through checkpoints). We did the latter, and a while later new-broom management decided that the QA department were part of the problem and whisked them away.

*Software can be compared with making cars, but more usefully with the proto-typing / design process that creates a new model of car. The assembly line part of the process is more just stamping discs.

Zeus help me. I actually got the just of that. That said, you might want to define “iterative” for the group. I took it to mean that a given process might have to be repeated several times, each time getting a bit closer to acceptability as it flaws were worked out; the QA idiots didn’t want to change the documentation to reflect that, as the precise number of iterations could not be defined. No?

show up on time not drunk or hungover?

A most excellent and succinct explanation. Yep.

In a nutshell, the Senior Analysts (about 10 of the most senior business / functional analysts and designers in the software engineering department) were asking the QA people to either put a loop into their process around a couple of boxes in the flowchart to show that sometimes things had to be repeated to get the right outcome… or if they really didn’t want a loop, to consolidate the boxes and make the iterative steps a single step (one bigger box but no looping). As one of the organizers I was naively assuming that the QA people would want their process to reflect best practice & what we actually did. :slight_smile:

Instead they rejected both our proposals leaving us and the entire software department no option but to evade the entire process in order to actually get code out the door.