Membership database: what to record so renewals do not depend on memory

A membership database exists to answer two questions on any given day: who is a member right now, and whose membership is about to end. Organisations that cannot answer the second question do not have a retention problem, they have a data problem — renewals lapse quietly and the shortfall appears in the accounts a quarter later, by which time the conversation that would have saved them is long past.

The fields a membership database needs

• Member identity and a stable member number that survives a name change.
• Category — individual, household, student, life, corporate — because the renewal rules differ by category.
• Join date, and the current period start and end dates as real dates rather than a year.
• Payment method and whether it renews automatically, which changes what you do at expiry.
• Status: current, in grace, lapsed, resigned, or deceased. Five states, each meaning something different.
• Consents and communication preferences with their dates.
• Any entitlements attached to the category, so a claim can be checked.

The renewal cycle, written down

1. Sixty days out: report of expiring memberships, checked for failed payment details.
2. Thirty days out: renewal notice with what the member got this year, not only what it costs.
3. At expiry: move to grace rather than to lapsed, and record the grace end date.
4. Grace end: final notice, with a named person to reply to.
5. After grace: set to lapsed, stop the entitlements, and keep the record rather than deleting it.
6. Ninety days after lapse: one reactivation contact, then leave them alone for a year.

Grace periods only work if the system knows about them. An informal grace held in someone's head produces members receiving benefits they have not paid for and lapsed members nobody chased.

Why the spreadsheet breaks

A spreadsheet can hold the list but not the cycle: dates do not fire, statuses get overwritten without history, and last year's version is the only record of who was current then. A register with one row per member, real date fields and a status column turns "who expires next month" into a filter — Ettex Records does that, with the renewal notices going out through Ettex Mail from the same rows, and joining forms arriving via Ettex Forms so a new member is never typed in twice.

Reports worth producing monthly

• Current members by category, with the change since last month.
• Expiring in the next sixty days, split by automatic and manual payment.
• Renewal rate for the period, by category — the single number that predicts next year.
• Lapsed last month, with the reason where you know it.
• New joiners by source, so recruitment effort can be aimed.

The discipline is the same one that makes donor management work: a person-level record with history, not a transaction log. Organisations that run both — members and donors — should keep one record per person with both relationships on it, otherwise the same household gets two mailings and one of them will be wrong.