
Ask HN: Are there technical reasons ISP support experiences are often terrible? - wwweston
I&#x27;m astonished by how often ISP support starts with wasting time walking through a script, often by someone it isn&#x27;t clear knows much, culminating in asking for a traceroute when the script allows.<p>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.<p>I <i>might</i> have hoped that a CSR could look at that and say &quot;Oh, hey, yeah, that <i>does</i> look like an issue, we&#x27;ll get someone to look at that, thanks.&quot;<p>But instead they went straight into the script, and eventually we ended up stalling out on a 3rd piece of authenticating info I don&#x27;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.<p>Maybe ISPs don&#x27;t care if tech support is good, and it&#x27;s a cargo cult crosswalk button isn&#x27;t designed to do anything other than let the customer feel like they&#x27;ve given input. Maybe simple reboot fixes comprise 95% of issues and so that&#x27;s what support does. Maybe good support is much, much harder than I think it is?<p>Sometimes I think: ISP, you have hardware in my home&#x2F;business. If it&#x27;s working, you can tell. If it&#x27;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&#x27;t this just be &quot;reboot and hit diagnostic page&quot;?  And authentication... you&#x27;ve got my physical and network addresses, you know I&#x27;m on your network or I&#x27;m not.<p>Am I missing something? If so, what?
======
troydavis
> 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
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?

------
Porthos9K
"We don’t care. We don’t have to. We’re the Phone Company." \--Lily Tomlin

[https://snltranscripts.jt.org/76/76aphonecompany.phtml](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."

------
bradknowles
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?

