Program status structure for repeating cycle

[Bianca_Lopez]

Hi, I created an email invitation that gets sent out to people more than once, working in a cycle repeatedly. Basically how it works is:

1. Person becomes qualified (Member)
2. Invitation is sent (Sent)

3. Person converts (Converted)

Repeat to start

Now, my question is, how would you structure the program status when you would like to keep tracking every time they go through the flow? But without losing their previous activity / status changes? So for example, if the person converts in Dec 2017, we'd also like to see that the person became qualified, sent the email and converted in Sept 2018, and again if they do in the future.

Hope that makes sense!

[Grace_Brebner3]

Hey Bianca,

You might like to mark this as a question rather than a discussion

A person cannot go backwards in a program status, so if you want to allow them to go through a single program multiple times and you want to track their progression via program statuses each time they go through, the only way (at least, the only way I know) to do this is by replicating your program statuses as many times as people are likely to go through. i.e.,

Member - 10

Sent - 20

Converted - 30

Sent 2nd - 40

Converted 2nd - 50

Sent 3rd - 60

Converted 3rd - 70

But with this approach, you won't immediately easily see where someone got to on their first run through once they progress to their second and third (as a person can only hold one status in a program at a time). Personally, I don't think cyclical repetitive program statuses are often (if ever) an ideal approach. I find it to be an inefficient and not particularly scalable way to try to achieve the intended clarity, and that it tends to result in reporting that is actually more confusing instead of more clear.

I would be more likely to either:

1. create separate, independent programs for each cycle through;
2. create a linked, nested program structure for each cycle through (noting that only email programs can be nested in default programs, but defaults can be nested in events & nurtures - so this would be dependent on the exact use case);
3. or leave it as is and accept that it's not granular.

Hope that helps. Interested to see if others have different strategies for this, though!

[Bianca_Lopez]

Thanks for the help, Grace! I did consider replicating the statuses, however I realised that it will still not provide the data I'd like reporting-wise.

I think the best way to achieve granularity in this case is to just create independent programs. That way, it will also provide flexibility in the future if we decide to have separate strategies for each cycle.

[Anonymous]

You could do it as an engagement program. Then progress them through streams depending on your status. You could also report on what their current stream is.