add an active customer search into long running Journey Orchestrator programs

Related products: None

I worked with a customer who has an interesting use case regarding a long running Journey Orchestrator Program (FkA AO). The main ask was how does JO handle churned customers? Are they automatically dropped, or is there a chance that customers who might churn in the middle of (lets say) a year long Program be included as active participants after they churn?





It presented a unique question, and in discussing this with my counterparts, I do not believe there is any behind the scenes check for "Customer Info != Null and Customer Info:  Status = Active " .  Based on my knowledge of the product churned participants could still be included in a long running JO Program unless a mechanism was included in both the Participant query and between each send step in the JO program (this really only concerns an email chain model). 





In this users case, I suggested that he create a calculated field based off of the Customer Info Object called "Active Gainsight Customer"  with filters for Status Name = Active, and Customer Info != Null. The customer had wait steps configured between each send step - I recommended that he add a conditional wait after the wait to reference his "Active Gainsight Customer" calculated field. Theoretically this should perform an "active customer" check and not allow users from newly churned customers to proceed further in the JO Program.





If there is not any back end "Churn Check" for participants in long running JO Programs, it would be great if we could add a workflow to automate this in the scheduling portion of bionic participant queries. I think this would be very useful for Programs that are scheduled 90 days or longer. Basically, we would add a checkbox to the scheduler that would say something like :


"Long Running Program - enable ongoing Customer Status Check".  If this checkbox was selected - that would add an automatic status check before each send step and would drop participants that were newly churned. 





Is this something that would be helpful? Is there a backend process that already does this that I am not aware of? Would something like this be feasible to look into adding into the product?
Yes please!





We had our AO basically double in complexity because of this. (I may or may not be the user in the case above).





Thanks for filing this Dan!
Also - this concerns bionic participant queries. Powerlists do have a backend check baked in to look for Customer Info != Null. 
Hi Dan,





Not necessarily. Even if you bring the data via powerlist and add them as participant to a program. We wont refresh the values of the participants to use the latest value. What you have said is common to both bionic query and powerlist. Thanks for sharing the use case.





Thanks


Abhishek S
Aren't you working on an improvement whereby we will be able to define variables to be revalidated for each send in the mail chain?
Hi Diane,





No. We are not working on that requirement.





We will do a check to see if the user has unsubscribed or if the user has been marked as "Do Not Email"(roadmap) before sending email. It wont be a user defined check of configurations to be evaluated before email send. 





Thanks


Abhishek S