Staggering CTA creation


We have a CTA that checks to see which instances do not have a primary contact. If we trigger all at once for the first time, we will have about 20 CTAs per CSM. Ideally we would like this to be 5ish. 

 

Is there a way within the CTA to stagger the creation of CTAs? 

 

We are setting to create a new CTA every 90 days and to not create if there is another one open. We have the instance name tokenized in the name and using the name as part of an identifier.

 

Thought was to start, I could set to create a new CTA every 1 day, remove the do not create if open, and remove using the name as an identifier

@andreammelde Is one of your concerns that you’ll flood your CSMs’ Cockpits with CTAs when you initially launch?

If so, one idea, which is admittedly a bit of a hack, is to filter one of your String fields such that you only kick off CTAs for a certain part of the alphabet. You could run A-F, then some days later G-M, etc. Once you gently rolled out the CTAs, you could then remove the alphabetic filtering altogether, assuming that your CSMs have worked through the initial flood. You can then lean on your logic that looks for an existing CTA before creating a new CTA.

I’ve filtered on String fields (for example, String field >= A, or String field <= F) successfully.


@matthew_lind exactly - we don’t want to overwhelm with the initial roll out. 

 

I was thinking of trying to use a similar hack for A/B testing we have done with JO, but it doesn’t stagger well.

 

Ill try that kind of hack and see if it gets to the goal the CS team has requested


@andreammelde Is one of your concerns that you’ll flood your CSMs’ Cockpits with CTAs when you initially launch?

If so, one idea, which is admittedly a bit of a hack, is to filter one of your String fields such that you only kick off CTAs for a certain part of the alphabet. You could run A-F, then some days later G-M, etc. Once you gently rolled out the CTAs, you could then remove the alphabetic filtering altogether, assuming that your CSMs have worked through the initial flood. You can then lean on your logic that looks for an existing CTA before creating a new CTA.

I’ve filtered on String fields (for example, String field >= A, or String field <= F) successfully.

That’s an interesting idea! Thanks for sharing your workaround.


It works in sense to use the string field, but it does not totally solve. For example, if a CSM has majority of their accounts in one group, they still have a chance of getting more CTAs than what we would like to send. I was able to split it up in enough runs to keep the CSMs closer to 8 - 10 triggered.

 

 


@andreammelde Thank you for posting. We understand your problem but unfortunately, we don’t have any immediate solutions in our roadmap for it except the workaround provided by Matthew.