The Win First

I pulled up a teammate's Brevo (our email automation platform, the Klaviyo replacement) loom last week and honestly — she nailed the confirmation side.

Webinar A Confirmation. Webinar B Confirmation. Both done.

List-add fires the flow. Email goes out with the right merge fields — first name, seat number, year, join URL previewing correctly. The SMS leg works too ("you're in for July" + join URL, 2 credits). Transactional path is clean. Brevo's live recipient preview even shows her a real contact's actual merge values so she can sanity-check before anything goes out.

Great work on this. Genuinely.

The Countdown Is the Open Problem

Then I watched the countdown flows — Webinar A Countdown, Webinar B Countdown — and another teammate had already flagged the right question on her own loom.

The sequence is built as sequential relative waits: 7d → 4d → 3d → 2d → 1d → 23h → 1h → live → 15 min after.

The question: what happens to someone who signs up the day before the event?

Do they enter at the top of that chain and silently walk every wait — including a "7 days out" reminder that fires 6 days after the event ends? Or does Brevo drop them in at the right point?

That's not a hypothetical. That's a real registration pattern.

The Discovery That Got Me Excited (For a Minute)

So I dug into the Brevo flow editor and found something I wasn't expecting.

Brevo has a "Before the date occurs" wait — anchored to a contact's opt-in date, not a fixed calendar date. So you could build the countdown as opt-in date − 7 days, opt-in date − 3 days, opt-in date − 1 day… with contact filters to scope it to the right list.

That actually solves my teammate's timing question. A late signup — registered tomorrow for an event the day after — would reach the "−1 day" step and fire correctly, skipping the earlier waits that are already in the past.

GENIUS mechanism. I got excited.

Why It Still Doesn't Fix the Real Problem

Then I said it out loud: "we're going to have multiple opt-in dates for multiple webinars."

And there it is.

Opt-in date is a single-value contact field. One field, one value, one contact. The moment that contact registers for a second webinar — Webinar A and Webinar B both happening this month — registration #2 overwrites the opt-in date. The countdown for the first event now fires on the wrong date.

The timing mechanism is genuinely clever. But it still rides a shared global field. That's the collision I've been chasing for weeks, and date-anchoring doesn't touch it.

What We Actually Need

The fix isn't cleverer flow logic. It's isolating the data.

Each event gets its own date field and its own join-link field — not a new flow, new fields. Countdown fires from the per-event date, merge-fields pull the per-event join URL, nothing can overwrite anything else's data. When the event ends, we tear down those fields to stay under Brevo's quotas (200 attributes, 300 lists, 50 workflows — it adds up fast).

Questions are in with Brevo support now: can date-anchored waits handle one-time future dates (not year-recurring anniversaries), and can our registration platform sync write to per-event attribute names dynamically.

Why This Matters

The lesson isn't Brevo-specific.

Any automation built on shared global fields will collide when two instances run concurrently. It doesn't matter how elegant the flow logic is. A mechanism that solves your timing problem can leave your data-model problem completely intact — and you won't notice until two webinars run the same month.

Fix the field model first. The flows will follow.

P.S. July 1 go-live target is still alive. The confirmation side is done. We just need the data architecture confirmed before a colleague's countdown sequences go live.