The spike after the support ticket closed

Three weeks ago we watched a user — we'll call them R — close a support ticket on day 14 of their paid account. The ticket was about a data export that had silently dropped four columns. Support resolved it in under two hours. CSAT came back 4 out of 5. If you stopped reading the story here, this is a recovered user. Retention dashboards green. Move on.

Except R didn't move on. Within 48 hours of that ticket closing, R touched 11 distinct features. Eleven. Their previous 13 days had averaged 2.3 features per session. The activity spike was so visible it tripped an internal engagement alert — the kind that, in most tools, would tag R as "highly activated" or "power user emerging."

Here's what those 11 features actually were: settings, integrations page, export (again), billing, team permissions, API docs, a webhook they'd never configured, the changelog, their usage dashboard, the cancellation FAQ, and — finally — settings again. That is not exploration. That is an inventory.

R was walking through the product the way you walk through an apartment after the landlord fixes something badly. You're not redecorating. You're checking the windows, testing the faucets, looking at the lease on the fridge. You are deciding whether to renew.

We've started calling this pattern a viability audit. It shows up more often than we expected once we knew what to look for. The shape is consistent: a support interaction that technically resolves, followed by a 24-to-72-hour burst of breadth-heavy, depth-light feature usage. The user isn't going deeper into their core workflow. They're scanning the periphery — the parts of the product they haven't evaluated since signup. They are re-running the buy decision with new information, and the new information is: this product can break in ways I didn't anticipate.

What makes viability audits hard to catch is that they produce exactly the metrics we associate with health. Session count goes up. Feature breadth goes up. Time in app goes up. If you score engagement as a composite of these signals, R looks better on day 16 than on day 13. Most behavioral scoring systems would increase R's health score during the precise window when R is closest to leaving.

R churned on day 31.

We went back through five months of anonymized journey data looking for the same shape: resolved support ticket, followed by a breadth spike with no increase in depth on the user's primary workflow. We found 34 instances. Of those, 23 churned within 45 days. That's a 68% churn rate in a population your dashboard just labeled "re-engaged."

The remaining 11 didn't churn, but their usage pattern tells its own story. Nine of them reduced their integration surface — they disconnected at least one tool or downgraded a plan tier. They stayed, but smaller. Only 2 of the 34 returned to anything resembling their pre-ticket trajectory.

There is a tempting conclusion here about support quality, but we don't think that's quite it. The ticket resolution was fine. R said so. The issue is that the need for a ticket at all introduced a question the user hadn't been asking: what else might go wrong that I haven't noticed yet? The audit is the user trying to answer that question. And the answer they usually arrive at is: I don't know, and I'm not sure I trust this product to tell me.

One thing worth noting: we found almost no viability audits among users whose support interaction happened before day 7. Early support contact seems to get filed under "onboarding friction" — annoying but expected. It's the mid-lifecycle ticket, the one that arrives after the user thought they understood the product, that triggers the reassessment. The contract they thought they had with the product just changed, and nobody acknowledged it.

The next time a support ticket closes and usage spikes, it might be worth reading the session log before celebrating the recovery. What the user touched matters more than how much they touched.