Lifecycle flow collision map

Use when automations have piled up over years and nobody knows what one person can receive in a week.

lifecycle-flow-collision-map.md

Download .md

You are an email operations analyst. You are auditing how existing automations interact, not writing new ones.

Every live flow, with trigger, entry condition, number of emails and timing: {{FLOW_INVENTORY}}
Broadcast and campaign schedule for a typical month: {{CAMPAIGN_SCHEDULE}}
Frequency cap and quiet hours in force, or "none": {{FREQUENCY_RULES}}
One customer situation to trace, such as a lapsed buyer who returns: {{TRACE_SCENARIO}}

Output four numbered sections.
1. A collision table: Flow A | Flow B | How one person qualifies for both | Worst case emails in seven days | Which message contradicts the other.
2. A day-by-day trace of {{TRACE_SCENARIO}}, showing every send that person receives from {{FLOW_INVENTORY}} and {{CAMPAIGN_SCHEDULE}}.
3. A priority rule set: which flow wins in each collision, what pauses, and what is skipped rather than delayed.
4. Gaps: any state in {{TRACE_SCENARIO}} that no flow in {{FLOW_INVENTORY}} covers at all.

Rules:
- Count sends rather than estimating them. Where the timing needed to count is missing, name the field to pull.
- Treat contradiction as worse than volume. A win-back and a renewal notice on the same day is a bigger problem than five emails.
- If {{FREQUENCY_RULES}} says none, show what a cap would have suppressed in the trace before recommending one.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{FLOW_INVENTORY}}
{{CAMPAIGN_SCHEDULE}}
{{FREQUENCY_RULES}}
{{TRACE_SCENARIO}}

Getting a better result

Export the flow list from the ESP rather than working from memory. The forgotten flows cause the collisions.
Trace a real customer. Collision tables read as theoretical until you watch one person receive nine emails.
Decide what skips and what queues. A cart email that lands three days late is worse than one never sent.

Questions about this prompt

When is a collision map better than auditing flows one at a time?

When automations have accumulated for years and nobody can say what one person receives in a week. Reviewed alone, every flow looks reasonable. The problems live between flows, such as a win-back and a renewal notice arriving on the same morning saying contradictory things.

What do I need to export before running it?

A flow inventory with trigger, entry condition, email count and timing, a typical month of campaigns, your frequency cap and quiet hours or "none", and one customer situation to trace. Export the inventory from the ESP rather than working from memory, because the forgotten flows are the ones colliding.

What do the four sections return?

A collision table, a day-by-day trace of your scenario, a priority rule set saying which flow wins and what is skipped rather than delayed, and the states no flow covers. The trace is what convinces people. Collision tables read as theoretical until you watch one customer receive nine emails.

What do teams get wrong when fixing collisions?

Fixing volume and ignoring contradiction. Five emails in a week is survivable; a cart reminder arriving after the order shipped is not. The decision teams defer is skip against queue, and a cart email that lands three days late is worse than one that never sends.