What evidence does an ISP actually act on for a one-destination routing problem? Tracert screenshots keep getting closed as "works for us" Playbook

What gets ours escalated, roughly in order of how much each item moves the needle:

1. A control test. Same client device, same destination, two different access networks, timestamps within a minute of each other, one works. This single pair kills "works from here" because you've already isolated the variable on their behalf.
2. Both public IPs written out explicitly, plus destination address and port. Not "our head office" — the address.
3. Timestamps with the timezone spelled out, UTC if you can manage it. A good share of "could not reproduce" replies are somebody testing a different hour.
4. A continuous measurement rather than a single shot. A multi-minute mtr or WinMTR run to the destination, exported as text, not as a screenshot.
5. A trace in the reverse direction, from the destination side back to the client's public IP. Path problems are frequently one-way, and this is the artifact first-line never has and cannot produce themselves.
6. One sentence stating exactly what you want checked, phrased so it can be answered yes or no.

Everything else is decoration.

Add evidence that isn't yours. Public looking-glass servers on a few different networks, and if you have access to a distributed measurement platform, a probe or two from unrelated networks toward the same destination.

If you can show the destination answers from four other networks and not from theirs, the conversation stops being your word against their first-line agent's ping. It also protects you in the other direction: if it turns out the destination is unreachable from everywhere, you found that out yourself before you accused anybody, which is a much better afternoon.

Worth saying what to cut, since you asked. Don't attach the full packet capture, don't attach your firewall configuration, and don't include five competing theories.

One page, the artifacts, one question. Every additional theory you volunteer gives first-line something to reply to that isn't the question, and they will take it, because replying is easier than escalating.

The one sentence is basically the whole ticket. Something like:

"From the access node serving line <circuit ref>, is <destination IP> reachable, and is any filtering, scrubbing or rate limiting applied toward that prefix?"

It names a place, names a target, and can be answered yes or no by one person looking at one thing. Compare it with "our customer can't reach their office", which routes straight into the reset-your-router script and stays there for a week.

Set your own follow-up before you send it. Two working days. If the reply is "works for us" with no artifact attached, respond exactly once with the same package and the same single question repeated word for word, then escalate on the account rather than on the ticket.

Ticket-level escalation almost never works because the ticket is the thing being processed. Account-level does, because somebody gets asked why a customer is unhappy, and that person can reach across teams.

If the line's WAN address sits in 100.64.0.0/10, say so in the first message. Being behind carrier-grade NAT means the path they need to examine is shared with other subscribers, which changes which team inside the ISP owns the problem — and getting to the right team is most of the delay.

Same goes for anything obviously traversing a mobile or fixed-wireless leg. Name the topology you can see from outside; it saves them a discovery step and saves you the reply that asks for it.