Ask where support reports in most companies and you'll hear: "Operations." Or "Customer Success." Or "the CEO, technically, but nobody really owns it."

The reporting structure determines the incentives. And the incentives determine the outcomes.

When support reports to Operations, the primary metric is cost. How do we handle more tickets with fewer people? How do we reduce cost per ticket? How do we automate more? Operations optimizes for efficiency. Support becomes a cost to minimize.

When support reports to Product, the primary metric is insight. What are customers telling us? What's broken? What's confusing? What's missing? Product optimizes for learning. Support becomes an intelligence system.

Both are valid perspectives. But only one makes support better over time.

The Operations Model

Support under ops looks like this: headcount is minimized, automation is maximized, SLAs are set by cost constraints (not customer needs), and the team is measured by throughput (tickets per agent per day).

This model works in the sense that it keeps costs controlled. But it creates a ceiling. Support can only get cheaper, not smarter. The insights in the ticket data go unused because nobody in the ops org is looking for product insights. They're looking for ways to reduce handle time.

The team feels like a cost center because it's managed like one. Agents don't contribute to product decisions. Their feedback goes into a black hole. Morale is low because the work feels extractive: handle tickets, hit targets, repeat.

The Product Model

Support under product looks like this: the support team is treated as the customer intelligence arm of the product organization. Ticket data feeds product decisions. Support agents participate in product reviews. Bug reports from support get prioritized alongside engineering-originated bugs.

The team still handles tickets. They still need to be efficient. But the optimization goes beyond cost: how do we use support interactions to make the product better, which reduces future support volume, which reduces cost naturally?

This creates a virtuous cycle. Support identifies a confusing UI element. Product fixes it. Ticket volume for that category drops. Cost goes down. But it went down because the product improved, not because support got squeezed harder.

The Practical Differences

Under ops: a support agent notices that 30 tickets per week are about the same confusing settings page. They flag it in a weekly report. The report goes to the ops manager, who includes it in a monthly summary, which the product team may or may not read. Three months later, nothing has changed. The agent stops flagging things.

Under product: the same agent notices the same 30 tickets. They post in the support-product Slack channel with a screenshot and ticket count. The product designer reads it on Tuesday. By Thursday, there's a UX mockup for a clearer settings page. It ships in the next sprint. Ticket volume drops.

The difference is the distance between the observation and the decision-maker.

The Hybrid Model

If moving support entirely under product isn't feasible (often the case in larger orgs where support handles operational tasks like billing and account management), create a hybrid:

Support operations (staffing, tools, queue management) stays under ops or a dedicated support VP.

Support insights (product feedback, bug reporting, feature request aggregation) has a dotted line to product.

A weekly meeting between support and product (the 15-minute sync) formalizes the feedback loop.

This gives support operational structure while ensuring the intelligence function isn't lost. It's not perfect (dotted lines are weaker than direct reporting), but it's better than the pure ops model where product feedback dies in a spreadsheet.

What Changes When You Do This

Agent retention improves. Agents who see their feedback lead to product changes feel valued. They're not just closing tickets. They're shaping the product. That meaning reduces turnover.

Product quality improves. The product team gets real-time, unfiltered customer feedback instead of quarterly survey summaries. Decisions are informed by actual usage, not assumptions.

Support volume decreases over time. Every product improvement that reduces confusion or fixes a bug eliminates the corresponding ticket category. Under the ops model, volume is managed through automation. Under the product model, volume is reduced through improvement. Reduction is better than management.

Cost decreases naturally. Not because you squeezed the support team harder, but because there are fewer tickets to handle. The cost reduction is a byproduct of product improvement, not the goal.

The Org Chart Is a Strategy Decision

Where support reports is a strategy decision about whether support data becomes product intelligence or gets compressed into cost metrics.

If you're a startup with under 50 people, support probably reports to the founder or CEO, which means it's effectively product-adjacent. Keep it there as long as possible.

If you're growing and need to formalize, think carefully about where support goes. The default (operations) is the wrong choice for product-led companies. The right choice is wherever the support data will be most valued and most acted upon.