Support Tickets Are Product Research

We went looking at our own support quality recently, expecting the review to be a formality. Our team is patient, sharp, and genuinely invested in helping operators run their business. We figured we'd sample some tickets, feel good about it, and move on.

We didn't come away reassured.

Not because the team was doing a bad job — they weren't. It's that we noticed something that had nothing to do with effort at all.

An experiment we didn't mean to run

Almost by accident, we ended up comparing two kinds of answers to the same operator questions. One kind came from the usual sources: our help docs, the training material we give new support hires, the “here's how we've always explained this” knowledge passed down informally on a team. The other kind came from anchoring the answer directly in our actual product code — the real logic that runs when a booking happens, a price gets calculated, a refund gets issued.

The difference wasn't subtle. The code-anchored answers were more accurate, more specific, and caught edge cases the documented answers missed. Not slightly better — uncomfortably better.

It was never a training problem

The easy story would be that our documentation needs updating, or new hires need better onboarding. Both are true in the boring, always-true way documentation always needs updating. But that's not what the gap was actually showing us.

The real issue is structural. Every answer — whether it comes from a person or a bot — is only as good as what it's anchored to. Docs are a snapshot taken at some point in the past, maintained by whoever remembered to update them. Institutional knowledge is even less reliable, filtered through whoever's been on a team long enough to have absorbed it, and it decays every time someone leaves.

The product code doesn't have that problem. It isn't a description of the system — it is the system. It's the one thing that can't drift out of date with itself, because it's what's actually running when an operator's guest hits “book now.”

A ticket is a measurement, not a complaint

Here's the model this pushed us toward, and it's changed how we read every ticket that comes in.

A support ticket was never really a complaint. It's a measurement — the exact distance between what the product actually does and what somebody, an operator, a support rep, sometimes even us, believed it did.

It's easy to treat tickets as inventory to clear: close it, move to the next one, keep the queue short. That's a reasonable operational goal, but it misses what each ticket is made of. Every one is a data point about where the map — our docs, our training, our tribal knowledge — has diverged from the territory: the real, running product.

Read enough tickets that way and a pattern shows up fast. The same few gaps recur, not because operators keep asking unusual questions, but because the same few places in the product have quietly drifted from how anyone currently describes them.

Where this points for us

This isn't an argument for more automation for its own sake. It's an argument about what a genuinely better support experience actually requires. A tool anchored in stale documentation gives a confident, stale answer faster than a person would have. Speed isn't the improvement, the anchor is.

The real takeaway wasn't about our support team. It's that we didn't know our own product as precisely as we assumed, and the fastest way to close that gap is to stop asking people what they think the product does, and start checking what it actually does.

Support tickets have been product research the whole time. We're just starting to read them that way.