Representative documentation
-
So, the fiber ONTs I've inherited primary responsibility for are giant steaming piles (actually, I think I just slandered steaming piles everywhere). And the support documentation & support department for the company aren't much better. See:
Reset Button
The unit can be reset to factory defaults by pressing and holding the reset button for less than 10 seconds
will cause a reset of the device. Holding the reset button, until all front panel LEDs turn on, will reset the
configuration to factory defaults and then do a reset of the device.Ai de mi. I think if I ever encounter former co-worker who was responsible for picking these, I'll have to thank him "properly"...
-
And representative support conversation (via e-mail):
Me:
I'm trying to recover the configuration of an {shitty rack chassis} that we have in our testing rack -- we lost the documentation for how it got set up. What is the pinout of the cable needed to connect via the serial port?
Agent:
See link: {link to their support site manuals page, which has a configuration manual, an installation manual, some release notes, etc}
Me:
I've looked through the configuration guide, and while it has information about the default serial port baud rate settings, it doesn’t provide me any information about what pin-out I need for the cable connection to my computer.
Agent:
Let me know if page 63/64 is helpful.
Me:
I would greatly appreciate my next contact from you to be the actual pin-out of the serial console port, rather than this "hide and seek" bits of information that is completely incomplete and inaccurate. {More rant about having gone through all of the manuals, including pages 63 and 64, and none of them having the gorram pinout information}
Agent:
Sorry,
Didn't mean to upset you, just trying to help you.
Here's information I received from one of the engineers:
See, now, that wasn't so hard! It only took 3 e-mails over the space of an hour to get the basic pinout information!
-
It only took 3 e-mails over the space of an hour to get the basic pinout information!
Sounds like he was stalling for time waiting for the engineers to get back to him. Though you'd know better if benefit of the doubt is called for here<I'm guessing not>.
-
Sounds like he was stalling for time waiting for the engineers to get back to him.
Or they considered him to be another moron who needs to be potty trained to read the documentation, instead of sending 20 emails a day when everything is in the manual.
Granted, in that case it wasn't (and the fact that the manual is shit doesn't help), but when you have people mailing you because they can't be arsed to look at the docs for more than five seconds...
-
Or they considered him to be another moron who needs to be potty trained...
Which the helpless desk guy proved that he was himself.
-
-
-
A) I'm not inclined to give them the benefit of the doubt, as their support experience in the past has been best summarized as "create ticket, get no useable response, e-mail your assigned sales engineer, wait days, then get a response from escalated support via your sales engineer"
B) If he was stalling, acceptable responses would include:
- Email #1: "To verify, have you checked our manuals, located here: {link}"
- Email #2: "Ok, I think there might be more information on page 63/64 of {manual you didn't already try}, but I'm also going to ask our engineering department for further information."
OR
- Email #1: "I've sent a request to engineering for more information, but while we're waiting, you might also be able to find the answer with our manuals, located here: {link}".
I'm going with the moron-projecting-that-I'm-a-moron theory. Y must u be so useless, helldesk?
-
+1 that's actually really helpful, I sometimes struggle for how to word things to not give the impression the other guy is a moron and give benefit of the doubt :)
-
+1 that's actually really helpful, I sometimes struggle for how to word things to not give the impression the other guy is a moron and give benefit of the doubt
Yeah, for me every time I give benefit of the doubt I'm bitten in the ass.
For instance, the one time I don't ask the client that has worked with me for years and who usually is on the ball whether the router was plugged in. Or I do ask and assume a client knows which is the router and which is the modem when he or she tells me all the lights are on, and I get there and neither of them are on.
And that is why if I'm forced to make an on-site call I'll ask for way more than the two minutes of me looking at an all-on-one printer's front to press the button that says "Auto Answer" is actually worth. If they don't want to engage their brains and lie to me over the phone that they did check the front and button light is on they should pay for it.
/rant
-
For instance, the one time I don't ask the client that has worked with me for years and who usually is on the ball whether the router was plugged in. Or I do ask and assume a client knows which is the router and which is the modem when he or she tells me all the lights are on, and I get there and neither of them are on.
-
Level 1 techs are only at level 1 and not something specialized for a reason.
Just got a ticket with a user reporting that "everything is slow", which is only that user, at their computer. Why would it be software? If it's an internal app, it must be sent to software! Nevermind taking two seconds to find out if they just need to reboot or something.
-
-
Level 1 techs are only at level 1 and not something specialized for a reason.
Flapjacking tell me about it. we ended up with one of those because of reasons and it's annoying as flarblewarblewitz!
I've added a JIRA ticket assigned to me called "Helpdesk Support" because as a developer i should never have to deal directly with initial helpdesk triage. any tickets i get should ahve basic triage already done. Not his.
he ran across the ticket recently which has 1/2hr assigned to it for every ticket he did that to me with the time trackjing comment of 'Initial Triage for IT-1XXXX' where IT-1XXX is the ticket i triaged for him.
He asked me about it and i said it was a time tracking ticket for an external helpdesk and he FARQUADING BOUGHT IT!
time comments now read 'Initial Triage for Doe.J On IT-1XXXX' and the ticket ID has been sent to his manager....
-
as a developer i should never have to deal directly with initial helpdesk triage.
I don't think I've ever worked at a place--and I've worked at some large ones--where developers weren't part of initial triage if they had to deal with answering tickets at all.
-
He asked me about it and i said it was a time tracking ticket for an external helpdesk and he FARQUADING BOUGHT IT!
*FARQUAADING
-
I don't think I've ever worked at a place--and I've worked at some large ones--where developers weren't part of initial triage if they had to deal with answering tickets at all.
Depends on the size of the company, really. I went from ~20 to ~30 to now ~800 employees with the companies that I've worked at, and this is the first one where I expect proper triage from a L1 tech.
-
*FARQUAADING
You're assuming a lot. Maybe the helpdesk guy bought it so much that it inspired him to travel a long distance to hang out on a college campus.
-
Depends on the size of the company, really. I went from ~20 to ~30 to now ~800 employees with the companies that I've worked at, and this is the first one where I expect proper triage from a L1 tech.
No, the last place I worked was pretty big. Oh, now I remember, though, that it was an internal application, so it wasn't unreasonable for me as a developer of it to be L1--who else would be? (It was 7 years ago I left there...)
-
I'm on a product, but we've got internal deployments as well. We've got some pretty good support guys, but they're not allowed to help with issues on internal deployments - all of those must go straight to development, even though support is better capable of troubleshooting installation issues.
-
No, the last place I worked was pretty big. Oh, now I remember, though, that it was an internal application, so it wasn't unreasonable for me as a developer of it to be L1--who else would be? (It was 7 years ago I left there...)
Sounds like how my current company used to be.
-
I don't think I've ever worked at a place--and I've worked at some large ones--where developers weren't part of initial triage if they had to deal with answering tickets at all.
if it's a dev issue, sure i should be involved. if it is resetting the users password i should not! and that's the level of tickets i'm getting from him without investigation just because the user mentioned my name as the last person they talked to.
i don't expect helpdesk to solve all problems but they should at least check for the ones in the FAQ!
-
"I forgot my password" -> you reassign it to the right department with reason "not my department."
The next time the same person does it, you politely email them and tell them you can't help them.
-
that's the thing, I've NEVER helped these users with their password! I don't have the domain access to do that! i'm just the only developer in the building at 0700 when they come down looking for the helpdesk people. I tell them that i can't help them reset their password because i don't have that access and that they need to open a helpdesk ticket.
they do and invariably it reads something like
I was down on 3rd this morning looking for you and @accalia said that i need to open a helpdesk ticket for this so you can reset my password because i changed on the friday before my vacation and i forgot it
and it gets assigned to me because i'm mentioned by name! i swear all Doe.J sees is:
[spoiler]I was down on 3rd this morning looking for you and[/spoiler] @accalia [spoiler]said that i need to open a helpdesk ticket for this so you can reset my password because i changed on the friday before my vacation and i forgot it[/spoiler]
-
i'm just the only developer in the building at 0700 when they come down looking for the helpdesk people.
That's your mistake. I come in at 9.
But yeah, I've submitted tickets where I say that a server is down, and, as a software developer, I have them assigned to me. Not even a second of attention given to the ticket to see who it should be assigned to.
-
That's your mistake. I come in at 9.
i come in at 0700 so i can leave at 1530. :-P
But yeah, I've submitted tickets where I say that a server is down, and, as a software developer, I have them assigned to me. Not even a second of attention given to the ticket to see who it should be assigned to.
exactly! that sort of crap may fly at an ISP helpdesk where you are rated on how many tickets you service and how quickly. not so much on a 12 person IT team servicing a company of 300 and counting.
-
I really wish I had that middle-level: "Are you fucking stupid?" response built in.
I can either play dumb and appease the support/sales monkey or I can go full-nuclear, but I can't play the middle.
That's seriously something you should add to your CV/resume.
-
Well, then assign it right back to that fool, with "not my department."
-
Well, it's indirectly on my CV -- I'm a business major
But, from having worked the equivalent of helldesk levels 1 and 2 in working up to my current position, the rules I've found for being on the helldesk side of the conversation run to the effect of:
- Remember that the guy contacting you is already pissed off at you(r company), because he's had this problem for a while and has probably already tried some things to remedy it.
- 90% of the time, the person on the other end of the phone is incapable of communicating in tech-speak. Use common terms to describe what you want them to do. (In our case, we often have to talk people through unplugging the power from their Power over Ethernet - PoE - adapter. To get them to find it, we relate it to "grey colored box, size of a bar of soap" or the like.)
- For IT/networking/Internet type things: 90% of users don't use the address bar as an address bar. Know what the Google & Bing search pages are going to look like for whatever string you're going to ask them to type in.
- Never ask them to do something in a way that implies they haven't already done it. Ask, "can you verify X" or "I am required to have you check A, B, C while you're on the phone with me." Most people are civil enough to realize that the helldrone is constrained to following certain steps, and if you reference that, you'll get some subconscious sympathy from them.
And, obviously, when you're on the customer side of the helldesk, getting vulgar or overly pushy with the drone is simply gonna get your ticket binned. Bust out a business argument they aren't going to want their manager to see/hear if the ticket gets escalated, make sure you communicate clearly and slowly, and make sure that you follow their requests (even if "following" means lying down on the couch and counting out 15 seconds while you "reboot" your modem for the 7th time).
-
Yeah, I've definitely wound up on the wrong end of the "customer assured me he knows what he's doing and didn't." And sometimes we get customers who get extremely belligerent when you try to have them work through things; they're insisting that someone needs to come out (within the next 5 minutes!!!!!!) and fix our broken stuff.
But, in general, if you (calmly, quietly, politely) explain to them that they're going to receive $extraCharge for the service call if you're unable to complete the basic troubleshooting and the problem turns out to be tied to that, they'll be a bit more reasonable. And if they still aren't, then you note the ticket, schedule the service call, and make sure billing knows to terminate their service when they refuse to pay the $extraCharge later. Sometimes haters just gonna hate
-
Generally my clients know me personally so I have little problem actually working with them on things like this. It's just that sometimes they are tired because they tend to be small business owners and they just got home from 14 hours (I know their hours pretty well) the fax machine just doesn't work, and they need it to work, but they just don't have the brainpower left to do anything about it. Belligerence rarely goes into it, most of my customers know I can tell when their lying, and they always have the fear that I'll simply be too busy to see them if they get out of line with me.
Professionalism is a two-way street. I get the job done and they don't spend any time berating me. Otherwise I'll just shrug my shoulders and walk away -- I've got enough on my plate.
It's good to be only responsible to yourself.
-
Ah, yeah. Private consulting is way betterer than general helldesk. At least my current job's helldesk manager is willing to back his support staff up when the "always right" gets rude and belligerent. Having customers know they can get fired makes for a much nicer helldrone experience.
-
@chubertdev said:
That's your mistake. I come in at 9.
i come in at 0700 so i can leave at 1530.Exactly. Why waste your afternoons?
-
Why waste your afternoons?
I come in early for the same reason - I generally don't waste my Thursday or Friday afternoons. Certainly not at work.
oh look -it's Thursday....
-
At the company I just left; my department, despite being the smallest and quite specialised dev team, was the only one that had "development" within their team name.
A new support guy started a few weeks ago, and obviously skipped the "here's what departments we have" part of induction, because every time he handled a ticket that sounded like it would need development work he looked through the assign to list, saw Widget Development and assigned it with some comment like "can development take a look at this".
My morning "wait until the coffee has opened my eyes a bit" task was to go through the tickets from him, identify the one or two that actually applied to us, and do the basic extra logic of "this says it's a problem with a report, better assign it to reporting. This one says the web site is causing problems. Hi web support".
-
Ha. Did you ever tell/convince him to do a better job at triage?
-
-
I come in early for the same reason - I generally don't waste my Thursday or Friday afternoons. Certainly not at work.
oh look -it's Thursday....
I'm a crazy night owl. I have the most fun at 2am.
-
Luckily, the first one doesn't apply to me, as I do not communicate with anyone outside of the company regarding issues.
-
Did you ever tell/convince him to do a better job at triage?
Sent him an email explaining what we did and why we weren't the only port of call for development. I tried to get a good balance between telling him to fuck off and not being a complete dick.
I CCed my boss, who had a good laugh about it, which suggests the balance was OK
-
, which suggests the balance was OK
Or just that he wasn't offended. :) Sometimes, if you have a good boss, that happens. I worked at a place once where my direct boss ran all kinds of interference for those of us in his department. When he left, I did too, because the new boss wasn't that kind of person.
-
When he left, I did too, because the new boss wasn't that kind of person.
That happens way too often.
-
i come in at 0700 so i can leave at 1530.
I love getting in at 8a. It's nice and quiet so I can actually get something accomplished! F'in open space offices.
-
I love getting in at 8a. It's nice and quiet so I can actually get something accomplished! F'in open space offices.
Everyone comes in here early, so it's only quiet before 5am, or after 5pm.
-
Here, people don't usually start all taking calls in cubicles next to developers until around 8.
-
Here, people don't usually start all taking calls in cubicles next to developers until around 8.
Being on the left coast, my company has to handle early inquiries from the east coast. There are far less calls at 17:00 PDT, so the timing makes sense.
-
Yeah, I've definitely wound up on the wrong end of the "customer assured me he knows what he's doing and didn't."
I've been down the "helpdesk person refuses to believe the problem lies at company server" too often to feel bad about telling them to go find someone who knows how things work. Escalate asap.
An example: during a routine maintenance, our ADSL modem somehow got blocked from either recieving or sending data (I forget which - it's been a couple of years). It took me more than three calls and an actual service visit to actually get someone to admit that there might be a problem (it looked peachy from the ISP to my modem) and that I knew what I was talking about. Those were two long weeks with no internet.I worked in 1st and 2nd line support myself, many years ago, and people are generally either clueless or savvy. I very rarely met the know-it-alls with no real knowledge. You learn to tune them out.
-
Working in IT consulting for small companies in the back-of-beyond, I wind up encountering what we've dubbed the "PC Magazine" type. They're a moderately successful entrepreneur, and they haven't gotten where they are by being dumb or being wasteful in spending. So when they need something to improve their networking, they bring in professional help, and then try to help the help by insisting on specific "flavor of the month" solutions that are pretty much the latest buzzword bingo winners. Sometimes you can convince them it's a bad idea, sometimes you can't.
Of course, said ex-coworker who was responsible for our FTTP service fustercluck had a tendency to jump on board with whatever PC Magazine thing the customer wanted to do, so I'm just eagerly awaiting when I get to inherit one of those messes (hello, assisting the customer with installing the Linux Exchange "replacement" when we're a MS Partner shop and pretty much everyone in the building told him to sell Exchange or cut this -- very parsimonious -- customer loose. :x)
-
"We'll investigate that possibility."
[three months later]
"After all possibilities were considered, this technology* was deemed to be the best fit."
-
- not your technology, which we didn't even really consider, but we won't say that.
-
-
Not sure I've ever had a customer1 where I could get away with a 3 month investigation delay. But yes, good tactic to combat the PC Magaziner.
1That I wanted to keep, anyway.
