Every Support Ticket Is a Product Failure

Support designed backwards from a sentence

At Eric Glyman's company Ramp, the support organization is built around a claim that inverts the usual support playbook: if a product worked perfectly, no customer would ever need to contact support, so every ticket is by definition a failure of the product. Geoff Charles, who ran product at Ramp, describes the sentence "every support ticket is a failure of our product" as posted directly in the support channels.¹ The organizational choices that follow are all downstream of taking that sentence literally.

Three deliberate breaks

The first break is the reporting line. Support does not report into operations or a standalone customer-experience function; it reports into product, and in Charles's account directly to him. His stated reasoning is accountability: "what better way of holding the product team accountable for support."¹ Placing tickets in front of the people who ship features closes the loop that a separate support silo would otherwise absorb.

The second break is incentives. Agents are not measured on tickets resolved. They are measured on reducing ticket volume and increasing deflection over time, so the job becomes eliminating the causes of contact rather than processing contact efficiently. Charles notes this required a different kind of hire than the veterans who had scaled large support teams elsewhere, because the standard benchmark-driven approach optimizes the opposite metric.¹

The third break turns the resulting signal into a shipping gate. Team-level contracts track operational overhead, defined as the tickets originating from a product area normalized by that area's users, alongside customer-satisfaction scores and a count of tickets caused by customer confusion. Negative reviews are forwarded to the responsible engineer, product manager, and designer, and surfaced bugs are assigned to an on-call rotation rather than accumulating in a backlog. As Charles frames the rule, a team can operate autonomously as long as those metrics stay healthy, but once they go red the team cannot ship new features.¹

What the pattern is meant to produce

The claimed outcome, at roughly 2023 scale, is a support team of fewer than thirty agents serving more than four hundred thousand users, which Charles attributes to deleting the causes of tickets rather than staffing against them.¹ The mechanism matters as much as the number: because the quality controls are metrics that halt shipping rather than review meetings, enforcement consumes no velocity while a team is healthy. This is the same logic that runs through Ramp's broader operating culture, where context replaces control and speed is treated as a design constraint rather than a tradeoff against quality.

The pattern is the org-design counterpart to Dogfood Your Own Product: dogfooding closes the internal feedback loop before customers arrive, while this pattern instruments the external loop so that customer pain is priced back to the specific team that shipped it.

Limits

The account is a single practitioner's description of one company, and the reported ratio is a snapshot rather than a controlled result. The deflection incentive also carries a failure mode that the headline metric cannot distinguish: a falling contact rate can mean the product genuinely stopped generating problems, or it can mean help became harder to reach and some users simply gave up. Charles does not present a counter-source that separates the two. The near-absolute claim of no bug backlog is stated for surfaced bugs at 2023 scale and is not established for later, larger operation. The pattern is legible mainly for products whose users a company can instrument at high volume, and it presumes the organizational will to let a red metric actually stop a launch.