Monday morning. You export last week’s new members from the membership database, tidy the columns and import them into HubSpot, so the welcome emails can go out.
Tuesday it’s the Eventbrite list. Who turned up, and which of them are actually members, matched by hand because the email addresses don’t quite agree.
By Thursday you’re building the renewal list in a spreadsheet and checking it against GoCardless to see whose direct debit failed.
None of this is in your job description. The systems don’t talk to each other, so you do the talking for them.
You’ve become the Human API.
I’ve walked into this at membership organisations running a custom-built database, a WordPress site with MemberPress or WooCommerce Memberships bolted on, an old Access database, and more spreadsheets than anyone could name. Every one of them had somebody doing this job, usually without anyone else noticing how much of their week it took.
How someone ends up with the job
It happens by accident. Each tool was bought to fix one problem, at a different time, often by someone who’s since left.
The membership database came first. Then a Mailchimp account for the newsletter. Eventbrite for the conference, because it was quick to set up. Stripe or PayPal for online payments and GoCardless for direct debits, and at some point Xero for the accounts.
Each one does its own job well enough. None of them was set up to share data with the rest, so the gaps get filled by whoever’s nearest. That’s usually the person who knows most about how the organisation runs, which is an odd use of someone you can least afford to lose for a day a week.
The job grows a bit with every tool that gets added.
Meet John, your newest member
John’s a project manager who’s just joined your professional body. He joined for 2 things: somewhere to log his CPD hours, and a few events where he can meet people doing the same job.
He’s made up, though you’ll have hundreds like him. This is his first year when nothing’s connected.
- He joins. He pays on the website. His record sits in the payment system until someone exports it, so his welcome email turns up 3 days late.
- He’s onboarded. The welcome email is generic, because HubSpot has no idea what he joined for.
- He books an event. Eventbrite asks for his name, email and organisation all over again. He uses his personal address this time, so now there are 2 Johns.
- He attends. It never gets recorded against his membership. As far as the CRM knows, he hasn’t engaged once.
- He’s due to renew. He gets the same reminder as someone who’s done nothing all year, sent from Thursday’s spreadsheet.
That’s 5 touchpoints, and at each one he’s dealing with a system that’s never heard of him.
Decide who owns each piece of member data
The fix starts before anyone builds an integration. For each piece of member data, pick one system to hold the master copy. Every other system reads from it.
When 2 systems both think they own the same field, you end up with 2 Johns and 2 renewal dates, and before long the team stops trusting either. That’s where the Human API comes from.
With the systems I see most at membership organisations, it usually falls out like this:
| Member data | Owned by | What HubSpot gets |
|---|
| Contact details and email consent | HubSpot | It’s the source |
| Membership status, tier and renewal date | The membership database: a custom build, MemberPress, WooCommerce Memberships, or a CRM such as Salesforce or Dynamics 365 | Properties, updated whenever they change |
| Payment and direct debit status | GoCardless, Stripe or PayPal | A status property. A failed payment starts a workflow |
| Invoices and what’s been paid | Xero | A paid or unpaid flag, never the ledger |
| Event registration and attendance | Eventbrite or Zoom | Registered and attended, per event |
| Email engagement | HubSpot, once Mailchimp’s retired | It’s the source |
I settle each row by asking where the data’s created first, because that system usually owns it. Then how quickly anyone needs it. A failed payment matters within the hour, while event attendance can sit until the next morning.
And which way it moves. Most rows only need to flow into HubSpot. Contact details are the awkward one, because members change them in more than one place, so they sync both ways with one clear winner when the two disagree.
Sometimes the right answer is that HubSpot should become the membership database and the old one gets switched off. That’s a bigger job, but it takes a whole row out of the table.
Spreadsheets don’t get a row. Some will hang around for a while anyway, and I think that’s fine, as long as nothing depends on them.
The same year, once each piece has an owner
- He joins. His payment creates his HubSpot record within minutes, tier and renewal date already set. The welcome sequence starts the same day.
- He’s onboarded. The emails match what he told you he joined for.
- He books an event. The registration finds his existing record, so there’s still only one John.
- He attends. It’s on his record by the next morning.
- He’s due to renew. His reminder lists the events he went to. If his direct debit fails, someone gets a task to ring him before he lapses.
None of it needed an export, though in my experience someone will keep a spreadsheet going for a few months anyway, just in case.
Where to start
You don’t have to connect everything at once. I usually start with whichever row eats most of the team’s week, which tends to be renewals or events, get everyone to agree who owns it, and automate that one flow before touching the next.
That’s most of the work I do now: mapping who owns what, then building the connections between HubSpot and the systems around it.
If that sounds like your week, book a call and talk me through which systems you’re running.
