Implementation worksheet · 5 min read
A Journey Orchestration Platform Data Readiness Checklist
Before any orchestration platform can work, four data layers must be ready: identity (one resolvable user key across channels and devices), events (the journey-triggering actions, named, versioned and actually firing), consent (channel-level permissions queryable in real time), and latency (events arriving fast enough for the journeys you're designing). Audit all four against your real pipelines before signing — the platform inherits your data exactly as broken as it is.
The commonest orchestration disappointment isn't the platform — it's discovering during onboarding that the events the journeys need don't exist, fire twice, or arrive hours late. The audit belongs before the contract, when leverage and calendars still exist.
Put it into practice
1. Audit identity resolution
Pick 20 real users active on two+ channels; trace whether one key connects them today. Count the orphans — every unresolved identity is a journey that will fork into two half-journeys.
2. Inventory the trigger events
List the events your first three planned journeys need. For each: does it fire today, is the schema documented, who owns it, does staging match production? The gaps become your pre-onboarding engineering backlog — priced and scheduled.
3. Test consent queryability
For one user, answer in under a second: may we email, may we push, when did that change? If the answer lives in three systems, the platform can't enforce what you can't express.
4. Measure event latency honestly
Timestamp event-fire to warehouse-or-stream arrival for a day of traffic. Cart-abandonment journeys need minutes; a nightly batch means your 'real-time' platform runs day-old journeys.
5. Write the readiness verdict
Green per layer or a costed gap list. Vendors will happily onboard you unready — the checklist means unready is a decision with a price tag, not a surprise with one.
Data readiness audit
Copy this structure into your review document and record your observed result for each row.
| Layer | Test | Result | Gap cost |
|---|---|---|---|
| Identity | 20-user cross-channel trace | ||
| Events | first-3-journeys inventory | ||
| Consent | sub-second query per channel | ||
| Latency | fire-to-available p95 | ||
| Ownership | named owner per event |
A failure worth checking
The backfill failure: signing on the assumption that historical events can be backfilled later 'for the models'. Backfills reconstruct what was logged, not what wasn't — the missing product events stay missing, and every model or journey depending on that history starts cold anyway. Fix event capture first; history accrues from then.
Common questions
How long does readiness usually take from a standing start?
Weeks of engineering if events and identity need real work — which is exactly why the audit runs before the contract clock starts, not during a paid onboarding.
Do CDPs make this checklist unnecessary?
A CDP with clean identity and events shortens the audit; it doesn't replace it. Plenty of CDP deployments have their own orphan and latency debt — audit the reality, not the architecture diagram.
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.