Engagement programs, as I understand them, do not allow for dynamic casts. To phrase that differently, they are restricted to specific casts (sends) and someone who enters the program has to wait until the next cast to receive content. This, for drip nurturing campaigns can pose somewhat of a problem. I want my users to receive 12 emails, once a month, as long as certain conditions are not met. They can transfer into and out of the 12 email pattern, depending on conditions, transition into a 4 email pattern depending on engagement. Obviously because we want leads to transition in and out of the campaign, but not receive the same content, an engagement program seems ideal.
However, I want to drive engagement that feeds my sales team, so I need to have smooth engagement curve rather than something peaky. Smooth engagement that feeds a sales team drives (or is more likely to drive) consistent generation of opportunities, and thus revenue. Peaky engagement is likely to result in large periods of higher engagement which would outmatch the sales capacity to consume those leads, and some leads would 'go stale' or not receive the same level of engagement that would be possible with a smooth semi-consistent stream.
This leads us to fall back on campaigns, but there is a fatal flaw here: no conditional logic in wait steps. If there were conditional logic in wait steps one could at least create a single (albeit large) smart campaign that distributed the correct email sequence on the correct cadence. Without this, leads that re-enter the 12 email cadence would have to wait 1 month x the number of emails they received. Since this functionality does not exist, one is either forced to build a Traffic Cop system, or daisy-chain campaigns together to achieve the correct result.
Add on top of this that you don't have the equivalent of a while loop - I assume for reason that you are concerned about user logic error resulting in campaign queue backlogs that strangles the system - and our options are limited. Using a while loop and a carefully constructed series of choices in a "send email" flow step, one could achieve the desired dynamic email send required. One could even create a dummy campaign to sit in between the campaign being called to not trip any loop detection (depending on how this is actually tracked on the backend) though at this point we are getting pretty convoluted.
What actually surprises me are the product decisions that lead to this design - lack of any sort of recursive wait option seems like a large gap. There are a number of possible solutions, none of which seem to have been implemented. This seems like fairly basic functionality.
.png)