Architecture · FS-04
Membership Retention Engine
ARCHITECTURE · $8K–$15K PROJECT BANDEvery active member scored on churn risk nightly from attendance, engagement and payment history, with a different intervention per band, tier mismatches surfaced before a cancellation, and failed cards handled as a fixable event rather than a lost member.
Every figure in this console is sample data, shown to demonstrate the interface. It is not real client data and not a performance claim.
The problem this is shaped around
Attendance drops for three weeks, the member cancels, and the owner learns about it from the billing report. Every signal that mattered was visible the whole time, and nobody had the hours to look at it member by member.
How work moves through it
Stage 1
Signals collected
Check-ins, class bookings, payment events and support contact all write to the member record as they happen.
Stage 2
Scored nightly
Each active member scored zero to one hundred, with the contributing factors stored alongside the score so it can be explained and argued with.
Stage 3
Band determines response
Bands get materially different treatment — an automated nudge at one end, an owner-signed message and a phone call at the other.
Human step
Owner works the red band
The highest-risk members arrive as a short daily list a person actually acts on, rather than a dashboard nobody opens.
Stage 5
Outcome measured per band
Save rate tracked per band and per sequence, so the intervention proves its own worth instead of being assumed to work.
Gold marks a step a person takes. There is always at least one, on purpose: the system prepares and displays, a human confirms and executes. That is the rule for money movement and for anything a model extracted from a document, and it is not negotiable on a build.
Decisions taken at the schema, not retrofitted
Score history is retained, not overwritten
A member at 70 and falling is a different situation from a member at 70 and recovering. Storing only the current value throws away the direction, which is most of the signal.
A failed payment is an event, not a status
Cards fail for expiry, for limits, for fraud holds. Collapsing all of it to 'delinquent' loses the distinction between a member who is leaving and a member whose card expired.
Integration credentials belong to the client
Google, the payment processor, the bank aggregator, the messaging bot — each is registered under the client's own account and authorised by them through the provider's own flow. We never hold their password and they can revoke access at any moment without asking us. It costs an extra onboarding step and it means the client is never locked in by a credential they do not control.
One database per client, not shared tables
Each build runs in its own container against its own database with its own credentials. Isolation by table prefix inside a shared database is the mistake this replaces: it works until one missing filter in one query shows a business its competitor's numbers, and by then the whole schema depends on it.
Where it breaks, and what it does about it
Anything can be made to work on a good day. This is the list that decides whether a system survives a bad one — and the honest cost of each answer, because none of them are free.
| When this happens | The system does this | What that costs to build |
|---|---|---|
| A member is scored high-risk while on holiday | Known absences suppress the score rather than distorting it, and the suppression is visible so nobody wonders why a quiet member is not on the list. | An absence concept that staff have to actually record. |
| The nightly scoring job fails | Yesterday's scores are shown with a stale marker rather than a blank dashboard, and the failure raises an alert. A retention list that silently stops updating is worse than one that is visibly a day old. | Job monitoring and a stale state in the interface. |
| A win-back sequence reaches someone who already cancelled | Sequences check membership state at send time, not at enqueue time. The gap between those two is where the embarrassing message lives. | Send-time state checks on every queued message. |
What this deliberately does not do
- It does not cancel or downgrade anyone. It surfaces the mismatch and a person makes the offer.
- Churn risk is a probability from behaviour, not a certainty, and it is never shown to the member.
- No-show fees are charged only under a configured grace policy that a person sets, and a first offence gets a warning rather than a charge by default.
- It does not replace the billing system. It reads from it and acts on what it sees.
Book an architecture scoping session
An hour on your actual operation — where the work currently queues, what gets re-keyed, which step everyone has quietly built a spreadsheet around. You leave with a diagram like the one above drawn for your stack, whether or not you build it here. Scope is written before any payment, always.
The linked walkthrough is an interactive demo, not a deployment: it runs entirely in your browser with sample data and resets when you refresh it. This page describes the architecture built when a business commissions the system — not a claim that this particular one is running anywhere. Systems are built on infrastructure we operate, and your data stays yours and is exportable on request at any time, including if you leave.
FS-04 · membership-retention