Winback starts before the cancel button, not after

By the time someone clicks cancel, they decided weeks ago. The cancellation is the paperwork. A winback flow that starts at cancellation is a goodbye card with a discount stapled to it. The real work is earlier: spot users going quiet and reach them before they cancel, not after.

The hard part is defining “quiet,” because it is different for every product. Here is how we did it for ours.

Our situation

GetFluxly is the kind of product a healthy customer does not open every day. Once automations are running, the whole point is that you stop thinking about them. So “has not logged in for a week” tells us nothing. Our best customers trip that wire constantly.

We had to define quiet on the customer’s data instead of their visits. A healthy GetFluxly account has two pulses: events flowing in, and automated emails going out. Either one can stop silently, and each stop means something different.

What to track

• events_ingested, a daily count per project, from which we derive events_stopped: three straight days of zero on a project that was previously active
• automated_emails_sent, from which we derive sending_stopped: fourteen quiet days on an account that used to send
• last_seen_at, a profile trait updated from sessions
• Subscription status, because winback runs on paying accounts only. Trials have their own sequence, and mixing the two produces nonsense.

Triggers, conditions, and the rules we took

Three signals, three different emails, escalating in how human they get.

1. On events_stopped, same day. This is a service email, not marketing. When a previously active project goes to zero, it is almost never a decision to leave. It is a deploy that dropped the snippet, a domain change, a consent config change. Treating it as churn risk would be tone deaf. Treating it as an outage on their behalf builds the kind of trust that prevents churn.
2. On sending_stopped, within a day. Their automations went quiet, which means their users stopped getting emails and they probably have not noticed. Show what the account sent in the previous period so the silence has a shape.
3. At 21 days of no login combined with either signal above: the founder email. Plain text, no design, no button. One question. Replies go to a human, and answering them is the actual winback.

Guardrails: any activity exits everything, a login, an event arriving, sending resuming. Never more than one winback email in a week. And winback is suppressed entirely while a failed payment sequence is running, because “we miss you” next to “your card declined” is how you end up in a screenshot.

The timeline

There is no fixed calendar here, which is the point. Day 3 of silence for the tracking alert, day 14 of no sends for the automation nudge, day 21 of compound quiet for the founder note.

Each clock starts from the customer’s behavior, and each resets the moment they come back.

The emails

1. Tracking stopped (service tone)

GetFluxlyhello@getfluxly.com

ON EVENTS STOPPED

Your event tracking went quiet on {{last_event_date}}

---

Hi {{first_name}},

{{project_name}} was receiving events steadily, then stopped three days ago. That pattern is almost always a deploy that removed the snippet, not anything you chose.

Two ways to check:

Open the live event feed (if events show here, you are fine)

Reinstall guide (takes about a minute)

If you paused tracking on purpose, ignore me. Otherwise, reply and I will help you find where it went.

2. Founder check in (21 days quiet)

GetFluxlyhello@getfluxly.com

21D QUIET · NO LOGIN

Is GetFluxly still doing its job?

---

Hi {{first_name}},

I noticed your account has been quiet for about three weeks. No pitch here, just one question:

What is not working?

Missing feature, confusing screen, wrong tool for the stage you are at. Any answer helps, including blunt ones. I read and reply to every one of these myself.

MD, GetFluxly

Setting it up

1. Find your product’s pulse, the one or two streams that indicate the account is alive. For us it is events in and sends out. It is probably not logins.
2. Derive the stop signals server side with a threshold that respects normal gaps. Three days for a daily pulse, fourteen for a weekly one.
3. Write the first email as an outage notice, not a campaign. Tone is the feature.
4. Save the founder email for the compound signal, and only send it if you will actually read the replies.
5. Exit on any activity, cap at one email a week, and never run winback and dunning at the same time.