Your support team found the leak six weeks ago

Here is a conversation that happens in almost every company I've sat in.

A metric drops. A room full of people spends two weeks working out why. Somebody finally suggests asking support. The support lead says, more or less: "Oh, yeah — we've been getting those since the update. I mentioned it in standup."

They did mention it. Nobody was listening for it, because a support ticket is filed as a cost to be resolved rather than a signal to be read, and there is no path from "we're seeing a lot of these" to "this is a revenue problem worth a room."

Support is your earliest and most specific leak detector, and in most companies it is structurally disconnected from anyone who could act.

Why support sees it first

Two reasons, both mechanical.

Support is a leading indicator; metrics are lagging. A customer confused by a checkout change contacts you the same day. That confusion shows up in your repeat-purchase rate 30 to 90 days later, once enough of them have failed to return for a cohort to move.

Support gets specificity that analytics cannot produce. Your funnel tells you customers dropped at step three. A ticket tells you "the shipping cost wasn't shown until after I entered my card and it felt like a bait and switch." That sentence contains the mechanism, the emotional response, and the fix. No amount of event data reconstructs it.

Strong association across the accounts we work with, when a revenue leak is eventually diagnosed, the corroborating evidence is almost always already present in support tickets, dated weeks earlier than the metric movement. We call this strong association rather than causal because we're observing it retrospectively, and cases where support saw nothing are less likely to become case studies.

Why the signal doesn't travel

Not because support teams are bad at their jobs. Because of how the work is measured and structured.

Resolution time is the metric. A support team optimizing for time-to-close is optimizing for handling each ticket as an isolated unit. Noticing that four hundred of them share a cause is unrewarded work that makes your average handle time worse.

Categories are built for routing, not diagnosis. Most tag taxonomies exist to get a ticket to the right agent. "Billing," "Shipping," "Technical." Those categories are too coarse to detect that shipping complaints changed character three weeks ago.

There's no escalation path for a pattern. Every support tool has a path for escalating an individual ticket. Almost none has a path for escalating a trend. The support lead who notices something has to find the right person, in the right team, and be persuasive — a social problem, not a systems one.

Volume swamps the signal. Forty complaints about a new issue inside two thousand weekly tickets is 2% and invisible on any volume chart. It's also, potentially, the leading edge of a leak affecting every customer who hits that flow.

What to actually measure

Three things, in order of implementation difficulty.

1. Contact rate per cohort, not ticket volume

Total volume tracks how many customers you have. Contact rate — the percentage of a given cohort that contacts support within N days of first purchase — tracks whether your product is getting harder to use.

Plot it by acquisition week. A step change in contact rate for cohorts acquired after a particular date is the same signal as a step change in second-order rate, arriving weeks earlier.

2. Reason clustering on ticket text

Your existing tags won't do this; they're too coarse. Cluster on the actual text and look for emerging groups rather than growth in established ones.

The interesting object is a cluster that didn't exist last month. Forty tickets about unexpected fees is not a spike in "Billing" — it's a new thing, and new things have causes with dates.

3. Contact-to-repeat correlation

This is the one that converts support data into money.

For each reason cluster, compare subsequent purchase behaviour between customers who contacted about that issue and a matched cohort who didn't.

Some issues are neutral or positive — a well-handled problem can increase loyalty. Others are terminal: customers who contact about them essentially never return. Those are the expensive ones, and their cost is entirely invisible in support reporting, which measures whether the ticket was resolved rather than whether the customer stayed.

Ranking reason clusters by revenue impact rather than by volume usually reverses the priority list.

What it costs

Tickets in a reason cluster
  × (subsequent purchase rate of matched non-contacting cohort
     − subsequent purchase rate of contacting cohort)
  × lifetime value
  = revenue cost of that issue

Plus: customers who hit the same issue and never contacted you.

That last line is the multiplier nobody applies. Only a fraction of affected customers contact support — most just leave. If your contact rate for an issue is 5%, the population experiencing it is twenty times the ticket count.

Which means a forty-ticket issue may be an eight-hundred-customer issue, and the version of the number that gets reported to leadership is the forty.

Who has to fix it

The structural fix is not "support should communicate better." It's giving a ticket pattern the same escalation weight as an individual angry customer — a room, an owner, and a dollar figure.

In Flolyt, the Support Signal agent watches reason clusters and contact rates, and opens a Room when a new cluster emerges or an existing one shifts against expectation. The Room carries the cluster, the affected cohort, the repeat-behaviour delta, and the owning teams. The agent surfaces revenue-relevant contacts; it cannot reply to a customer.

The play

• Instrument contact rate per cohort, not ticket volume. Day one change, immediate value.
• Cluster on text, not tags. Watch for new clusters rather than growth in old ones.
• Join tickets to purchase behaviour. This is the step that makes support data legible to a CFO.
• Create a pattern escalation path. A named threshold at which a support lead opens a room rather than raising it in standup.
• Rank issues by revenue cost, not volume. They will be different lists.

How you'd know it worked

If you fix an underlying cause, measure contact rate for that specific cluster in cohorts after the fix against cohorts before, at matched maturity. Total ticket volume is far too noisy to detect one issue resolving.

Then check the downstream number: does subsequent purchase rate for customers who would have hit the issue recover to match the unaffected baseline? That's the revenue confirmation, and it lags the support confirmation by a purchase cycle.

Guardrail worth setting: watch for contacts migrating rather than disappearing. Sometimes a fix in one flow relocates the confusion to the next one, and cluster-level monitoring catches that where volume monitoring won't.

What we can't tell you yet

We can't tell you what share of affected customers contact support. It varies enormously by issue severity, customer segment, and how easy you make it to reach you — and the very customers who don't contact you are the ones you have the least data about. Any multiplier we gave you would be a guess wearing a decimal point.

We also can't fully separate causation from selection in the contact-to-repeat correlation. Customers who contact support differ from those who don't in ways beyond the issue itself. The label stays strong association — enough to prioritize, not enough to claim the issue caused the churn.