Help desk declared code PEBCAK and therefore refused to help! Why hello there Friday and hello there, also, this week's instalment of On-Call, The Register's weekly column that recounts readers' tales of tech support terror. This week, meet “Ben” who told us he once worked for “a large three-letter-acronym IT company, which at the time had their hands in just about everything IT related …
I doubt that ServiceNow have a classification for UK Government staff incompetence but in my day we used to have quite a few, IIRC some were:
LUBE: Lacks Understanding of Basic English
BIOS: Basic Intelligence Operator Subnormal - Knows what a computer looks like: can't start it.
EULA: End User Lacks Ability - Knows what a computer looks like: gets as far as "Enter Password"
RAM: Read Ability Missing - this for users who classify an issue as "Critical: Department Dependent" (something nasty will happen to the whole department if this is not solved!) but fail to respond to IT requests that they answer their phone/email. This means that someone has to physically go to that office.
SCSI: "Can someone please Solve/Complete this Stupid Idiot's ticket?" - see RAM above
My favourite was always:
CAMEO: CAse Made for Extermination of Operator
Beer: It's Friday.
The obvious answer is no ticket at all, but rather a simple "take the floppy out, doofus". But if that is completely against corporate policy and procedure (or if there is no floppy), how hard would it have been to ask the appropriate desk to call the user?
I'm as hard-nosed as the best of them in certain cases, but some things are easier to just fix and move on. This is one of them.
This is true, and probably the course of action I'd have taken, but when the user launches in to being an arse when you suggest the most appropriate course of support then it does tend to make one less inclined to be the most helpful possible.
He did exactly what the user demanded - log the call with networks support as it's clearly a network problem. How much more helpful could he be!
And if you took your car to an expensive engine specialist and started screaming at him because you couldn't open the car door, then it would be a reasonable response to tell them, that since it's not an engine problem, to take it to the garage. Just because he might know how to fix it, doesn't make it his problem especially once you've been told who can.
Listening to some of the calls our support staff get is scary. Getting some of them to the point where our staff can remotely access their computer can be like pulling teeth. There are people who don't know what is meant by 'Could you open a web browser please?'. Others that don't seem to know what or where the address bar is. On one memorable occasion it appeared that one of the guys was struggling to get the user to type a six digit number.
And the one time when a caller said her microphone wasn't working. Turned out it wasn't plugged in. Now that isn't all that unusual (despite our software being geared around audio). But when asked to plug it into a USB socket it still didn't work. Eventually it turned out they'd plugged it into their colleague's monitor 'because it was the nearest socket'.
Well that's very true. Occasionally I've needed to do that and I don't have the faintest idea how to activate 'away from desk'. I also don't know how to redial the last number or get the company phone directory to display. Bloody Cisco phones.
On the plus side my old desk phone went doo-lally last year and was removed along with those of my colleagues as part of a streamlining exercise. I think everyone was happy about removing the ability of us software developers to talk to the outside world :)
I am glad that it is not just me who is baffled by completely unusable phones. Mostly people need to answer a phone, transfer a call, accept a transferred call, include someone else in a call, mute a call. Can I do this without a three-page crib sheet? No.
I've got a Panasonic phone here. In order to divert calls to another number, I have to type in 17 digits - to be fair that does include the phone number - but is still ludicrously long.
There are 12 named buttons on the phone, none of which does this and a further 12 programmable buttons, where the only way to program them is with these silly codes.
Cancelling divert is 8 numbers!
I don't know who designs these phones, but I do know that nobody can bloody use them!
There is of course no button for divert to voicemail, or pick up voicemail. What a pile of shite.
That issue, and many more that I've helped to resolve over the years, mostly at a human rather than IT level, comes from a system that is computer centric, not user centric. Even at a "three letter company" ( Of which there have been more than a few in IT - marketing like the three letter combo) most users just want the problem to go away and are not IT experts themselves. As soon as you introduce the element of users having to choose where to report the problem there's an element of auto-diagnosis. And the more basic the issue (e.g. floppy in drive) the more likely for that to go wrong. A little bit of user knowledge doesn't help here, tending to mislead. A generic support desk with expertise to direct calls to the right person ( you don't even have to tell the user who that is) is more useful. (Only not a generic support desk with a script reading non-technician, please)
Indeed, and that is why they came up with the notion of the generic service desk that logs calls for every IT problem as well as all facilities problems from a broken coffee machine to a crack in a supporting wall.
There are two problems that have crippled the notion of "service desk":
1) A truly generic service desk rarely resolves problems on first call, which irritates some users and looks bad against a key performance metric of the services it replaces: calls resolved on first contact.
2) Many companies create their service desks by simply rebranding the IT helpdesk; giving them extra work and no extra staff. This leads to a longer backlog of calls, and it's the desk staff that get it in the neck, as their performance goes down against key performance metrics... including calls resolved on first contact as while they can reset user passwords online, they can't exactly unblock the third stall on the right in the gents lavs over a phone call....
So yeah... service desk is a dream. I'm sad to live in reality.
I work in the network group here at $Co. While I won't say that our level 1 support staff is entirely useless, our group has gone around a few times with their group on how to properly escalate a ticket.
We've also had a problem with our customers (i.e., employees in the other departments) calling us directly for help because either they've gotten the run around with the help desk, or they put in a nice verbal request over the phone, and the level 1 staffer put into the ticket essentially 'it's broken, they need help' and dumped the ticket into our queue.
Fortunately, things have gotten better. Mostly.
"level 1 support staff is entirely useless"
They're not usually hired for their intelligence or problem solving skills, but merely for their ability to stick to a script and explain how to close the coffee cup holder.
The problem is when they either escalate too much or too little and this gets compounded when oversight is done within the group, so manglement try to avoid admitting they're cocking up.
This post has been deleted by its author
Oh God. At times over the years I've made a support call for stuff that I couldn't solve by using the limited resources and tools available to me as the user who was responsible for the team's IT (Often as simple as a permissions issue where the protocol was that I didn't have routine access to the server because of the presence of confidential data from other teams). The central IT team knew me, listened to the steps I've taken to identify/resolve the issue and usually came back with either a suggestion or a solution.(And sometimes I was able to call them with a workaround I'd found for a more general problem that we were all having that they could and did roll out elsewhere). But then a few years back a new corporate system appeared. I had to go through the "helpdesk" - seldom the same person that I'd spoken to before. Who'd take me through the usual script before passing the request on. But they never passed the information on that I'd given them . Which meant that a technician had to come out to answer the ticket, get the whole explanation again and then tell/allow me to resolve the problem, often in seconds because it was a relatively simple fix to a purely local issue. Of course soon after this started the IT guys just gave me their direct numbers - simpler for everyone and we logged the support call after the fix.
His name was actually spelled differently, but it was Polish & sounded so close that's how most of us pronounced it. It was years before he
finally learned what the IT acronym stood for & that his picture was probably in the dictionary beside the definition.
I've seen PRATFO used before now. It's normally a medical one (Patient Reassured And Told to Fuck Off), but can be applied to IT calls to (replace Patient with Person). Often used when the person calls in about a complete none-event, such as a user calling because they've received a Windows Update message telling them they need to restart their computer - is it a virus? That sort of thing.
I've got a dumbass at work this morning who has spent the last 1 hour and 45 minutes trying to fix his computer because it won't print.
I told him last night the printer was out of paper so i've been watching in amasement as he switches things on and off randomly to fix it...
PS: It's a bit basic (both the staff member and the printer) and doesn't report being out of paper or ink
The favourites I have experienced are:
User: The hard drive hasn't finished loading. Me: that's the used and free space not a loading bar.
User: I can't type, the keyboard isn't working so I can't login. Me: connects, clicks in the username box. Try now.
User: This box says to close Outlook for this install to finish, what do i do?
User: I can see your remote connection request, do I click allow or deny?
Hey it's your mom. Be nice. And draw some comfort from the fact that you are not going to get a call that says, "a nice man called from Microsoft and said I needed some security updates. You're always telling me about hackers so I thought I'd let him in. And you always seem so frustrated when I ask about the remote connection thing so I clicked Allow. Aren't you proud of me!"
I'd normally decline before the remote connection request is sent, but if this was done without warning I would absolutely decline.
I saw the damage done by IT support on a colleague's C:\ drive once... I mean if you're in large IT company, with a 3 letter acronym, and internal IT support in India, you'd be crazy to accept any remote connection request from a L1 agent.
A few weeks ago I invented a new version of PEBCAK for a mobile world...
A few days after a Moodle upgrade I received a call that a user was unable to login to the system. I was unable to replicate the issue so went back to the training dept. for more info and was told the user was on a phone, in a caravan and had since managed to login. I closed the call with my new acronym:
PEBSAFF
Problem Exists Between Screen And Fat Fingers!
Yeah, never slag off people who's job it is to help you, even if they are bad at it.
I know for a fact I got preferential treatment from some of the (offshore, outsourced) second-line teams because I was always polite, patient (sounding) and gave them all the information they needed in a clear fashion in the original ticket.
I mean, they frequently fucked things up when they were still freshly outsourced, but they fucked my tickets up far less often than they fucked up anyone else's, and that's all time saved on my part.
" I was always polite, patient (sounding) and gave them all the information they needed in a clear fashion in the original ticket."
Meanwhile, at the bank's robo-menu:
"Enter your account number and the last four digits of your social security number"
(an eternity going through options when repeatedly hitting "0" doesn't work)
Customer Service Rep: "Can I have your account number and the last four digits of your social security number?"
(an eternity discovering that he problem needs escalating to a different department, and a subsequent internal forwarding to wait musak)
Customer Service Rep #2: "Can I have your account number and the last four digits of your social security number?"
(Repeat until urge to be polite wears off completely).
When I was working Air Force aviation maintenance, we would (RARELY!) sign off a job as "R2 stick actuator, op check good" = Replaced the stick actuator (pilot), operation check tested normal.
Needless to say, it was typically not a welcome sign off when maintenance supervision found those, and you had better have a good reason for blaming the officer who reported the problem. Poor thing might get his feelings hurt by being called out for being a useless git, you know.
LOL. I've done similar.
Had a new employee that kept having problems and turning in tickets. A new ticket came in midday Friday, and by the time I got to their desk on Monday morning, there was a different person sitting there. Verified everything was working, and closed the ticket with "Replaced user, Tests OK.". Waited on an angry call from the help desk manager who'd I'd had discussions with before over resolution comments, but apparently said user had ticked her off as well. :)
To be fair, years ago I had a staff member who kept reporting computer crashes in an office that we shared - Cox and Box style - when I was out she was in. When I checked the PC it was always fine and I never had any problems when I was using it. Until one day I was using that machine when she was in the office and went past -and it crashed. Never did find out why, but we were able to replicate it, several times.
The chap who uploaded a mystery file full of binary gibberish instead of a plain text file, and, when informed it was binary gibberish, demanded I fix it. When informed that wasn't possible as it's their end, they escalate to management ..
The person with the technical job title who rang up with a valid but solvable problem, who gradually requests the response in simpler and simpler terms, until you realise they are in fact not just non-technical, but they are in fact a fraud who rings around the company asking other people to 'assist' them with (i.e. do) their work..
The company that hires the above, because they can't tell the difference between a tech and a random word generator with a tie.
The company that outsources to the above because they said 'yes', where their own techs said 'no', and then gives that company their techs ...
The outsourcing deal that defines the service being outsourced, as written by someone who read a book that was once in close physical proximity to an actual book on the subject..
Bitter and disillusioned? Moi?
I used to run a help desk where I instituted a system of three letter codes on ticket resolutions. These were used in analysis to try to make the service more efficient. Among these codes were the U codes where the cause of the ticket being raised was found to be the user themselves. PICNIC tickets as we used to call them. Problem In Chair Not In Computer.
Among these were:
USR - user self resolved.
UGA - user given advice.
UTR - user training required.
The former usually meant the user figured out what they were doing wrong without being told. The second that the desk told the user what they were doing wrong. The last that the user wouldn't take advice and needed to be referred for corrective action.
Finally there was the ultimate sanction. UFW. I invented this one for situations where the user was beyond redemption. Where nothing amount of training or advice could help. This created a flash against the user account so help desk staff could be warned what they were dealing with as soon as they answered the phone. When questioned by senior management I did hurriedly think of something for the F and W to officially stand for. I no longer recall what those two official words were.
Originally and to all the help desk staff they always meant one thing.
Fuck. Wit.
So the thing that confuses me here is :
Why the hell are there multiple helpdesks that can't pass a ticket between resolver teams?
Ok it's not a network problem; so just pass it to the desk-side support team in whatever service management tool (or tools) that you are running.
Basic ITSM process design normally includes how to pass on work that has ended up in the wrong place to a more customer friendly triage team.
"Many helpdesks will not transfer a ticket between resolver teams due to past football tossing between teams. Bad management forbids it, good management regulates and tracks it for abuse, then beans the offender(s)."
I've experienced that as a user in 2 main forms:
1) products from different suppliers, where each supplier blames the other one
2) where the hardware folks blame software, and the software folks blame hardware.
Both can be difficult to resolve and involve a careful mix of diplomacy and your own diagnostic skills.
I've seen them all, but unfortunately, we can't even be so much as circumspect because the users see the ticket updates by auto-email.
However, most places I've worked allow two very good things: a limited amount of response time from the user, usually less than a week. We have to attempt contact every day, but once the deadline is reached and there is no response, we close the ticket.
The other thing is discretionary authority. If a user is being a real numpty, we can put them off or cut them off if needed. But, we also have to call the boss right right away and explain it. If we follow the process, the boss stands up for us. We have to document that we put in a best effort to resolve the issue before we cut them off.
Yeah, I've seen it all, but I have no doubt someone will surprise me again.
" It's more worrying that people presumed to be logical ( as in techie minded) don't see that. "
While at a transistor level, computers are about logic, everything above that level is a baffling mess of arbitrary decisions, and any minor variation results in complete failure.
If PEBCAK was an assembler opcode....
Back in MSDOS exe days, rather than exit normally would kill off in Windows, then wonder why they were locked out for 2 minutes, then wonder why their HDD was filled with swap files.
They thought they were being clever but just killed the CMD environment leaving a mess and the data connections open.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
