Catch churn signals and answer them

Churn is visible in the product months before it is visible in a conversation. An account stops running the weekly export, then stops inviting new users, then renews out of inertia once and not twice. None of that reaches the team whose job it is to notice, because noticing means someone opening an analytics dashboard for every account every week and comparing it to what they remember.

The data is complete and already collected. What is missing is the comparison, run every week by an AI agent against a baseline that does not fire every summer.

How customer churn signals show up in usage

Each week, PostHog activity for every active paying account is compared across two windows: the last 30 days against the 90 before them. The comparison window is the entire difference between a list people act on and a list people mute. Thirty days against the previous thirty means every account with a European August looks like it is churning, and the first week of September fills the list with alerts that resolve themselves. Thirty days against the preceding ninety absorbs the holiday and still catches a genuine three-month slide, which is the shape actual churn has.

Three measures are kept apart, because they mean different things:

• Active users. A fall here is an adoption problem.
• Events per active user. A fall here means the people still using the product are doing less with it, which is usually worse.
• Breadth of features used. Narrowing to a single feature is the clearest early signal there is.

An account is flagged when any of the three falls by more than 30% and it has more than a trivial baseline, since below that the percentages are noise. Breadth catches the case volume hides. An account whose event count is stable but which has narrowed from six features to one is in more trouble than an account that is down twenty percent across the board, because it has quietly become dependent on a single thing it could replace. Averaged into one health score, that account looks fine.

Telling churn apart from an ordinary drop

Before a drop counts as a signal, the explanations that are not churn get checked. Seasonality is compared against the same period last year where the data exists. An outage, or a release that changed how events are recorded, shows up next, since a renamed event looks exactly like abandonment. Fewer users because seats were removed is a contraction, and that is a different conversation from disengagement. Anything explained this way is counted and set aside, and never emailed.

When a churn signal needs a call

For the accounts still flagged, the HubSpot record comes in: plan, renewal date, owner, support tickets and the last contact of any kind. Two findings change what happens next. A renewal inside ninety days goes to the account owner as a call, with the reason attached. A support ticket that went unresolved shortly before the decline started is very likely the cause, and the handover says so plainly, since a reactivation email that ignores the complaint behind the problem makes it worse.

What the reactivation email says

Every other flagged account gets one email, drafted for the person who was most active before the decline, because they are the one who can say what changed. It names the specific behaviour. "You have not used the weekly export since March" invites either "we switched to doing it in the warehouse" or "it broke and we gave up", and both are worth knowing. "Your usage has declined" invites nothing, because there is no question in it, and it tells the recipient that somebody ran a report instead of looking at their account.

After that comes one question about what changed, cheap to answer, with no discount, no feature pitch and no calendar link. The draft is held, and nothing goes to a paying customer before a person has read it.