Membership management software manages the wrong half

Every product in the membership management software category is built around the same object. A member record with a renewal date on it. Around that sits a payment link, an email tool, and a portal where members can log in and correct their own address. The same category gets sold as membership software, association management software, club membership software and membership CRM, and underneath the names it varies less than the pricing pages suggest.

That's a database with a form on the front, and databases stopped being hard a long time ago. Every one of these products ships a competent one.

The problem is that hardly any of the work of running a membership organisation happens inside the record. It happens in the gap between the record and the money. A bank transfer somebody has to match to a person by hand. A card that stopped working on a Tuesday. A renewal date that went past while nobody was looking. None of that is a storage problem. Follow-up is a different job, and a database can't do it.

Ask someone who actually does the admin what their system is, and the software is usually half the answer.

Tim Reay, treasurer of an association, laid it out. Payments arrive by card or by bank transfer, and "renewal by card payment is automatically recorded and copied/pasted into the membership spreadsheet. Bank transfers I have to manually record each one." Even the automated route ends in a copy and paste. The place that association actually keeps its membership is the spreadsheet, not the tool that took the payment. The card route also costs about 3% in fees, by the same account.

That spreadsheet isn't a failure of discipline. It's where the parts the software leaves separate get joined up. When the Faversham Society went looking for a volunteer to help with membership admin, the advert opened with a question: "Are you good with a spreadsheet?"

The spreadsheet is the integration layer, and the volunteer maintaining it is the integration.

Every hour that person spends is a reconciliation the product declined to do. It's also the part of the setup that walks out the door when they do.

One account puts numbers on what the gap costs. Beowulf Urban, who runs subscription ecommerce brands, pulled a payment errors report while doing an analysis for an unrelated reason, then published what was in it.

Eighteen months of subscription billing. $30,392 of charges failed and $14,289 was recovered. 193 subscribers churned purely because a payment failed, which came to 9% of all churn. And then: "Not one of them decided to leave."

The distinction that account draws is between a hard decline, where the bank is refusing and no amount of retrying helps, and everything else. An expired card. A reissued card. Money not being in the account on the day the charge went out. That second group is recoverable, and it was being handled exactly like the refusals.

Membership organisations hit the same thing. One operator collecting gym memberships reported a 22.9% direct debit failure rate in a single month, said about half usually complete on a second attempt, and expected the rest to cancel.

None of this looks like a decision. Nobody resigned. Nobody complained. The member record says active until something changes it, and the thing that changes it is a person noticing.

Unpaid dues behave the same way. They don't announce themselves.

One former treasurer of a homeowners association went back through every statement for 21 years and found $83,000 missing. Nobody caught that in a monthly report. It surfaced because a person decided to reconcile two decades by hand. In the same conversation, a homeowner said their association had "casually admitted that half the people in the HOA didn't pay dues last year."

Software can also be quietly wrong about your organisation. Dale Koetke reported that a membership platform was treating members created before a certain date as being on automatic renewal even though they sat in manual-only levels, and that it was blocking a membership drive. The record said one thing, the organisation worked another way, and people who wanted to renew couldn't.

Migrations have their own version. One association told members its portal was offline while all the membership data moved to a replacement. For that stretch, nobody owns the answer to who is a member.

Three different failures, and in all three the information existed somewhere and nothing was reading it.

That same account also says what the fix turned out to be.

"The part that bothers me is that none of it is a build. It's settings. Card updater, retry timing that knows the difference between a soft and a hard decline, a dunning email that comes from us instead of a generic address and says what actually happened."

And on how long it had been sitting there: "This one was sitting in a report I'd had access to the whole time."

That's the shape of every failure above. The bank transfer was in the statement. The failed payment was in a report. The lapsed member was in the database with a date in the past. What was missing was something that reads all of it on a schedule and does the next thing.

That's a job rather than a feature. It's the job the treasurer is already doing between the record and the money, and it's the one part the membership tool leaves out, because doing it means acting instead of storing.

An agent fits in that gap. It reads the payment report on a schedule, separates a card that expired from a bank that refused, matches the bank line back to the member so nobody copies and pastes, and sends the follow-up that says what actually happened, from the organisation rather than a no-reply address. Renewals that haven't happened get raised while there's still time to ask for them properly. The membership record stays exactly where it is. Something else does the chasing.

The same argument applies to any workflow that only exists between two systems. The work is real, it runs on a schedule, and it has never had an owner.

These are the questions the evidence above suggests, roughly in the order that decides how much manual work survives the purchase.

1. What happens on the day a payment fails? If the answer is that a status changes, that's a record, not a response. Ask what acts.
2. Does it separate a soft decline from a hard one? Retrying a bank's refusal achieves nothing. Retrying an expired card is where most of the recovery comes from.
3. Can a bank transfer be matched to a member without anyone retyping it? This is the question that decides whether the spreadsheet stays.
4. Who is told when a renewal doesn't happen, and how long after? A date passing in silence is cheap to fix and easy to miss for a year.
5. Can you correct a member's renewal type yourself? Being wrong about your own members while you wait on a vendor gets expensive during a membership drive.

One more for after the decision: ask what the data looks like on the way out. The association above that changed platforms went dark while it did, and its members didn't stop renewing to fit the schedule.