Implementation worksheet · 5 min read
A Multi-Channel Journey Collision Test Plan
Force six collisions in staging rather than discovering them in production: two campaigns qualifying the same person in the same hour, a marketing send landing during an active support escalation, a win-back firing for someone who just converted, a billing-failure notice competing with a feature announcement, the same message arriving on two channels, and a journey re-entry while the contact is still mid-journey. For each, assert what the customer actually receives, in what order, and which rule decided it. The output is not a pass mark — it is a written arbitration policy, because every one of these has a defensible answer and the failure is having no answer rather than the wrong one.
Collisions are invisible in single-campaign QA: each flow is correct on its own. They only appear when one person qualifies for several at once, which is exactly the state production is in and staging usually is not.
Put it into practice
1. Build one test contact who qualifies for everything
A staging profile that meets the entry condition of every live journey at once. This one contact is the entire test rig, and it belongs in your seed data permanently.
2. Force each collision deliberately
Trigger the competing events within the same window. Do not wait for a natural collision — the point is to see the arbitration, and natural collisions arrive at inconvenient times with real customers attached.
3. Record what arrives, in order, on each channel
Not just whether a send fired: the sequence is the thing being tested. A correct set of messages in the wrong order is still an apology email.
4. Name the rule that decided each outcome
Priority, frequency cap, suppression, mutual exclusion, or vendor default. 'It just worked' means an undocumented vendor default made a business decision on your behalf.
5. Write the policy down and re-run it per release
The six cases become a checklist that runs whenever journeys change. Orchestration drifts silently as flows are added; the test is what makes drift visible.
Collision cases
Copy this structure into your review document and record your observed result for each row.
| Collision | How to force it | Expected outcome | Rule that decided it |
|---|---|---|---|
| Two campaigns, same hour | qualify for both | one sends, other queues or drops | |
| Marketing during escalation | open ticket + campaign | marketing suppressed | |
| Win-back after conversion | convert then trigger win-back | win-back cancelled | |
| Billing vs announcement | both qualify | billing wins | |
| Same message, two channels | email + push eligible | one channel only | |
| Re-entry mid-journey | re-trigger entry event | no restart, or documented |
A failure worth checking
The apology email: a customer upgrades on Monday and receives 'we miss you — here's 20% off' on Tuesday, because the win-back journey had no exit condition for conversion and nothing arbitrated between the two. It is a two-line fix and a disproportionate trust cost, and it is the single most common orchestration bug in production.
Common questions
Can I test this without a staging environment?
With extreme care in production using an internal-only segment and your own addresses. Better than not testing, worse than staging — and never with real customer contacts in the segment.
Who owns the arbitration policy?
Whoever owns lifecycle outcomes, with product and support consulted on the suppression cases. It is a business policy that a platform enforces, not a platform setting that a marketer discovers.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.