Ask HN: Are there technical reasons ISP support experiences are often terrible?
3 comments
> Am I missing something? If so, what?
Potentially a couple things:
1. The center of the Bell curve is a fairly inexperienced user. My experience is a bit outdated, but something like 75% of inquiries get solved by the script. You get pretty close with "Maybe simple reboot fixes comprise 95% of issues and so that's what support does" - it's simple wifi and computer problems, app-specific issues (try a different browser? try email?), etc.
2. The impact from providing crappy support is very low. The few experienced users will slog through it. Also, there's a relatively weak correlation between customers who think they're technical and have spotted a problem, and customers who have actually spotted a problem. An example from when I ran an IXP: People who email traceroutes with stars, not understanding that some devices don't generate TTL exceeded messages… or even what a TTL is… but being completely certain (a) it's a problem, and (b) it's the cause of their (completely unrelated) problem.
3. The price premium that individual customers are willing to pay for great - or even decent - support is small and short-lived. Often the support for business-grade service actually does skip the first tier "Read from a script" support because the numbers work. Even somewhat knowledgeable people are expensive; assume a fully-burdened rate of $1/minute to talk with someone with basic networking CCNA-level knowledge. That person still wouldn't be able to login to devices or do meaningful troubleshooting.
You're also assuming that they don't know about a problem, rather than that they know about it and are trying to solve it (or have decided it's not worth solving, though that's actually more rare than people often think). You might be right, but there aren't many large networks which don't do their own blackbox latency and loss measurements (in addition to polling for link usage, loss, etc.).
So, there's not a technical reason, but it's also not an accident nor a case of ISPs acting illogically.
Potentially a couple things:
1. The center of the Bell curve is a fairly inexperienced user. My experience is a bit outdated, but something like 75% of inquiries get solved by the script. You get pretty close with "Maybe simple reboot fixes comprise 95% of issues and so that's what support does" - it's simple wifi and computer problems, app-specific issues (try a different browser? try email?), etc.
2. The impact from providing crappy support is very low. The few experienced users will slog through it. Also, there's a relatively weak correlation between customers who think they're technical and have spotted a problem, and customers who have actually spotted a problem. An example from when I ran an IXP: People who email traceroutes with stars, not understanding that some devices don't generate TTL exceeded messages… or even what a TTL is… but being completely certain (a) it's a problem, and (b) it's the cause of their (completely unrelated) problem.
3. The price premium that individual customers are willing to pay for great - or even decent - support is small and short-lived. Often the support for business-grade service actually does skip the first tier "Read from a script" support because the numbers work. Even somewhat knowledgeable people are expensive; assume a fully-burdened rate of $1/minute to talk with someone with basic networking CCNA-level knowledge. That person still wouldn't be able to login to devices or do meaningful troubleshooting.
You're also assuming that they don't know about a problem, rather than that they know about it and are trying to solve it (or have decided it's not worth solving, though that's actually more rare than people often think). You might be right, but there aren't many large networks which don't do their own blackbox latency and loss measurements (in addition to polling for link usage, loss, etc.).
So, there's not a technical reason, but it's also not an accident nor a case of ISPs acting illogically.
Thanks! It's especially nice to hear from someone who's worked running the infrastructure involved.
Can you speak to the general question of whether it might be possible/practical to have a useful diagnostic suite that runs from the customer end of a connection? I'm sure that my ability to use traceroute is limited (I know what a TTL is, but I expect I don't have much beyond a pretty vague idea for how that interacts with typical device configurations along a typical route), but the fact that scripted conversations with support often seem to end with a request for some traceroute output makes me think someone at the ISP does find that information useful in troubleshooting (unless that's also an unconnected crosswalk button), and it makes me wonder if automating that among other things and frontloading its use could save time on both ends of the support call, which would seem to provide the right incentives.
Also... do you have any insights about the incentives regarding informing customers about already discovered problems? I suppose this touches on my assumption that the ISP doesn't already know about my problem vs the plausible reality that internal monitoring is already going on. I've noticed on a few occasions (primarily back when I was with Comcast, I think?) that when I've called in for interrupted service that they've said "your issue is related to one we're aware of, you can look at this URL to follow our efforts to address it, or sign up for automated updates." That's not the reward that an instant fix is, but it seems to feel pretty good. But it's also apparently rare, which nudges my default perception towards "most of the time the ISP does not already know." Is there a dynamic which means an ISP might reasonably believe it's better off not telegraphing known issues?
Can you speak to the general question of whether it might be possible/practical to have a useful diagnostic suite that runs from the customer end of a connection? I'm sure that my ability to use traceroute is limited (I know what a TTL is, but I expect I don't have much beyond a pretty vague idea for how that interacts with typical device configurations along a typical route), but the fact that scripted conversations with support often seem to end with a request for some traceroute output makes me think someone at the ISP does find that information useful in troubleshooting (unless that's also an unconnected crosswalk button), and it makes me wonder if automating that among other things and frontloading its use could save time on both ends of the support call, which would seem to provide the right incentives.
Also... do you have any insights about the incentives regarding informing customers about already discovered problems? I suppose this touches on my assumption that the ISP doesn't already know about my problem vs the plausible reality that internal monitoring is already going on. I've noticed on a few occasions (primarily back when I was with Comcast, I think?) that when I've called in for interrupted service that they've said "your issue is related to one we're aware of, you can look at this URL to follow our efforts to address it, or sign up for automated updates." That's not the reward that an instant fix is, but it seems to feel pretty good. But it's also apparently rare, which nudges my default perception towards "most of the time the ISP does not already know." Is there a dynamic which means an ISP might reasonably believe it's better off not telegraphing known issues?
"We don’t care. We don’t have to. We’re the Phone Company." --Lily Tomlin
https://snltranscripts.jt.org/76/76aphonecompany.phtml
It used to be funny because it was true. The problem is that it's still true. But now it's true of ISPs, at least in the United States; they have regional monopolies or at most a single competitor using a different physical infrastructure as is the case of Comcast and Verizon.
The support experience sucks for people who know anything about networking because there's no profit in providing better service when most customers are incapable of appreciating it. Since there's no profit, and most customers are incapable of recognizing or demanding better support, ISPs can get away with skimping on that aspect of the experience. Just as they've mainly gotten away with skimping on infrastructure and clinging to IPv4.
"We don't care. We don't have to. We're the Internet Service Provider."
https://snltranscripts.jt.org/76/76aphonecompany.phtml
It used to be funny because it was true. The problem is that it's still true. But now it's true of ISPs, at least in the United States; they have regional monopolies or at most a single competitor using a different physical infrastructure as is the case of Comcast and Verizon.
The support experience sucks for people who know anything about networking because there's no profit in providing better service when most customers are incapable of appreciating it. Since there's no profit, and most customers are incapable of recognizing or demanding better support, ISPs can get away with skimping on that aspect of the experience. Just as they've mainly gotten away with skimping on infrastructure and clinging to IPv4.
"We don't care. We don't have to. We're the Internet Service Provider."
Providing good customer service is expensive, and is generally not rewarded by the customers. It becomes what they expect but will not pay for.
So, you inevitably get a race to the bottom. And once you’re there, someone has to find a new bottom to race to.
So, why bother?
So, you inevitably get a race to the bottom. And once you’re there, someone has to find a new bottom to race to.
So, why bother?
Today I tried jump starting things with Frontier Communications by just pasting a few sample traceroutes into a chat window. All of them pretty clearly enter 3-missed-response territory several hops into named Frontier infrastructure, likely right on the boundary between them and whoever their upstream provider is.
I might have hoped that a CSR could look at that and say "Oh, hey, yeah, that does look like an issue, we'll get someone to look at that, thanks."
But instead they went straight into the script, and eventually we ended up stalling out on a 3rd piece of authenticating info I don't know anymore if I ever did, which I can see might be needed if I was trying to change service, get money, or play global thermonuclear war, but not to try and troubleshoot an interruption of service.
Maybe ISPs don't care if tech support is good, and it's a cargo cult crosswalk button isn't designed to do anything other than let the customer feel like they've given input. Maybe simple reboot fixes comprise 95% of issues and so that's what support does. Maybe good support is much, much harder than I think it is?
Sometimes I think: ISP, you have hardware in my home/business. If it's working, you can tell. If it's not, presumably you can observe the absence of activity. If to troubleshoot further you need a client reaching out from my side to some service on your network designed to evaluate things, then pretty much all of us have web browsers which not only do HTTP but have evolved to do socket-level communication. Why do I need to answer any questions? Shouldn't this just be "reboot and hit diagnostic page"? And authentication... you've got my physical and network addresses, you know I'm on your network or I'm not.
Am I missing something? If so, what?