In this video, I'm going to walk you through how I created this automated email course in Bento that has the ability for students to essentially fast-forward to the next lesson when they complete a worksheet. So this is the framing, and it's a nine-day course. One thing I want to disclaim before we go into it is that this flow I'm about to walk you through is, I believe, the first complicated flow I built in Bento years ago, and there are probably things I would do differently if I were to do it today. And in general, probably I wouldn't do it today. [chuckles] The thing about this that makes it the hardest is the concept of lesson skipping.

So, for example, I just released a new lead magnet with a welcome sequence that has nine emails or something. I didn't mess with any of this skipping ability, because that's where all the complexity comes from, and I'm not necessarily convinced that the ability to fast-forward pays off the technical debt it creates. Compared to if, for example, instead of doing this thing I'm about to show you, where one email-- So imagine you've got the nine emails, or you don't have to imagine it. Let's just find them.

So here are the nine emails. Let's see if I remember correctly. Wow. Yeah, I do.

It is nine. So you have these nine emails. Imagine if, instead of what we're about to do, where if someone completes lesson two's worksheet, now they get lesson three immediately. What if, instead of that, I just made a little miniature course experience with LearnDash, just like my main course, where somebody could mark lesson one complete in LearnDash to go to lesson two immediately.

And then it doesn't really matter if they get the lesson two email tomorrow, even if they binged all nine lessons today, because it maybe reinforces topics or whatever. If I were to do that, we wouldn't need really much complexity at all. It'd just be a regular welcome sequence. But nonetheless, this course ain't about no basic stuff.

It's about advanced, crazy wild stuff. So I'll just give you a little bit of an overview about how I accomplished this in case you ever want this sort of behavioral fast-forwarding for yourself. The main basis of how it works in order to do a fast-forward is that you need interruptible delays. So you've been through the intermediate section of this course.

I would give you a little pop quiz. Pause the video and answer the question in your own heart. If I told you to create a flow with an interruptible delay, how exactly do you think you would be interrupting a delay? Pause and think about it.

Hopefully, you paused and thought about it. The answer is you would kill that flow from another flow. So we talked about this in a different lesson. That is this one here.

So under Splits and Logic, you can click End Flow, and this allows flow A to kill flow B for a given user. And so that's essentially the basis of how this fast-forwarding would work, is that you would send an email, you'd wait a day, and then you have an event that'll trigger the next lesson, which we'll talk about in a minute. And if the immediate fast-forward action happens, that needs to kill the instance of them sitting in this flow waiting one day and do the next lesson calculation immediately, and then add them to the next lesson here immediately. So let's look at how it all works and see how much I remember.

So this automation spans essentially all of these flows, because this email course, this nine-day email course, bridges into an evergreen promotion that uses Deadline Funnel to offer a 30% discount bound to a one-week window or whatever it is for people who complete the welcome sequence. So basically, you take the free course about some pricing stuff and some value positioning, and then the paid course is just a deeper version of the free course on sale for a week. That's how this all works. And [clears throat] again, this was built a long time ago.

Bento's features have evolved, and I could probably build it in fewer separated flows right now. Most of why it has so many is because of the whole concept of non-concurrency. Needing to make sure a user can't get put into one flow multiple times was mostly achieved through put the user here, kill all instances of this other flow, wait five minutes, now put them in this other flow, that kind of thing, just to make sure they can never exist in there two times. So let's look at the first one.

Basically, the initialization happens in a standard way whenever they hit an event called Start Charge What You're Worth. Simple. And then I believe these two little events here were set up for me to avoid people who sign up for it twice. Actually, not quite.

So I'm looking through the code. I think the reason that I set this up, again, it's been a couple years, but what this is saying is if the user is not already locked, so remember I used lock status to say, like are they inside of something that's supposed to be exclusive, which for this Charge What You're Worth email course is true. We do lock them to this course. So if the user is not already locked to this, so either they're unlocked or they're locked to something else, technically, then we want to call an event that's the hidden subscribe event.

So it's like the internal event that only I would ever call from another Bento automation. Otherwise, if they are already locked to Charge What You're Worth, in other words, they're resubscribing to it even though they're already inside of it Then we'll just call this made-up event that I don't think ever actually gets called. And then we call that event, clear out the temporary field, and that's all that happens here. And presumably, this is that event.

Yeah. So [clears throat] this here is calling this if they're eligible. Oh, and look at that. I made that comment to myself.

Cool. I should have just read that. And then we just do some kind of initialization stuff, like if they've opted in for this, then we should remove the opt-out tag. So, in other words, if someone opted in five years ago, they opted out of it because they hated it, they opted back in today, we need to remove that tag.

Otherwise, in the next automation, when we check for that tag being present, they would end up not receiving it. And then similarly, if they're in the shadow newsletter, we should remove them. And then this here is what I mentioned earlier, just a bunch of killing of subsequent flows. So this is essentially just a bunch of mise en place kind of stuff.

Make sure we've cleared the palette, and they're ready to actually properly start. And then we call this main hidden init event as opposed to what this one was, was hidden init two or something like that. Hold on. Yeah, there we go.

This was subscribed to, and we're calling hidden init down at the bottom. So that one kicks off the next flow, and this is the flow that is basically in charge of keeping track of their lesson count and stuff, and this does a full reset there. And so this is where the current build, and I think probably even if I were to rebuild it today, we would always need some way of keeping track of what lesson they're in. So it just feels kind of cluttered to me a little bit, that we have to store these fields on their profile because there's really not another way.

But nonetheless, when someone's starting it for the first time, we need to set the current lesson to zero. We need to clear out their worksheets completed field. Again, just a bunch more clearing. Lock them, make sure they're actually subscribed, and then we can finally start the new lesson chain, which I don't know if that's in here or the next one.

Looks like it is in here. Cool. So when someone starts a new lesson, we essentially are [clears throat] checking their current lesson field number, which remember when they first start it, we set to zero. We multiply that by one, which I think probably the reason I did this is to account for the zero.

So in this case, the current lesson is going to be zero because zero times one is zero. And then the lesson-- Oh, let's-- Gosh, I got to check the math. Okay. The math is simpler than I thought, and this is an example of something actually that I don't think we would need to do today.

So back in the day with Bento, you couldn't pass Liquid into event parameters or event details rather, but you can now. So in this case, instead of calling this event, start new lesson, with an event details of the lesson number to start, I had to set it on a field on their profile. And so that's what all of this was looking at, is essentially checking this one. Checking if the new lesson that we're trying to start is in fact a bigger number than the current one that they're on to avoid instances where, so again, since we're going to allow people to fast-forward when they submit a worksheet, imagine if they submit that worksheet twice.

The same worksheet twice. You wouldn't want it to send them the next two emails. You would want it to send the next email once and then do nothing for that second resubmission. So all this is doing is, again, setting another temporary event to call where it says their current lesson is number one for the comparison.

The next lesson we're trying to start is number two for the comparison, and then we're saying if number one is greater than or equal to number two, don't do anything at all. Otherwise, we can continue. So this is just a fancy way of making sure that we don't do anything if someone's trying to re-trigger stuff. And the reason that I did the times one [clears throat], you can do it with plus zero as well, although I don't know if plus zero would work.

Usually, you would do it with some-- Well, I don't know. But in any case, the reason I did times one is basically to force Liquid to evaluate these as actual numbers rather than a string. And that's a common thing with Liquid if you're doing a comparison like this, like a greater than or a less than. If you're not careful, it might load up some custom field as a string instead of a number.

And then if you do the greater than or equals, if it's comparing strings, it'll actually compare the length. So imagine-- Let me think of an example. Here's an example. So imagine you have two field values, and one of those values is one, and then one of those values is 0.0001.

In this case, if you do is one greater than 0.0001? If they're both numbers, so if you did this thing where you multiplied by one, or it might work if you do plus zero or whatever. In this case, yes, one is greater than this. But if they were strings, the way that that would look would be like this.

So if this was a string, its length would be one. But if its value was two, its length would also be one. If its value was three, its length would also be one. If its value was 10, its length would be two.

So that's how that would get parsed as a string, whereas this would be one, two, three, four, five, six, seven, eight, nine. So it would be like checking is two greater than nine? Answer false, even though it should be true. So that's what this is doing.

It's essentially just casting those to integers and then checking if we should indeed send the next lesson or if they just double submitted. And then the rest of these things here are just clearing out the temporary event call. And again, with how we can pass event details in Liquid, or sorry, in Bento now, I would be able to simplify a lot of this if I were rebuilding it today. And then this here is where the actual next lesson logic is primarily getting dispatched.

So when this start new lesson thing is triggered, assuming they are in fact ready to start the next one, they're not double submitting the same one, that's this left-hand pathway. And what it will do is first off set the current lesson to whatever we passed in. Which again, that could've been an event detail if I were building it fresh. And then we kill any waits that are currently happening in this one.

So we kill instances of the main lesson sender flow, and then we just clear out some of our temporary fields, and then call the event type for the lesson number. So if I were to change this today, I would probably have this event be generic with one detail for the number or something like that. I think we could simplify this a little bit. But in any case, right now the way it works is that it will call hidden CWIW lesson one start or lesson two start, lesson three start, et cetera.

And then that's what this next flow is listening for, just an event with that number in the title. And I think the reason I built it this way is that back in the day you could inject Liquid into the event type, you just couldn't inject it into the details. So this was my way of working around that, I think. And then [clears throat] when this flow gets triggered, this is where I think it becomes a bit simpler and more intuitive, which is that the event gets triggered, the email gets sent, it hits the delay.

All this is pretty simple stuff. And then this is less simple, which is that now what it does is it sets the temporary next lesson to be whatever the current lesson is plus one. So if we just sent lesson two, we wait a day and then we say, "Cool. Next up we need to send lesson three." That's what happens here.

And then we trigger the start new lesson event, which is back to where we were. And that start new lesson event is going to be checking for this new lesson number. So back to here, as you may recall, we covered this before. So it comes over here, this one gets triggered and fires it into this chain, and then this here is saying their current lesson equals the temporary new lesson number, which over here we set to the next one.

So remember, we hit this flow, we sent them number two, and now we set this temporary one to number three. Now this flow gets hit and it says number three, which we flagged as the next lesson, is actually now the current lesson because they already waited the 24 hours, so they're now eligible for the new one. That's why we can set it. So it goes in here, it sets it as the current.

It kills all instances of this flow, which when somebody waits the 24 hours, there wouldn't be any, and that's okay. And then it adds them back to that flow, except for the next number is the trigger now, because we already set the current lesson to this new lesson number. So current lesson would now be three, and then when it fires this one, it would be hidden lesson three start. And then they go in here and it triggers lesson three start, and then they hit the delay.

And then if they go off and they separately complete the worksheet, which is a Gravity Form on my end, that'll trigger, I don't remember which event, but basically it triggers an event the same way that completing a delay would. So we set the delay, or sorry, we set the number the same way. Let me see if I can find it. Okay, it's this one.

So worksheet submitted calls this worksheet complete event, I think via Zapier right now. And we have to pass in the lesson number from Zapier into Bento in order for this to execute correctly, and then that's just calling the same set of flow steps. I have some other flows here that shouldn't be very relevant for you, but I'll just quickly go over them in case you saw them in the list and you want to know what they do. So this flow here handles worksheet processing, where I essentially put this in place, again, back in the day before you could pass Liquid in event details, so you shouldn't need to do this.

But it would essentially just [clears throat] use me calling this event to create some other events and mark details on their profile. So I was essentially keeping track of how many worksheets from within the course they filled out to do nothing. I didn't do anything with this data. But theoretically, I could have done some special targeting based on somebody's course score as a proxy for engagement.

The idea being that maybe if somebody's filled out seven of the worksheets, it means they're quite engaged and they'd be ready for that evergreen promo immediately. Whereas if someone filled out none, maybe we shouldn't do the promo at all. Maybe we should put them in general newsletter for a couple months before promoting anything. That would be the theory, but I didn't do any of that.

And then the opt-out, basically scrolling through this, most of what the opting out is, is if somebody went in and they clicked a link in the URL which contained the action. If you don't remember from the previous video, I do it with this page, I think. Yeah, you can actually see it in the history there. So see how it says, "Preferences noted?

Action equals newsletter preference video." So I essentially use the Bento link click with that action as the way of me keeping track of specific things the user clicked to do. So in this case, we would have an email that was like wfreelancing.com/preferencesnoted?action=cwywoptout. So if someone clicks that link, that is them opting out just of the Charge What You're Worth email course, but not necessarily everything I ever sent. So they would just go on to the newsletter.

So in that case, we just have to clear everything out. Unlock them, kill all the Charge What You're Worth flows, add the tag that they opted out, put them on the shadow newsletter. That's what all this does. If someone globally unsubscribes, we do things a little bit differently because we're obviously not going to add them to the shadow newsletter.

We just remove them from the flows, because an important note is that when you send emails from within flows, I don't believe, but I could be wrong actually as I'm saying it. I don't know if they natively respect the subscription status. I think they probably do, though, because I believe there's this transactional checkbox. So I can't remember what Jesse said.

Maybe he'll leave a comment on this video. But I believe Jesse said the way flows work is if somebody's unsubscribed, they'll still go through your flow, and any of the email nodes will just get skipped. But in something complicated like this, it could still mean that this unsubscribed person is having their custom fields changed in the flow. I don't know if them being unsubscribed changes that.

So, that's why for something like this, where you have a flow doing a lot of weird stuff, I personally like to just clean up after myself if someone's unsubscribing. So, final aspect of this is the flowing into that evergreen pitch. So you'll notice that for emails one through eight, all of them have their initiator event. They send the email, they wait a day, they set the next lesson, and then they leave.

That's the flow for all of them. But the final email, lesson nine, doesn't do that. The final email initiates, sends the email, marks a date stamp just saying this is when they completed the course in case Zach ever wants to look at it. I mean, he never has [chuckles] but just in case, we mark that, and then we do a little split where we say, have they already bought the thing I'm about to promote to them?

If yes, they have already bought it, then we won't do anything. If no, they have not already bought it, we will do something. But I think I might have just found a bug because I don't believe this would produce the thing that I, past Zach, would've expected because I'm pretty sure if this happens, they won't be added back to the shadow newsletter and stuff and they won't get unlocked from the Charge What You're Worth course and things like that. Yeah, I've been poking around these other flows that I'm about to walk you through to see if I forgot something because it's been a while, but I don't think I did.

And so this is a good example of why complicated flows like this can be risky, is that you just have to test them very thoroughly and think of all the edge cases. And in this case, I think I legitimately, unless I'm missing something, I missed one edge case, which is this edge case here, which is that if a current customer re-opts in for this free email course, which does happen, they will get essentially marked complete here from... Oh, wait, abort bridge. Okay, no.

Zach did already think of it. Cool. So let me just go find this. But as I say that, I've been digging around for a few more minutes, and I can't find it.

So let's call it a bug, and if nothing else, a learning experience, which is that this event is fired, but I don't know if anything catches it. And at this point, frankly, if something does catch it, I did a pretty dang bad job making that clear to future Zach because I can't find it. So, let's just pretend it was gracefully handled, but pretty sure it's not and pretty sure I am leaking subscribers right here. And so let that be a lesson to you.

And let's just focus on the bridge part. I'll keep it high level because this video's already been pretty heady, and this is more complex than most people would ever need to do. But the idea with these evergreen promos is essentially this idea of a bridge, which is kind of like a pre-launch or a warm-up sequence or whatever you want to call it. But it's basically the setup for the actual pitch.

So it's common in promos like this to have a few emails over the span of a week or so that are these pre-promo emails that are meant to install belief systems necessary for someone to buy the paid thing. It's like a common launch and promo structure, followed by the promo period of a week or two with the deadline bound thing and the offer actually positioned. So this bridge contains a few emails. We send them in here, I think.

And those emails are like, let's see if I can find the content. So these emails They're from back in the day when Brendan was running the business. I need to overhaul this whole thing, honestly. But the first one that goes out is a story of when he was having troubles in his agency winging it, and it says, "Oh, hey, mark your calendar for next Tuesday." And then the next one talks a bit about imposter syndrome, and I think again, probably mentions the Tuesday thing.

Yeah, "Get ready for next week." And we have stuff in here to essentially wait until the next Monday to send it. So again, as I look at this, even as nerdy Zach, I feel this is too complicated. Anything that's complicated enough to present opportunities for hitting edge cases like this, it just feels not worth it at this stage to me. I'm leaning a bit more towards simplicity.

But in any case, the way that this flow works is that when somebody correctly flows down into this, so they complete lesson nine, they are not a customer of the paid product. They get the start bridge event triggered, which puts them into this bridge and pitch starter, stopper, and opt-out. So this is like the orchestrator controller, whereas number 10 is the actual email sending one. So when they get triggered, the first thing we do is we check essentially if they're already marked as being in this bridge or in the pitch.

So I use the bridge pitch status field for that, which you'll see in a minute. Or just double-checking if they have already bought the thing. So in those cases, it'll be abort, otherwise we'll continue. And then I used that for creating an event which will either go down one of these two chains.

Again, this was back in the day, so if I were to do this today, we wouldn't need all this crap, and we could just use one magic split to condense this and this to not even be needed anymore. If somebody was the abort flow, so they already are in the bridge or pitch, or they already bought the product, it's going to just have an empty function name to call. Because that was what we set the temporary field here, we would just clear that out and then do nothing else. Whereas if they went down this path, we would still clear out the field because it was only used to call this continue event, and then now we can continue as normal.

So we'll set that bridge pitch status to in progress. So this is saying, "We are just getting started on doing all of this." We will kill any current instances of that email sending flow, just to clean up in case they're somehow in it. And then we will call the prep function. So you're getting the vibe, a lot of these are just making sure that nobody is going to be concurrently existing in future things, cleaning up over past things, calling the next step.

When that start bridge prep event gets called, that's this one here in the number 10 one. We first do this defensive guard, just make sure they haven't opted out of the pitch, and they haven't already bought the thing. Then we can update the status field to mark where they're at in the bridge. All this stuff here was from that original plan I had of marking the amount of worksheets they submitted to decide whether or not to send them the pitch yet.

I'm going to just skip that because I think that that's way too over the top for this. I'm tired just walking through this. So nonetheless, though, that's what this whole freaking thing on the left was just a chain saying, if their lead score was too low, like they submitted too few worksheets, clear out all these fields, set a certain delay, have it come back and re-pitch them later or mark them eligible later. That's basically what all these things do.

So I'll pause here, I guess. Or you can pause here. I'll just stop moving for a second in case you wanted to read any of these. But otherwise, let's continue on to the main path.

So what this does here is it calls the bridge prep no shadow newsletter delay event, which I think will be this one. No. Oh, sorry. Misspoke.

Being silly. This is the trigger event that would've been called up here. So this event got called if we determined they have enough of a lead score that we don't need to delay them. And then what that does is it goes down here and calls the actually start bridge event, which is the top of the main bridge chain.

So in this chain, we're updating some new status fields just so that we can get some auditability on different subscribers. I also like to log what product someone's been pitched and when. So in this case, we're appending the double your freelancing rate course to their log of things that we've pitched them. I have this event that I can fire for a different flow chain that's just called log a pitch, and you can pass in the pitch type, and what it'll do is it'll just put a timestamp on their profile of today at this date, at this time, they were pitched this thing.

And I think I even have a custom field that's last pitch date or something like that so that I can make sure I don't promote things too frequently to people. So that's what most of this stuff is doing, is just managing statuses and such. One part of this, though, that is relevant and part of the fanciness here is that we [clears throat] set the next message date time. I'm dropping the code snippet for you in the lesson.

Basically, the whole time-bound aspect of this and the integration with Deadline Funnel, which is Probably if there is one lesson from this that I think is useful and reusable, it might be this here. I will certainly do evergreen promos that are date bound in the future, probably. But all of the complexity outside of the baseline, I'll probably try to strip because this is one of the first projects I did when reviving the DYF business from when Brennan, the original founder, built it. And God, [chuckles] you're probably exhausted just watching this.

I don't know how many people got this far, but this is just too complex. But in any case, this little bit of code here is essentially setting a time of day in Eastern Time and finding the date when that will next be present. So we are, because of the cadence of messages, and because it's going to essentially start the promo period on a Monday, there are only certain days a week we can actually send the first bridge message. So given that the first bridge message is going to say, "Keep an eye out for next Tuesday," and given that that first bridge message has a two-day delay after it, and then this one will go out on the Monday.

What it means is that this first bridge message has to be sent out on either a Monday, a Tuesday, or a Wednesday. Because if you sent this on a Thursday, and you waited two delays, then this one would come through on a Saturday, which is not a great time to send an email. And so what this code is essentially doing is saying, "Here are my three dates we're down to send on. Find me the soonest date that is one of these three days and is not today." That's what this code is doing.

And so we [clears throat] set that as this one, this field. We set that as the next message date time field, and then we have a delay that waits until the value of that field. So today is Wednesday. So if I ran this right this moment, it would presumably evaluate to being Monday, August whatever the heck Monday is.

It's July 29th right now, so August 15th, whatever the math is. So it would have them wait until then. Once that date hits, it clears out that field, sends the first one, waits two days, sends the next one, and then it does another delay, which I also added to the lesson text, the code for. It does another delay that is basically the same, except with Monday as the only eligible date.

So what that means is, [clears throat] where are we? Here we go. If you got email one on a Monday, you would get email two on Wednesday, and email three on Monday again. [clears throat] If you got email one on a Tuesday, you'd get email two on a Thursday, email three on Monday. If you got this on a Wednesday, get this on a Friday, get this on a Monday.

So that's how this is working, is it's essentially saying we're putting two little warm-up emails in the span of one week, and then we're always waiting until Monday, and then the Monday email's the last warm-up email that's like, "Keep an eye out tomorrow because there's a sick-ass deal coming for you, bro." And that's the end of the bridge, and then we move into the pitch. So once that happens, we mark the whole Charge What You're Worth course as complete. A lot of this was me replicating what Brennan had back in the day, because prior to me coming in, he had a very complex automation sequence, and I was rebuilding it here in Bento. So he marked it here, but probably I would mark it as complete.

If I were rebuilding it today, I would not mark it as complete after the bridge. I'd probably do it before the bridge, because to me, the bridge is less about the lead magnet content, and it's more about the pitch. But nonetheless, this is how it is. We wait a day, and then we fire off the Deadline Funnel initialization.

So basically, both of these are just firing webhooks into Deadline Funnel per Deadline Funnel's documentation, where we pass in the subscriber's email address as a parameter with that event. And that gives Deadline Funnel what it needs to create a deadline for that specific email address. From there, we can send email one immediately, since it's already been that 24-hour wait. And let's see if I'm doing the images in the cart open.

I doubt it. But yeah. So I'm not doing the Deadline Funnel countdown timer images in the cart open email, because usually you wait to do those for the final 48 hours or so. But observe this.

So notice how this link goes to the Deadline Funnel URL, not wfreelancing.com, but rather to Deadline Funnel, with the user's email passed in. So this is an important thing for you to know is that when you're linking to a Deadline Funnel page from a Bento email, you can't just link to the sales page, or at least you're not meant to. You're meant to have your links actually pass in the person's email, because then Deadline Funnel can map the clicker to the page to know that this person is on their specific deadline. It makes it harder for people to spoof and fake their deadlines, basically.

So that's how all the Deadline Funnely stuff works. I think from here, the actual sending is much simpler. We're just waiting a couple of days. Because we know everybody starts on Tuesday, we don't have to do any weird calculated delays anymore.

We can just be like, "Wait two days, wait three days, whatever." And then this one does have a Deadline Funnel timer, so I can show you how that works. Basically, for all of these, these are just HTML blocks where the image source is actually Deadline Funnel/all that image crap with the user's email injected into it. So, this is just from their documentation. And so this existing and passing in their email is what sets the timer to whatever this specific person's expiration is.

And then once they've finished it... Yeah. So, once they've finished the main flow, we just do some cleanup stuff. As usual, we log when the last pitch was completed, unlock them, clear their Deadline Funnel deadline, clear the status field, put them back in the newsletter, and then send a little question like, "Hey, noticed you didn't buy the thing.

Why not? Why didn't you buy my thing?" And the final thing to show you, I believe, is the unsubscribing behavior. So, if somebody ever clicks the link to opt out just from the pitch, but they want to go back onto the newsletter, that's this route. So, then we add that opt-out flag, unlock them, clear the status, end the flows, add them to the newsletter.

That's that one. And then if somebody buys the thing being promoted, we basically do the same steps. We clear it out, add them to the newsletter, et cetera. And if somebody globally unsubscribes, we just kill some of the flows and clear out that status.

So, parting words for you to tie everything together. If I were to go back and do this again, rebuild it, probably what I would do in terms of what I would keep and what I would cut and stuff, I think that the Deadline Funnel approach to the pitch is fine. The Deadline Funnel part was probably the least complicated part of this, and it's also the most interesting and valuable. So, probably I'd keep the Deadline Funnely approach mostly as is.

It was fine. The whole waiting for a Monday, waiting a couple of days thing, I think also fine, and I would say it's a core tenet of the Deadline Funnel thing. I would keep that. But I think what I would probably minimize or cut entirely and try to super simplify would be all of these status markers, all of the if-thens, I would try to cut as much as possible.

All of the lead scoring, I would cut. Things like trying to rotate pitches if someone's being re-pitched the same things multiple times, that's way too complicated. Cut. Lead scoring for the amount of worksheets they filled out, cut.

Fast-forwarding from worksheets, ugh, gray area, but I still think cut. People do like it. They like being able to binge it. I've had subscribers say that.

But is it so much cooler to get to binge via email than to just click the next button in a lesson on the site? I don't think so. And if I have somebody register for the course site, I can have them give me more of their personal identifying information, like their first name, last name, and stuff like that, and have a higher touch experience. I can have videos where they'll see me, versus it just being emails.

So, I'd say cut. And if I were to do some segmentation based on their interests, let's say going back to the example I gave in a different video of someone's trying to get their first client versus scaling. If I were to have that level of segmentation, the way I would probably keep it simple would be just copy and paste the entire message chain so that person A gets this sequence, person B gets that one. But I wouldn't be touching that kind of thing unless I had huge volume coming through this, where that huge level of effort to write a whole other launch sequence is going to actually pay off, which with DYF in its current state, it wouldn't.

So, all that being said, hope you got some good ideas from here and that it was generally useful. See ya.