How to predict membership churn from attendance data

Every check-in, class booking and no-show in your business is a timestamped record. Somewhere in that pile is the fact that a member whose habit was four sessions a week has trained once in the last two weeks. That is the most actionable thing you could know about them, and in most membership businesses nobody reads it. The data expires unused, and the first time anyone looks is when the card declines or the cancellation arrives.

Churn prediction from usage data is not a machine-learning project. It is a handful of fields, a nightly calculation and a routing rule. The hard parts are getting attendance onto the member record reliably, choosing the right denominator, and building the suppression logic that stops it becoming harassment.

Why total visits tells you nothing about churn risk

Most operators already have an attendance report: visits per week, visits per member, maybe a leaderboard. It is almost useless for predicting churn, for one reason. It ranks members against each other.

Rank your base by visits and the bottom of the list is your twice-a-week members, who have been twice a week for two years and are perfectly happy. The member who has gone from five sessions to two sits in the middle of the table, invisible, and is the one actually leaving. Absolute frequency describes a preference. Change against a member's own history is a signal.

So the first design decision is the denominator. You are not asking whether a member trains a lot. You are asking whether they train materially less than they themselves used to. Those two questions produce different lists, and only the second is worth working.

The one number the whole engine turns on

You can build a usable risk engine around a single ratio:

• Baseline weekly visits: the member's own rolling average over the trailing eight weeks, recalculated weekly, excluding any full week they were frozen.
• Visits in the last fourteen days: recalculated nightly.
• Attendance ratio: visits in the last fourteen days divided by twice the baseline. A member holding their own pattern sits near 1.0. A member who has halved sits near 0.5.

One guard is needed immediately: where the baseline is below one visit a week, floor the divisor, or a once-a-two weeks member will produce a wildly unstable ratio that flags them every other week.

From there you add the components that catch things the ratio alone misses:

1. Days since last visit, read relative to that member's normal gap. Eight days is unremarkable for a once-a-week member and alarming for a daily one.
2. No-shows in the last thirty days. Booking and not attending is a distinct and early signal: intent is still there, the habit is going.
3. A declining booking trend. Members often stop booking ahead before they stop attending.
4. Any failed payment in the last sixty days. Billing friction and disengagement travel together.

Weight those into a single score out of a hundred, with the ratio carrying the most weight, and derive a band from the score: healthy, softening, at risk, critical. The band is what routes the member. The score is what you tune.

What has to be true before you can score anything

This is where most attempts die, so the prerequisites are worth stating plainly.

• A reliable attendance event source. Check-ins, class bookings and attendance statuses must arrive on the member record with timestamps, every day. If a meaningful share of your base trains without checking in, the engine will flag healthy members as at risk and your team will stop trusting the list inside two weeks. Fix the capture first. Where no direct connector exists, relay events through a middleware tool such as Zapier or Make, accepting that a scheduled import means the engine runs a day behind.
• Thresholds signed off by the owner. What ratio and what gap constitute each band. Start deliberately conservative.
• Every member mapped to a named coach. Unassigned members generate tasks nobody owns.
• A named person who works the daily list. The entire value of this build is a short list of names each morning. If nobody is accountable for it, you have built a dashboard.

The attendance-based churn prevention build guide sets out the pipeline, the field list and the eight workflows in full. The sections below are the method, so you can decide whether it fits your data before you look at the spec.

How to build an attendance-based churn model

Step 1: Separate new members from the decay logic

A member in their first thirty days has no baseline, so decay rules cannot apply. Put them in their own stage with a ramp check rather than a decay check. If a new member has trained fewer than twice in their first two weeks, that is a coach's phone call, not an automated nudge.

Step 2: Recalculate nightly, and keep the job silent

One scheduled job in the small hours rewrites visits over seven, fourteen and thirty days, days since last visit, the attendance ratio and the score, then derives the band last. Two rules matter. First, the job must be structurally incapable of sending a message. A recalculation at two in the morning that can text someone is an accident waiting to happen. Second, act on change only: when the derived band differs from the stored one, copy the old value into a previous-band field, stamp the change date, move the stage, swap the tags, and raise an event for the touch workflow.

Step 3: Recalculate baselines weekly, not nightly

Baselines should drift with the member, slowly. Once a week is right. A member who genuinely settles from four sessions to two will, over a couple of months, be measured against two, which is correct. Recalculating nightly makes the standard chase the decline and hides the pattern you are trying to catch.

Step 4: Derive the fields that make messages specific

In the same weekly job, compute each member's favorite class from their booking history and the two weekdays they most often train. These two fields are the difference between "we have not seen you in a while" and "there is a spot in your usual Thursday class at six". The second is a message from someone who knows them. The first is a mailshot.

Step 5: Store the direction of travel, not just the position

Keep a previous-band field and a band-changed date. Direction of travel lets workflows fire on a member who has just dropped from healthy rather than on everyone currently in a band, which is what stops a member whose score oscillates around a threshold from being messaged weekly.

Step 6: Match the responder to the severity

The band should decide who responds, not how loud the message is.

• Softening: one light automated message naming their class and offering two upcoming slots on their usual days, followed if there is no response by a single one-tap question asking what is getting in the way, with four options. The answer routes the branch: a time problem gets shorter formats, a schedule problem gets alternative slots and an offer to move their standing booking, a motivation answer gets a short coach check-in. No third message at this band.
• At risk: a human, every time. The task goes to the assigned coach with the whole picture on it: baseline, recent visits, days since last visit, their usual class and days, whatever they said the barrier was, and who last spoke to them. The instruction is explicit: write a personal message in their own thread, do not use a template. A coach messaging from a position of having noticed is the intervention. An automated message pretending to be that is worse than nothing.
• Critical: owner level, with a real option in the message. Not a nudge, an offer of a proper conversation in which a lighter plan, a different shape of membership or a pause is genuinely on the table.

Step 7: Build the suppression layer before the sending layer

This is the part that determines whether members experience the system as attentive or intrusive, and it should be built as always-on rules evaluated before any send:

• Block if a suppression tag is present. Apply that tag on any human conversation, any inbound reply, any mention of a physical or health reason, and any request to be left alone, and expire it automatically after two weeks.
• Block if a coach spoke to the member in the last week, whatever the score says. A human's message takes precedence over the system's.
• Block if the member has hit their intervention cap for the quarter. Create a task instead, so a person decides whether they need a conversation.
• Block and queue anything that would land inside quiet hours, in the member's own time zone, rather than dropping it.
• Block entirely if a cancellation has been requested. A member who has asked to leave must not get a retention nudge the next morning.

Step 8: Detect recovery and close the file

Risk engines that only escalate end up with everyone flagged. Define recovery explicitly. Visits in the last seven days at or above the recalculated baseline for two consecutive weekly evaluations, then clear the tags, move the member back, and record which band they recovered from so recovery rate can be reported by entry band. Tell the coach, so the acknowledgement comes from a person rather than an automated message.

Mistakes that make churn scoring useless

Mistake 1: Launching on unreliable attendance data

Every other mistake is recoverable. This one poisons the list. If check-ins are patchy, the engine's first output is a set of confident false positives, and the team will correctly conclude the list cannot be trusted.

Mistake 2: Turning the messaging on at the same time as the scoring

Run it silently for two weeks. Score everyone, send nothing, print the lists and read them against what your coaches already believe about those members. Tune the thresholds against that comparison, then enable sending.

Mistake 3: Letting the system talk about health

If a member says something hurts or they have been unwell, the correct automated behavior is one acknowledgement, suppression, and an immediate handoff to a coach. No advice, no reassurance, no suggestions. The barrier question should capture the fact that there is a physical reason and store no description. It exists to stop the messaging, not to build a health record.

Mistake 4: No accountability loop on the human steps

If an at-risk task sits uncompleted for two days, it must escalate to a manager. Without that loop the build degrades into a dashboard nobody reads.

Mistake 5: Showing the score to the member

The score is an internal routing device. Members should be able to understand from your privacy notice that attendance data is used to support engagement (be straightforward about that rather than treating it as a secret) but a number should never be surfaced to them, and access to it belongs to coaches and management through role permissions. Automated profiling, consent wording and retention periods are governed differently in different places, so confirm yours with your own counsel before launch.

What to measure once the engine is running

• Band distribution and weekly movement. The net flow between bands matters more than the standing count in each.
• Recovery rate by entry band: the share of members who return to healthy, split by whether they were caught at softening, at risk or critical. This is the number that proves early detection pays.
• Median days from band change to first human touch. The operational discipline metric. If it drifts past a couple of days, the daily list is not being worked.
• Churn rate by last band held. If members are churning straight out of healthy, your thresholds are wrong and need retuning.
• Attendance ratio distribution across the active base, monthly. A shift in the middle of that curve is the earliest sign of a timetable or staffing problem rather than an individual one.

Churn scoring is the back half of a retention system; the front half is trial conversion and the first thirty days, which the membership onboarding and retention guide covers. To work out whether your check-in data can feed an engine like this, book a call and we will look at the event source first: that is the part that decides everything else.

Frequently Asked Questions

How much attendance history do you need before the scoring is trustworthy?

Eight to twelve weeks is a sensible minimum, because the baseline is a rolling eight-week average and you want one full cycle of it before the engine routes anybody. Start collecting and scoring earlier if you like, but keep the messaging off until baselines stop moving significantly week to week.

Can this work without a door reader or check-in kiosk?

Yes, if something else records attendance reliably. Class bookings with attendance marked, a coach completing a roster, or an app check-in all work. What does not work is inferring attendance from bookings alone: a booked-and-missed session is a risk signal, and counting it as a visit inverts your own data.

How often should a member be contacted about their attendance?

Rarely, and with a hard cap enforced centrally rather than hoping stop conditions catch it. A quarterly intervention limit per member, a block on messaging anyone a coach spoke to in the last week, and two weeks of suppression after any human conversation keeps the volume somewhere members experience as attentive. When the cap is reached, raise a task for a person instead of sending.

What is the first intervention worth building if you only build one?

The daily coach list. Three to five names a morning, each with the member's baseline, their recent attendance, their usual class and days, and the date of their last human contact. No member-facing automation at all. Most of the value in attendance-based churn prevention comes from someone knowing who to notice, and that version can be running in days rather than weeks.