Every Support Ticket is a Product Failure

Treat customer support as product feedback by having support report to product

Geoff Charles
Velocity over everything: How Ramp became the fastest-growing SaaS startup ever | Geoff Charles

Every Support Ticket is a Product Failure

"Every support ticket is a failure of our product. We literally have that as a quote just posted on all those channels. It's a failure. And if the product works perfectly, no one should ever have to contact our support team." - Geoff Charles

What It Is

Every Support Ticket is a Product Failure is Ramp's philosophy that treats customer support as a product quality signal rather than a service function. The most radical implementation of this principle: the support team reports directly into product leadership, not customer success or operations.

This creates structural accountability. When support reports to product, product leaders can't ignore the friction their products create. Every ticket becomes evidence of a product problem to solve.

The second key insight is changing what support teams optimize for. Instead of hiring people focused on resolving tickets (minimizing handle time), Ramp hired people incentivized to decrease tickets over time and increase deflection. This required hiring a "different breed of people" who then became leaders in other parts of the organization.

The result: 400,000+ users on the platform with a support team of under 30 agents—an extreme ratio that demonstrates the philosophy in action.

How It Works

Structural changes:

  1. Support reports to product leadership, not a separate organization
  2. Support metrics are product metrics
  3. Product teams are directly accountable for their operational burden

Hiring changes:

  • Hire for problem-solving and improvement, not just ticket resolution
  • Incentivize ticket reduction and deflection
  • Look for people who can identify patterns and work with product to fix root causes

Measurement changes:

  • Track tickets by product area, normalized by users
  • Create a contract with product teams: maintain low operational burden or you can't ship new features
  • Distinguish between bugs (route to on-call engineer) and confusion (count toward UX debt)

How to Apply It

1. Make structural accountability real Consider having support report to product leadership. "What better way of holding the product team accountable for support other than having support report into product."

2. Track confusion separately from bugs "We track how many support tickets come in that were due to a customer being confused. And if that number is slightly elevated, we're basically saying, 'You can't ship any new features, you need to fix these things.'"

3. Create a product operational burden metric Each product team has a "percentage of operational burden"—tickets from their area normalized by users. Keep this as a team health metric alongside NPS and CSAT.

4. Use first-principles hiring "Instead of hiring people who were focused just on resolving the ticket, we incentivized people to actually decrease number of tickets over time and decrease deflection or increase deflection. And that required hiring a different breed of people."

5. Use support as a career pipeline People hired for pattern recognition and improvement often become leaders elsewhere in the organization.

When to Use It

Good fit:

  • Self-serve products where support interactions represent friction
  • Products that should be intuitive enough to require no explanation
  • Companies where support and product are currently disconnected
  • Organizations ready for structural change

Not a fit:

  • High-touch enterprise products where "support" is really consultative success
  • Situations where support is genuinely a value-add (complex professional tools)
  • Companies without the cultural willingness to restructure

The Counter-Argument

You could pattern match to other companies: hire experienced support leaders, use industry benchmarks, build large support orgs. But Ramp started from first principles: if the product works, why would anyone need to contact us?

The result is a support team roughly 10-15x smaller than what benchmarks would suggest for their user base.

Source

  • Guest: Geoff Charles
  • Episode: "Velocity over everything: How Ramp became the fastest-growing SaaS startup ever | Geoff Charles"
  • Key Discussion: (00:47:00) - Explanation of support philosophy and organizational structure
  • YouTube: Watch on YouTube

Related Frameworks

Back to Execution