Most of the membership organisations I work with already pay for HubSpot, and it’s still set up the way it arrived, with leads and a sales pipeline. Renewals get run from a spreadsheet sitting next to it.
I think renewals are where that shows first, because a missed one costs real money.
Membership status: lifecycle stage or a custom property
Membership status needs a home on the contact record, and there are 2 candidates.
The first is lifecycle stage. HubSpot lets you rename and add stages, so it can run Prospect, Applicant, Member, Lapsed and so on. The catch is that lifecycle stage is used across the whole portal and only moves forward by default, so if a sales or marketing team already relies on it, changing it will upset somebody’s reports.
A separate membership status property is the other option: Active, Pending, Lapsed, Cancelled. It leaves lifecycle stage alone and can move in either direction.
Plenty of organisations end up using both, with lifecycle stage tracking the wider relationship and a status property answering the day-to-day question of whether someone’s membership is live right now.
Join date, renewal date and calculated properties
Every membership build I do starts with 2 dates on the contact: join date and renewal date. Tier comes next, along with renewal preference (manual or automatic). I track the date of the last event someone came to as well.
On top of the dates go calculated properties. Days until renewal, and years as a member. I usually add days since the last event as well.
Nearly everything else runs off those numbers.
Active lists and renewal reminder workflows
Once the calculated properties exist, the lists are simple to build. Members whose renewal is due within 60 days, say, or members who haven’t been to an event since the spring.
Each list feeds a workflow, and the workflow sends the emails on whatever timings the client picks. Some clients want a reminder a week for 2 months. The list doesn’t mind, because it’s only reading a number.
I like it because nothing depends on someone remembering to run a report on a Monday morning.
A deal pipeline for renewals
Every renewal gets its own deal in a renewals pipeline. A workflow creates it off the renewal date, so the deal turns up a set number of days before it’s due, already associated with the member and, where it applies, their organisation.
The stages are plain: renewal due, invoice sent, paid, lapsed. If the organisation sells tiers, upgrades get a stage of their own.
A deal per renewal means there’s a record of every year someone renewed, with a value attached, so finance can see what’s due next quarter without having to ask me.
A deal that closes won pushes the renewal date on a year, and the cycle starts again. Lost ones flip the member’s status to Lapsed, which drops them into a win-back list (win-back emails are the part I least enjoy writing).
Membership reports in HubSpot
With the dates and deals in place, the reports are mostly a matter of choosing which ones. The ones membership teams look at are renewal rate by tier, renewals due by month, retention by the year people joined, and whether people who come to events renew more often than people who don’t.
That last one tends to settle arguments about the events budget.
Connecting payments and events
Payments and events can report back to HubSpot automatically, so a failed GoCardless payment moves the deal and an Eventbrite check-in updates the last event date without anyone touching it.
Who owns which piece of that data is in The Human API. The order I connect things in is in Connecting your membership systems to HubSpot.
If your renewals still live in a spreadsheet next to HubSpot, book a call and I’ll talk you through how this would look in your portal.
