In this video, I'm going to walk you through how I juggle a weekly evergreen newsletter with one-off list-wide broadcast style promos. So basically, the problem to solve here is that if we're running a launch of some kind or a promo of some kind, and we want to make sure that people are not receiving newsletters at the same time as those promo emails, we need a way of blocking those. But then simultaneously, if somebody is ineligible for that promo or they purchase the thing, or they opt out of it and want to go back to the regular newsletter, we need a way for them to still get their newsletters while the promo's happening for everybody else, so that it's not like they just have a couple of dead weeks when everybody else is getting the promo. So, that's the problem that this thing I'm about to show you solves.

So right now, I like to do my promos as broadcasts. In the past, I've experimented with them all being automated, like from flow emails, but I kind of prefer the ergonomics of broadcasts. So that's what I'm going to be showing you. I do have some automated pitch sequences, usually attached to the back of a welcome sequence from a lead magnet, but that's not what this is.

This is literally just stop the newsletter for a couple of weeks, eligible people get broadcast, restart it. And this is just for them. Stop the newsletter just for them. So current customers of the product don't have the newsletter stopped.

They often effectively do, because I'm often not writing newsletters while I'm doing the promo because I'm writing the promo, but they would, if eligible, get newsletters if newsletters existed. [chuckles] So I'm not going to go too deep in how the newsletter works in this video, because that's for a different video. But the main thing for you to understand about how that evergreen newsletter works is that we have this cron trigger. So this is just a schedule. So every week on Thursday at 3:00 PM my time, I think.

No, 3:00 PM UTC. Yeah, which is 10:00 AM Eastern Time. We initiate that newsletter for everybody who is eligible. Originally, I had this whole chain here where we'd check all four of these things one by one, but each of these adds a five-minute delay and more events to process, and I was trying to reduce the events I was firing.

So there's just this compound split that's checking all of them at once. Importantly, there's this custom field called lock status, and that's the backbone of what I'm about to show you. So basically, whenever I am sending somebody a sequence that I don't want to have the toes of stepped on by other automated sequences, I use this lock status field to manage that. And so basically, for a welcome sequence or a, probably not a welcome sequence, but a pitch attached to a welcome sequence, I will set the lock status to some slug for the thing.

So you'll see it in a minute how we do it here. Let me find that exactly. So that's in this flow here. I'll show you how we call it in a moment, but what I wanted to call your attention to is that in this flow, which is the one-off promo global start and stop flow.

So this would work for broadcast style promos and the automated style promos. What this one does is it first checks if the person's already locked. So they're already receiving some other promo, and we don't want to stack this promo on top. If that's the case, we'll just do nothing.

We're not going to send them two promos at a time. But if they are eligible, we will abort any shadow newsletter delays right now. And then importantly, I set their lock status to just a generic one-off promo label. And so now back in the newsletter, if they hit that weekly cron, they will not pass through this split because their lock status is not null.

Their lock status is one-off promo. So that's how I manage this. And then if somebody's receiving a welcome sequence attached promo for a specific product, the lock status would get set to that. So, we have one called W freelancing rate that happens, and so that one would be lock status DYFR, I'm pretty sure.

So where the concept of one-off promos are a little weird in DYF is that because we have the broadcast style ones and the non-broadcast style ones, I also have this kind of generic shared broadcast style promo, starter and stopper. And most of what it does is orchestrates things into the main global starter and stopper. And it is called from a specific individual promo itself. So basically, every time I go in and do a new promo, like here we go.

So see all these one-off broadcast style promos? What I'll do is I'll dupe out the one-off broadcast style promo template that I've made for myself. And this template basically just has a bunch of little to-dos that I've marked of all the different things that I need to customize and values I need to set. [clears throat] And then we call the helper flows with the promo slug, the date, et cetera. And this flow is pretty simple usually.

So I have one up from the last promo, right? Yeah. So this was from a promo a couple of months ago. I didn't end up using any of these.

You don't need to worry about this. It's regarding the newsletter. But importantly, all this is very simple. So it's basically just saying this promo ended on May 7th, and then call the one-off broadcast style promo event with this promo slug that's specific to just this promo and the date for the last pitch log.

I like to use this last pitch log field to keep track of when I've promoted something to somebody so that I can make sure not to do it too frequently. So one of the things that we'll do when adding somebody to a promo is check Have they received something within two weeks or three weeks or a month or whatever? So you can say, is the date for last pitch log greater than one month ago? You can do that in Bento.

So that's why I like to use that field. And so that one there, trigger one-off broadcast style promo, will call this, trigger one-off broadcast style promo. And this is the main initiation chain. And we basically do a bunch of logging and calling of other little functions.

So this one sets the current one-off promo to whatever the one is. So 200KF May 2026. Now I can find people who are in the promo by filtering from this one field, and then log a pitch, log some date stuff, and then this here calls [clears throat] the main one-off promo thing that's not broadcast specific. So start one-off broadcast promo, lock broadcast style, and that is in here.

Yeah. So this is the main flow I was showing you earlier that is just adjusted a bit for the broadcast style one. I feel like this one might be a little bit too complicated and specific to DYF to be super relevant for you and give you ideas and it's been a little while since I've messed with it, and I didn't document it very well. So I'm like, what the heck is this field even for?

So I guess the main inspo that you could take from this is just kind of seeing how I'm calling different flows almost as functions that serve one specific role, and that most of the logic we see here isn't about the sending of the emails, really. It's more about making sure people are only getting the kind of thing I want them to get. I feel like that's the main gem to take away is that any time you're creating some kind of automated sequence, you have to be mindful of other automated sequences or non-automated sequences that people might be getting at the same time, and that's what most of this stuff is managing. And so this whole broadcast style promo end thing and the global end in the main one, [clears throat] what these are doing is it's saying, if somebody opts out of this one promo in general, or they opt out of the whole list, or the promo's window has ended, et cetera, or they bought the thing or it was scheduled, then we want to fire this main [lips smack] ending flow, which is this one.

And then we also need to kill any preexisting flows that are happening. So it's like this idea of cleanup, so I would say zooming out, looking at what you're playing with and asking, what are the flows that someone might still be just sitting in, and how do we kill those delays, kill those existing flows, et cetera, from one main orchestrator? And that's what this is. And then how do we know what somebody's receiving over here so that we don't send them more stuff over here?

Part of why these are hard to show as well is that a big part for me of doing one of these new promos is that I have a pretty complicated set of SOPs that I follow to configure all of the stuff for a new promo. So I figured I'd take a moment to show you the segments. Basically, the flows that I showed you are how I'm managing where people travel, but then the actual core thing of like, okay, well, Zach, how do you email these people? I have different segments that I use for every email.

So I have within this specific 200KF product, there's a wait list that people can sign up for. And so I have different segments for people who are on the wait list, people who are not on the wait list, and then for everybody who's eligible. Not many people are eligible right now because they've all been removed because the promo's not active anymore. But nonetheless, the segmentation rules are perhaps interesting.

So importantly, the current one-off promo, remember how that one flow sets it to the slug for the specific promo? That's one of the rules. So if somebody is marked as inside of this promo, they are eligible unless they've already opted out of the newsletter, which is pretty much a global opt-out in terms of content. They're also not eligible if they've already bought the product.

They also have to have a subscribed status in order to be eligible. This one's not actually important for the broadcast. Bento won't send a broadcast to somebody who's unsubscribed, but it's still useful for seeing your audience, because if you didn't do this, by default, unsubscribed people would be shown in your count, so it can make your metrics a little bit more tricky to calculate. And then additionally, we want to make sure that they didn't opt out of the current promo, which is a little flag that I let people do.

They say, "I don't want to hear about this specific one." So that's one set of rules. The other set of rules is for the wait list people. So it's a similar situation, except in this case, I use the 200KF interest tag to mark somebody as on the wait list. And so in that case, in my mind, if somebody is signed up for the wait list, they're always eligible for a promo because that's what they joined the wait list for.

And so that's that set of rules. And then the other two segments are basically just their own versions. So like this contains definitions of both, and then this is just either/or, pretty much. There's a little bit of a nuance, but that's pretty much how that works.

And so then on a given promo email day, I just go create a broadcast, choose which segment is relevant, and send it, and it's as simple as that, if you could count any of this as simple.