Subscription Funnel

The situation

The offer was a three-tier recurring membership. Members joined, paid monthly, and some of them stopped paying without ever deciding to leave. Their card expired, or a charge was declined, and the subscription simply ended.

Nothing chased those payments. There was no dunning, no retry messaging, and no notification to anyone that a paying member had just become a former one.

There was no route up, either. Moving between tiers required a conversation, so members who had outgrown their tier stayed on it or left. And the owner had no view of which tier people were dropping off at, which made the whole thing unfixable by inspection.

What was broken

• Failed payments ended subscriptions silently, with no retry and no recovery message.
• There was no upsell path at all, so an upgrade depended on someone having a conversation.
• Content access was not tied to live payment state, so the gate and the billing were two separate truths.
• The owner had zero visibility into which tier members dropped off at, or why.
• Retention messaging, where it happened, ran on a shared calendar rather than on each tier's own billing clock.

Constraints

• Billing lives in Stripe, so recovery had to be driven by real subscription events rather than by a guessed schedule.
• The three tiers differ in timing and in what they include, not in mechanism, so one machine had to serve all three.
• Every retention send had to be opt-out aware. A save sequence is exactly where an unsubscribed member gets messaged by accident.
• Nothing in the build could depend on the owner noticing a failed payment.

What I built

Two events start the same machine: a declined charge, and a member reaching the edge of what their tier includes. Recovery and upsell are the same funnel viewed from two directions, which is why they share the access gate underneath.

The conditional access gate

Content across the three tiers is gated on live subscription state rather than on a manual list. This is the quiet load-bearing piece. Access that is not tied to payment state keeps serving people who stopped paying, and it also makes dunning pointless, because nothing changes when the money stops.

Dunning that runs itself

A declined charge goes straight into Stripe dunning: the retry, plus the payment-recovery messaging alongside it. Churn revenue recovers itself instead of walking out unnoticed. A branch then checks whether the retry actually took the money, because "we sent a retry" and "we got paid" are different states.

The save sequence

If the retry did not rescue the member, a multi-channel save sequence opens. It runs on SMS and on email, so a member who ignores a text still gets a route back. Sends are timed against that tier's own billing cycle rather than a shared calendar, since a member three days from renewal and one three weeks out need different urgency.

The upgrade path

A dynamic pricing table shows the tier options in context, priced against what the member already has. A one-click upsell then moves them up without leaving the flow they are in. That path did not exist before, which is why upgrades used to require a conversation.

Drop-off visibility

Every outcome, saved or lost, is written back against the tier and the step of the save where it happened. The original diagnosis was a measurement failure rather than a marketing one, so the build ends in a reporting surface rather than a send.

Edge cases and failure handling

• A retry that succeeds: the member is marked saved and never enters the retention sequence, so nobody gets chased for money that already cleared.
• A retry that fails because the card is genuinely dead: the save sequence opens instead of the subscription just ending.
• A member who has opted out of a channel: the guard suppresses the retention send on that channel rather than letting a save sequence override consent.
• A member who never answers: the non-response is logged against their tier and their step, so a silent loss still produces information.
• A member at a tier boundary rather than a billing failure: the same gate routes them to the pricing table and the upsell instead of to dunning.

How I verified it

The verification evidence for this build is thin, and I will not dress it up. There is no test suite or read-back record in the material I hold for it. The system does provide its own check. The recovered-or-not branch after dunning distinguishes an attempted retry from a successful one, and the drop-off reporting shows where members actually leave. Both were built so the owner could see the machine working rather than take my word for it.

What changed

+35% membership retention, measured. Churn revenue recovers automatically instead of walking out the door, because the failed charge is now retried and chased without anyone noticing it first.

The owner also has something they did not have before. A clear view of drop-off across all three tiers, showing which tier a member left at and at which step of the save. That is the part that keeps paying off, because it turns the next retention decision into a reading rather than a guess.