A support conversation should be a straight line: issue in, answer out. Instead most tickets look like a rally — question, partial answer, follow-up, screenshot request, wrong screenshot, another follow-up. Each touch feels productive. The sum is waste. Everything that moves context to the first message — recordings, logs, environment data, a well-designed ticket form — collapses the rally. One touch to understand, one touch to resolve. Your customers do not want a conversation. They want their problem gone.

Product teams pay for user research, run surveys, and schedule discovery calls. Meanwhile, support sits on hundreds of unfiltered sessions of people struggling with the product every single week. The difference between a complaint and an insight is context. “The export is confusing” is a complaint. A recording of six different customers hesitating on the same screen is a roadmap argument nobody can dismiss. If your PMs never watch support recordings, both teams are flying half blind.

Most support onboarding is a tour of the macro library. Here is how to say sorry in four registers, now go answer tickets. The fastest-ramping agents I have seen learned differently: they watched real recordings of real customer issues, end to end. The confusion, the workarounds, the moment the UI betrayed the user. You cannot template empathy. But you can show a new hire exactly what your customers live through — and let the macros come later.

“Works on my machine” has a support-team cousin: “cannot reproduce, closing.” Nine times out of ten, the bug is real. What is missing is the customer’s reality: their browser extensions, their network conditions, their account state, the exact sequence of clicks they made before things went sideways. You cannot reproduce what you cannot see. Capture the environment along with the issue, and “cannot reproduce” quietly disappears from your ticket closures.

Every time a support team books a Zoom call to “see the issue live”, two calendars get blocked, a customer gets homework, and the bug politely refuses to reproduce itself in front of witnesses. Live calls are the most expensive way to acquire context that could have been captured asynchronously in ninety seconds. Keep the calls for relationships, onboarding, and hard conversations. For bugs? A recording made by the customer, on their machine, in their environment, beats a scheduled meeting every single time.

I asked our engineers what makes them ignore an escalated ticket. The answers were brutal and consistent: “Customer says it’s broken” with no recording No browser, OS or account information No logs, no network trace A summary written from memory, three days later An escalation is a handoff of context. If the context is missing, you are not escalating — you are forwarding the confusion to someone more expensive. The best support teams escalate evidence, not descriptions.

Teams obsess over first response time because it is easy to measure, not because it is what customers feel. A 3-minute reply that says “could you tell us more?” is not support. It is an acknowledgement of receipt with better branding. The metric I care about is time to understanding: how long until someone on your team actually knows what the customer is experiencing. Everything downstream — resolution time, CSAT, escalation quality — flows from that moment. Shorten that, and every other number follows.

Sending a customer a 14-step tutorial on how to export a HAR file is a ritual humiliation for everyone involved. Half of them never reply. The other half send you a screenshot of the tutorial asking where the F12 key is. I say this with love — it is not their job. Network requests, console logs and environment metadata should be captured automatically, at the moment the issue happens, without the customer even knowing what a devtool is. If your escalation process depends on customers becoming engineers, your escalation process is broken.