Representative documentation
-
"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.
Discourse mangled this post after baking it once.
-
-
@chubertdev - Days Since Last Discourse Bug: 0
-
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
Not long ago, I had an experience with Verizon tech support that's kinda related to this. We couldn't get to about half the web pages we wanted to - across about six different devices variously running Windows, Android, and Linux. While I've never worked in that position, I know enough to be reasonable and not argue with seemingly stupid or redundant instructions like "please reboot" the modem after having tried that myself several times.
Anyway, after going through helldesk #1's routine, including screen-sharing on one of the computers and trying a proxy, he dumps me with a bullshit* "we'll call you back" line, having been unable to figure out what was wrong. So a little while later I call again, and get helldesk #2 who starts off blaming my side, after having indicated she read the ticket from #1. And she did it in a very annoying way - saying something like "Fixing your equipment is your responsibility, but we'll try to help you as best we can". After some insistence that it couldn't possibly be the computers, tablets, and phones that were all at fault**, and pointing out that it wasn't that the websites were down (they were accessible by other means), she finally does the minimum possible troubleshooting she could do before blaming us again. And after some repeated assertions (with evidence) that the problem had to be at the modem/router or further up, she just hung up.
Finally, #3 was actually helpful. After a quick patronizing "please be calm, we're trying to help you" on chat (presumably from reading the previous notes), they went through enough troubleshooting to figure out it (might) be the modem/router, and sent us a new one.
Unfortunately, at the same time we received the new modem/router, there was a network outage, so I can't say whether the problem was the router/modem, or them needing to reset/replace a faulty system further up. But the problem was fixed without having to do anything to any of the computers, tablets, or phones that #1 and #2 believed were the cause of the problem.
All of which is to say: don't trust tech support to honestly represent the proceedings or the problem before kicking the customer. They have their own interests and ignorances too.
* How do I know it was bullshit? See helldesk #2. ** To expand on that: the same websites could not be accessed from each device going through their router/modem. However, the phone when using the AT&T 4G connection could connect to each place fine. Also, tracert showed us stalling out at one of their routers (or something like that) in nearby #MAJORCITY for the websites we couldn't connect to, but working fine for the other websites.
As an aside: those attempts to manage the emotional context of the conversation are really transparent, patronizing, and aggravating. Pretty good for getting the customer to want a more competent provider, though.
-
Actually, it felt quite a lot like this:
-
This reminds me of an internal ticket I filed a couple months back. Colleagues said 'you'll never get a response and every 6 months they close all tickets "assume fixed".
Well, I did indeed not hear anything, until two weeks later I got tired of the problem and send a followup email, CC boss and boss+1. (not really boss+1. Weirdness in our part of the org chart. But they didn't know that). 48 hours later the issue was resolved.
-
every 6 months they close all tickets "assume fixed".
One of our internal ticket systems automatically closes any ticket that hasn't been updated in 7 days. Not only must some "No update; still waiting for X" comment be added, the ticket status must change from "Waiting on IT" to "Waiting on customer," or vice versa, to keep the ticket from being closed automatically.
-
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).
Had this on a Dell support call many years ago. Don't remember the details anymore, but basically went something like this:
Me: spends about 45 minutes doing reboots, flash BIOS, RAID card reseat, etc. to get the RAID to be recognized so server would boot. No dice. Call support.
Support: May I help you?
Me: explains problem, review quickly steps I did, please escalate to level 2.
Support: Ok, let's start by rebooting the server...
Me: lets out silent groan ... waits 1 minute ok, rebooted, no dice.
Support: Ok, let's try flashing the BIOS. Download from www.dell.com/...
SNIP 30 minutes
Support: Ok, escalating to level 2...
Level 2 Support: Hi, I see from the ticket...snip...try shorting pins 3&4 at this location to reset the RAID card & reload...
Me: It works! Thank you!Yes, I know those level 1 guys probably need to make sure you did the steps. I get aggravated when I just explained what steps I did in detail, and he still tries to make me do them again. Grr!
-
This is one of the main reasons I'm sticking with my current ISP. My previous one was like this. The current one has support where I can call in, tell them everything I already tried and just move on to the troubleshooting steps I can't do myself (server settings, port resets, etc.).
Average time spent talking to the helpdesk agent: 5mins. Immediate problem resolution rate: 90%-ish (10% is equipment problem, mostly due to old, crappy infrastructure).
-
Yes, I know those level 1 guys probably need to make sure you did the steps. I get aggravated when I just explained what steps I did in detail, and he still tries to make me do them again. Grr!
well in the really big ones that is exactly what those level 1 techs are for. They are to weed out:
- The simple problems that can be solved with basic troubleshooting
- The people who think they are techy and smart but actually aren't and have one of the simple problems
- The assholes that just want to talk to their manager first because "there's no [copulation]ing way that tier one knows a [copulation] thing about tech!"
it's a crappy job, but it is needed. especially in the multinational helpdesks that go all the way up to tier 4 or 5
EDIT: apropos. i've been ra dom walking through the archives of XKCD to wast time this morning and this just came up: http://m.xkcd.com/806/
-
. I get aggravated when I just explained what steps I did in detail, and he still tries to make me do them again.
Of course. The problem is, as you already know, that lots of people lie and say they've done all that when they haven't, but when doing it once would fix it. If they don't insist, they may wind up spending half an hour on the phone. Look at all those stories on notalwaysright.com or wherever where people waste support's time for 20 minutes and then say "oh I can't see that because it's dark, because we're having a power outage." WELL THERE'S YOUR PROBLEM!
-
So, I'm a victim of other people's dishonesty?
-
Pretty much.
And it really happens. We have customers who have notes attached to their permanent file along the lines of "customer will always say they rebooted their equipment, but they never reboot the right equipment (if they're actually rebooting any)".
@Dreikin:
To be fair to Verizon's helldesk, I would have probably started off with blaming your computers or internal network setup too. "Half the Internet is intermittently down, and it's your equipment's fault" is a pretty extraordinary claim, especially if they're not receiving a large mass of calls from your area. Because inconsistent/incomplete outages for one customer are almost always a DNS resolution problem -- a routing problem would be expected to cause a massive deluge of calls due to dozens/hundreds/thousands of customers being out.We had a customer on our FIOS the other day that had their Internet keep cutting in and out. Their router's uptime wasn't going backwards, the ONT's uptime wasn't going backwards, and there were no log entries showing an interface on the ONT bouncing. Of course, the customer was convinced it was our fault. Eventually, through the use of a packet inspection tool (MikroTik's Torch utility), we were able to observe that the customer was using a 3rd party DNS server that was periodically not responding to their requests (I assume there was a rate limiter inline somewhere -- certainly not ours).
Even that took the customer three support calls and effectively two escalations before it got to someone who was able to even start diagnosing. And it still took me the better part of 2 hours of work on it to catch the right piece of information to pin-point the problem.
TL;DR: technology is hard.
-
Also, many $majorVendors I've worked with (specifically Dell and HP, but there have been others as well) tend to have their Online Support staffed with more of a Tier 1.5/Tier 2 type tech. And/or they're much quicker to escalate on Chat Support calls.
I think partly because there's a recognition that someone who went looking for the Chat Support option is much more likely to not be afraid of their computer.
-
-
"What color is the metal on the plug? That didn't fix it? There should be a stamp on the face of the plug, you'll have to take it out and read it to me. There's no text? But plugging it back in made it work? Awesome, thanks."
-
So I have a customer who's providing a demonstration of this today. He's setting up a second instance of our web app as a test environment.
You make a DSN, then run our installer, and tell it the name of the DSN. He didn't install it the way we recommend, and then he complained about all sorts of things ("it's installed as a new web site, not a virtual directory, and now I'm getting NXDOMAIN errors." "Yeah, that's not my fault, but I don't know how to fix the problem because people usually listen to me when I tell them 'don't do that."
Later he says it works, but it has the same information as the production version. Now I told him at least twice he needs a new DSN pointing to the test database, but I bet he forgot to do that, so today I had to say "that sounds like a DSN issue--please make a new DSN and try." You just know he'll say I didn't tell him that before, even though I bet I can find where I did in the email trail.
-
There's no text? But plugging it back in made it work? Awesome, thanks
I wish I could like that more than once, but here's your +[insert random Unicode character here].
-
@Dreikin:
Many good reasons why tech support might initially consider the problem on my end.True enough. And I don't have a problem with all that when I do call - I even do all the steps they ask me to, whether I've done them before or not unlike some people @redwizard, @izzion, @everyone-with-a-life. The problem was that #1 and #2 stopped with "it's your equipment's fault" without even an implausible idea of how/what it could be that would affect all of these disparate systems the same way*. And the way they treated me (#1: "I'm going to tell you something to get you to hang up now", #2: "There there, it's all your fault. And it's not really our job or responsibility, but we'll go ahead and tell you how to fix your problem. The problem that's your fault, you evil person, you.").
Eventually, through the use of a packet inspection tool (MikroTik's Torch utility), we were able to observe that the customer was using a 3rd party DNS server that was periodically not responding to their requests (I assume there was a rate limiter inline somewhere -- certainly not ours).
Interestingly, despite checking that the websites were up through a proxy, no-one bothered to check DNS stuff. Didn't even notice that at the time (although I'd already checked myself - and found I couldn't set the DNS servers on the router/modem. Which probably should have been my first clue it was that device, since the option was there and had worked in the past.).
Also, many $majorVendors I've worked with (specifically Dell and HP, but there have been others as well) tend to have their Online Support staffed with more of a Tier 1.5/Tier 2 type tech. And/or they're much quicker to escalate on Chat Support calls.
I think partly because there's a recognition that someone who went looking for the Chat Support option is much more likely to not be afraid of their computer.
That could explain why #3 actually got somewhere. In this case I'm betting 1.5. During the screen sharing, #3 had to type some commands (ipconfig /release, etc.), but seemed like someone was telling them verbally what to do, because they would start typing stuff like "ip config slash release"**. So I ended up typing most of the commands for them once I figured out what they wanted (or they asked me to do it for them, eventually).
Not trying to bag on #3 here - it seemed like they were going beyond what they normally do, and I was happy for that.
"Half the Internet is intermittently down, and it's your equipment's fault"
Not terribly important, but that wasn't my claim. Rather, it was:
- Any site one device can see, all can see.
- And site one device can not see, no device can see.
- Except when using the AT&T cellular network via the one relevant cell phone, where all sites were visible.
I've had problems before where they did something on their side to fix it, but it wasn't widespread. They've never told me what they did, but it seemed like it was just something in a weird state with respect to our connection - including, possibly, something to do with the router/modem.
* I should perhaps make clear that the router/modem is theirs, and I emphasized the problem could be there in the calls. **Okay, not exactly that bad, but I can't remember what the real version was; In any case, the point is that they typed it the way it sounds (if you're not used to it).
-
Is this a new discobug?
"Half the Internet is intermittently down, and it's your equipment's fault"
Produces:
@izzion said:"Half the Internet is intermittently down, and it's your equipment's fault"
While putting a blank line between <hr /> and the quote produces:
"Half the Internet is intermittently down, and it's your equipment's fault"
Edit: So I tried using entities for the square brackets, but while discourse shows them correctly in preview, it ate them in the post. WTF? Is there another way to do what I wanted?
Filed under: Heading towards Discobugception
-
Not terribly important, but that wasn't my claim. Rather, it was:1. Any site one device can see, all can see.2. And site one device can not see, no device can see.3. Except when using the AT&T cellular network via the one relevant cell phone, where all sites were visible.
I've had problems before where they did something on their side to fix it, but it wasn't widespread. They've never told me what they did, but it seemed like it was just something in a weird state with respect to our connection - including, possibly, something to do with the router/modem.
Not saying that was the claim you were "making". But it's almost certainly the claim that the helldrone heard.
And as far as your "discobug", it's showing normal to me
-
I even do all the steps they ask me to, whether I've done them before or not
Some additional data:
I'll try 3 reboots before calling. If they ask me to do another on the call I'm not doing it. Even if that does "fix" the problem, there is a very high probability that something is seriously wrong with the system and further digging is actually needed to find out the real problem.:P
-
Not saying that was the claim you were "making". But it's almost certainly the claim that the helldrone heard.
Heh, fair enough. And that does fit with how they acted. I suppose being able to type it out to #3 was probably also helpful in getting a solution.
And as far as your "discobug", it's showing normal to me
Well, that's Discoursistency for ya.
Some additional data:I'll try 3 reboots before calling. If they ask me to do another on the call I'm not doing it. Even if that does "fix" the problem, there is a very high probability that something is seriously wrong with the system and further digging is actually needed to find out the real problem.
I don't expect it to ever actually fix anything. I just figure:
A. I'm wasting the time already anyway
B. If it fixes itself, that's new and useful data. (Or they did something behind the scenes that required a reboot - pretty much the only thing I ever call for is the internet connection.)Although despite my jibe, I must confess I may have done that a time or two as well..
-
(Or they did something behind the scenes that required a reboot - pretty much the only thing I ever call for is the internet connection.)
A server setup that isn't on the network anyway, not likely.
But for many things, that's entirely plausible.
-
"What color is the metal on the plug? That didn't fix it? There should be a stamp on the face of the plug, you'll have to take it out and read it to me. There's no text? But plugging it back in made it work? Awesome, thanks."
When my DSL connection died (the problem turned out to be a fried modem), the phone tech asked me to reverse the cable between the modem and the phone socket. She remarked "I know it may sound weird, but sometimes it fixes the problem".
When I told her I know why it fixes the problem for some people and assured her that I did verify the cable was connected securely, she was genuinely surprised that I saw through their clever obfuscation.I repeated to her what I tried before calling and she skipped the rest of the scripted troubleshooting steps, but immediately made an appointment for an on-site visit by a tech.
-
Tech support guys hate me. I want to know WHY it broke rather than being satisfied that it randomly started working again.
-
Tech support guys hate me. I want to know WHY it broke rather than being satisfied that it randomly started working again.
Yeah -- its like nobody has time for root-cause any longer. Which is a real shame, because proper root-cause analysis roots out problems like, well, nothing else on the planet.
-
Ooh, that reminds me, I got an email today. They've upgraded the "root cause" field they added late last year as a text input to a dropdown and announced that by the end of the year it'll re-open any ticket that was closed without a root cause reason. This should be good. The temptation helpdesk people have to label everything as a bug will lend support to my insistence that our code quality really truly does need help.
-
They've upgraded the "root cause" field they added late last year as a text input to a dropdown and announced that by the end of the year it'll re-open any ticket that was closed without a root cause reason.
Root Cause: BUG
-
Spot-on.
No, seriously:
- Root Cause Category (Drop down with 6 choices)
a. Business
b. Code Bug
c. Database
d. Human Error
e. Network & Server
f. Vendor Software (Requires vendor support ticket ID)
- Root Cause Category (Drop down with 6 choices)
-
Actually, if they're accurate, that's pretty useful information from a high level standpoint.
-
Yeah, exactly. There's the age-old debate: "We don't have code quality problems, we have too many incidents because our users are stupid" vs "We clearly have quality issues, look how many incidents we had to handle in the past month". My response since day 1 in this position has been "We have no idea what our code quality is. We don't measure it. If you want to measure the impact of poor testing on products, you have to be able to measure the number of incidents in a certain piece of functionality and compare a well-tested change with one rushed out the door of approximately equal size". So they're taking me up on it.
-
by the end of the year it'll re-open any ticket that was closed without a root cause reason.
Here you simply can't close it without filling out that info. But where thinking about reworking the categories or registration. We're missing some info to actually attribute it exactly to a team, app and version.
-
Tech support guys hate me. I want to know WHY it broke rather than being satisfied that it randomly started working again.
Tech support guys hate me, but that's just because I discovered one weird trick that'll restore your faith in humanity.
-
What do those ads even go to?
-
I mean, someone must click on them, or they wouldn't still be doing it...
