Two incidents from my years in payments support look nothing alike on a ticketing system and are, underneath, exactly the same story.
One: the login that “couldn’t” be our fault
A customer lost front-end access shortly after onboarding. Everything on our side said this should be an easy escalation: they’d completed onboarding a week earlier, nothing had changed in the product, and “can’t log in” tickets are usually someone else’s department. The easy move was to hand it over. Instead I stayed on it and worked through the layers — browser, network, credentials — until the real cause turned up somewhere nobody checks: a personal firewall on the customer’s own machine. One session, resolved, no engineering time spent.
Two: the API error the documentation didn’t cover
A payment integrator was stuck on a recurring API error. Our documentation was detailed — and it had already failed them; they were close to abandoning the integration. A queue ticket answering “re-read step three” would have been the end of it. So I set up an after-hours call and we walked through the integration live, step by step, until we found it: one missed step, sitting between two lines of documentation that were each individually correct. The integrator was unblocked that night; the integration completed.
The pattern
Neither problem was the product. Both were a step that existed in reality but not on paper — a command run out of order, a firewall rule, a sequencing detail the docs assumed. The gap between how a system actually works and how it’s written down is exactly where support lives. Every ticket that crosses that gap is evidence.
What I do with it
- Rule out simple, local causes before escalating. It’s faster for me to check than for a customer to describe the problem to someone new.
- Judge the escalate-or-resolve call by where the unknown lives. If the remaining question is on our side, it’s an engineering question. If it’s on theirs, it’s mine.
- When the missing step finally turns up, write it down — update the docs, the runbook, the onboarding email. A fix that lives only in the ticket will be re-discovered by the next customer at full price.
The best support ticket is the one that ends with the documentation being slightly truer than it was that morning.