Move from campaigns to one-to-one decision waterfalls.

Who this is for

Teams copying rules between campaigns. A suppression or timing rule is easy to miss when it lives in several branches. A shared waterfall gives operators one path to review before execution.

Lifecycle leaders coordinating channels. A customer can be eligible for more than one campaign at once. Review the current context and contact pressure before choosing the next action rather than optimize each message in isolation.

Operators introducing AI-assisted decisions. Human teams still define the goals, constraints and review points. A planner needs usable data and explainable reasons, not just a recommendation that nobody can inspect.

A decision in context

A customer completes a relevant action while a campaign is waiting to send. The event changes the current context, but only if identity, timing and status are connected. A reviewed waterfall can choose a different campaign, wait or suppress. The example illustrates the decision structure; it does not claim a measured conversion improvement.

How it works

The decision waterfall applies the existing profile, consent, status, frequency, selection and execution sequence. The relevant sources and rules are reviewed for this application before a pilot.

1. Profile validation. Resolve the profile and relevant relationships. A decision needs a consistent identity before interpreting the event history or choosing an audience.

2. Consent. Check whether consent is available for the proposed purpose and channel. A promising business opportunity does not remove a permission requirement.

3. Status. Review live status, suppressions and risk. Record the reason when a bounce, opt-out, consent gap or sunset policy prevents a marketing action.

4. Frequency. Evaluate frequency, timing and recent contact. Eligibility for a campaign does not mean that another message is appropriate at this moment.

5. Selection. Read recent events and apply the reviewed planner. Select an eligible campaign and channel using the defined constraints and human-approved business logic.

6. Send or suppress. Return send, wait, suppress or escalate through the Decision API and current execution tools. Preserve inputs and reasons so the result can be reviewed later.

Test the flow before expanding

Choose one decision path and define its baseline before replacing broad campaign logic. Test both successful selections and expected suppressions. Check that a changed event or permission changes the decision for the right reason. Business measures come after operational validation: a clean API response does not prove a better customer experience.

Keep one owner for the pilot decision and the evidence it needs. An allowed action, a provider acceptance and a business outcome are separate observations. If an input is missing or a rule fails, record that limitation and choose the next bounded test. Do not fill a reporting gap with an assumed uplift or keep expanding a workflow simply because the integration has been written.

The published platform modules provide the profile graph, live marketing status, event-centric timeline, planners and Decision API behind this approach. Their value in a particular account depends on the reviewed mapping and operating rules. Define the first application clearly enough that your team can inspect both the selected actions and the people deliberately excluded.

FAQ

Does this replace human strategy?

Humans define the goals, guardrails and review points. Planners support repeatable decisions within those constraints and should return reasons operators can inspect.

Must we replace the execution tools?

The Decision API returns the selected action to the existing stack. Review the integration contract and downstream behavior for the first application.

Can the correct answer be not to send?

Waiting, suppression and escalation are explicit outputs of the published waterfall. A decision system should preserve those outcomes rather than treat every profile as a message opportunity.

What if our events or consent are incomplete?

Record the gap and restrict the decisions that depend on it. A planner cannot create a trustworthy event history or permission record from missing inputs.

Read before you start

• The revival playbook: See a bounded decision path from eligibility through measurement.
• Email sunset policy: Turn inactivity into a reviewed state and disposition.
• Sender requirements: Keep provider constraints in the operating rules.