3 ms·

> 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 out

> 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.

wwweston 7y ago
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?

wwweston 7y ago

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?