One Member, One Record

Executive Summary

Mapping out how member data actually moves through GBX's systems today turned up two things worth fixing before any more feature work gets built on top of them.

First, Mailchimp has quietly become the closest thing GBX has to a member database. It's where lead stage lives, where application answers land, and it's the record staff actually work from day to day. That's a mismatch: Mailchimp only ever knows a person by their email address, and people change email addresses — at exactly the two moments this pipeline can least afford it: between applying and signing up, and between signing up and later updating their details. When that happens today, the record splits in two: an orphaned lead on one side, a disconnected new member on the other.

Second, the private members area is old, its messaging feature no longer works, and it's a genuine chore to develop against locally — while carrying very little day-to-day usage to justify keeping it as-is. That's not a reason to panic. It's an opening: whatever replaces it can be built on a foundation that actually supports the search and member-recommendation features GBX wants next, rather than patched onto BuddyPress.

What follows gives each type of data exactly one true home, fixes the identity-linking problem with a mechanism already tested live against GBX's own Memberful account, and sets up the members area rebuild to happen on solid ground rather than on top of the old one.

01  ·  The Problem

Where the pipeline actually breaks

Today, a person's journey runs through three systems that were never quite designed to hand off to one another: someone becomes a lead (a staff referral through the ChimpLink Chrome extension, or a public application on the GBX-Global site), Mailchimp holds their record and lead stage as staff review and approve them, they're sent a Memberful signup link, and once they subscribe, ChimpLink updates that same Mailchimp contact with their subscription details.

That phrase — "that same Mailchimp contact" — is doing more work than it can reliably do. Mailchimp identifies a contact by email address alone, and two handoffs in that chain quietly assume the email doesn't change along the way: applicant → Memberful signup, and Memberful member → later profile updates. When someone applies with one email and signs up with another — which happens, and has happened — the system has no way to reconcile the two. You end up with exactly what's been observed: an orphaned lead sitting on all the application history, and a brand-new member with none of it.

This isn't hypothetical, either. Staff already hand-edit and bulk-update member data directly in Mailchimp, and a bulk update isn't checked against the same rules Mailchimp otherwise enforces. A recent bulk edit wrote "Pre-Seed" into a funding-stage field whose rules only allow "Pre-seed" — Mailchimp accepted it on the way in without complaint, then rejected ChimpLink's own attempt to update that very contact:

One system silently accepting data the other one strictly rejects, on the very same piece of information, is exactly the failure mode this proposal is meant to close off.

Separately, the members area itself has quietly become a low-priority liability: BuddyPress messaging is currently broken, the theme is painful to run and test locally, and current member traffic doesn't yet justify the cost of maintaining it as-is. Rather than a reason to leave it alone, this is the moment to rebuild it properly — see The Members Area.

Give every person a single internal ID the moment they first make contact with GBX — whether that's a staff-entered referral or a public application — and carry that same ID all the way through, including into Memberful's signup process. Memberful lets us attach that ID to a person's checkout link as a tracking parameter, and, critically, we tested this live against GBX's own Memberful account and confirmed it survives even when someone signs up with a completely different email address than the one they applied with. That one ID becomes the thing every system agrees on — not an email address, which is always free to change.

The same idea needs to run one step earlier, too: today, a lead who applies using a different email than a staff member originally entered for them risks the same kind of broken link. ChimpLink already has working logic that safely updates a Mailchimp contact's email address in place when it changes after signup, without creating a duplicate. This proposal is really about widening that existing mechanism to cover a person's entire history with GBX — from the very first time they're a lead, not just from the day they become a paying member.

03  ·  Day-to-Day

What actually changes for staff

Nothing about the spirit of how leads are reviewed changes. Staff still see new leads, still get notified when someone completes an application, still approve applications and send payment links. What moves is where that review happens: out of a Mailchimp segment that has to be manually refreshed, and into a live Leads view inside ChimpLink itself.

The automated email sequences — welcome emails, payment-link reminders, win-back emails for lapsed members — keep running exactly as they do today. Mailchimp keeps sending them; it's simply being told what to send by the system that actually owns the data, instead of being where those decisions are made and stored.

The lead journey, unchanged in shape

04  ·  The Members Area

Rebuild it, don't patch it

Three things point the same direction: current member traffic on the site is low, the BuddyPress messaging feature has already stopped working, and the theme is genuinely painful to develop and test against locally. Individually, any one of those might be worth living with. Together, they mean there's very little being protected by leaving it as it is.

What's gained by rebuilding rather than patching: a members area with its own proper data store, built from day one to support real search and member-to-member recommendations — the kind of features BuddyPress was never going to deliver well, and that any AI-assisted matching layer needs a solid foundation under it to work from.

06  ·  Open Questions

What's still unresolved

None of the below block starting. They're decisions to make as the work progresses, not reasons to wait.

• OpenWhat happens to an applicant staff decide not to approve? There's no formal "declined" state today — worth designing one deliberately, especially for future recommendation features that shouldn't resurface rejected applicants.
• OpenIf someone returns months after being archived and re-applies under a different email, how do we reconnect them to their original history?
• OpenOnce lead review moves into ChimpLink, what does a fast, confident review actually need in front of you — the application answers side-by-side with prior notes, a scoring or fit indicator, one-click approve/decline actions, a history of past contact? Worth walking through what today's Mailchimp-segment review is missing before we design the replacement.
• OpenStaff already hand-edit and bulk-update member data directly in Mailchimp today — and Mailchimp's bulk tools let through values that break its own validation rules (see the funding-stage example in The Problem). Once that data lives in ChimpLink instead, what would you need to keep doing bulk edits confidently — a proper bulk-edit/import tool that actually validates against the same rules, rather than one that lets bad data in silently?