# Data-Driven Lifecycle Operating Model

A reusable design for scaling a lifecycle program by scaling the operations behind it. Data and models compile what works. Humans introduce new ideas and content. The team is staffed around that split.

Use this as a repo artifact: copy it, fill the bracketed fields, and treat it as the contract for the compiler — not as a journey map.

Companion article: https://danieljrobles.com/projects/martech/articles/let-data-run-the-lifecycle/

Related operating-model design: https://danieljrobles.com/projects/martech/articles/agentic-architecture/

---

## Adapt this

| Field | Value |
| --- | --- |
| Program name | [e.g. Reactivation compiler] |
| Primary outcome | [one scoreboard: onboarding completion, lapse prevention, reactivation, …] |
| Owner (lifecycle / CRM) | [name / team] |
| Owner (compiler / MarTech) | [name / team] |
| Owner (data / identity) | [name / team] |
| Activation channels | [email, SMS, push, in-app, …] |
| System of record for next-best treatment | [warehouse decisioning — not the ESP journey canvas] |
| Exploration budget | [share of eligible traffic reserved for unproven treatments] |

---

## 1. Problem

A conventional lifecycle build starts with a prescribed map: welcome, nurture, win-back, upsell. Someone writes the copy, picks the channel, sets the wait, and draws the branches. That map is treated as the product. When the business adds a category, a brand, or a new retention problem, the team extends the map. More nodes. More QA. More people who know where the wires go.

That is not a lifecycle strategy. It is a factory for hand-authored journeys. It can look sophisticated in a vendor canvas and still be a linear ops model: every new idea needs a builder, every new audience needs a list, every new test needs another tree.

**Design goal:** integrate ranking, allocation, and measurement into the execution layer, with policy gates, and with a human function that injects ideas the historical distribution cannot invent. Architecture first, then staffing and tooling.

If adding a new idea requires rebuilding a journey, you are still in the prescribed model. If adding a new idea means contributing content or a hypothesis into a loop that already compiles treatments, you are scaling operations.

---

## 2. Operating model — three planes

```
                    ┌─────────────────────────────────────┐
                    │     CONTROL PLANE (decisioning)      │
                    │  eligibility · rank · holdouts       │
                    └─────────────────────────────────────┘
                                      │
           ┌──────────────────────────┼──────────────────────────┐
           ▼                          ▼                          ▼
   EXPLORATION                   POLICY                     EXECUTION
   Humans inject                 Encoded gates              Channels send
   hypotheses, copy,             (consent, brand,           a compiled
   offers, constraints           legal, inventory,          treatment
                                 quiet hours)
                                      │
                                      ▼
                           MEASUREMENT LOOP
                     outcomes · keep/kill · catalog refresh
```

Decisioning is the control plane. Humans explore. Policy is not a meeting. Channels execute; they do not own the definition of the audience or the goal.

### Humans (exploration)

Introduce candidates that are not in the historical distribution: a new offer mechanic, a tone shift, a content format nobody has tested, a hunch that a lifecycle moment is underserved. That is the exploration budget, not noise.

Humans do **not** sit in the weekly loop picking the next node on a tree.

### Policy (standing gates)

Consent, brand, legal, inventory, frequency, and quiet hours are encoded as eligibility filters. A treatment that fails a gate never enters ranking. Policy can halt a send. It does not redraw journeys.

### Compiler (execution + ranking)

Rules plus models pick among eligible treatments for the declared outcome. Holdouts are first-class. Winners stay in rotation. Losers leave without a political postmortem in a campaign standup.

---

## 3. Decisioning as the control plane

The interesting problem is whether a new priority can enter the system without a custom project. Eligibility, ranking, suppression, and measurement already have to exist.

| Capability | How it is used | What it enforces |
| --- | --- | --- |
| Identity and state | Who the person is, what they are eligible for, what they already received, what they just did | Warehouse truth, not ESP-only lists |
| Treatment catalog | Content, offers, and constraints as inventory rows | New ideas enter as catalog rows, not unique trees |
| Eligibility rules | Consent, brand, legal, inventory, quiet hours, frequency | Policy before ranking |
| Ranker | Rules first; a model when there are enough outcomes | Compilation instead of prescribed sequence |
| Holdouts | Always-on control for the declared outcome | Evidence instead of meetings |
| Exploration allocation | Traffic reserved for unproven catalog rows | The loop does not starve new ideas |
| Activation | Channels execute a decision | ESP/SMS/push do not own the goal |
| Feedback | Sends, conversions, unsubscribes, revenue return to the ranker | Keep/kill is a measurement job |

Hands-on stays on outcomes, hypotheses, contracts, and the scoreboard. Compilation, ranking, and traffic allocation are machine jobs.

---

## 4. Policy-as-code

Standards the compiler is not allowed to weaken:

1. **One outcome per loop** — a ranker optimizes a declared scoreboard. Do not hide five KPIs inside one “lifecycle.”
2. **Warehouse is canonical** for identity, eligibility features, and outcomes used in decisioning.
3. **Catalog is inventory** — copy, offer, constraint, and channel are rows. They are not nodes on a unique journey.
4. **Gates before rank** — consent, brand, legal, inventory, frequency, quiet hours.
5. **Holdouts are not optional** — a treatment without a control is not a learning system.
6. **Exploration is reserved** — a loop that only exploits known winners will ossify around last year’s map.
7. **Channels execute, they do not decide** — audience definition and next-best treatment do not live only inside the ESP.
8. **Keep/kill is measured** — losers leave the catalog without requiring a campaign standup.

### How a new idea gets through

1. Operator states the hypothesis and the outcome it is meant to move.
2. Creative / lifecycle contributes copy, offer, or constraint as a catalog candidate.
3. Policy gates run: consent, brand, legal, inventory, frequency.
4. The candidate enters exploration allocation (or rules-only ranking if volume is still low).
5. Feedback returns to the same loop that ranked it.
6. Measurement keep/kills. Residual risk stays on a scorecard, not as a new tree.

Humans inject candidates. The perimeter and the audit trail are not optional.

---

## 5. Layers in execution

Agents and tools do not sit in a sidecar chatbot. They own the systems that decide, send, and learn.

| Execution layer | Owner | Pattern |
| --- | --- | --- |
| Identity and eligibility features | Data | Shared person ID; no cloned PII in the ESP |
| Treatment catalog | Lifecycle + creative | New ideas are rows; builders do not fork journeys |
| Decisioning / ranker | MarTech / marketing engineering | Rules + model + holdouts; one scoreboard |
| Activation | Channel ops | Execute the compiled treatment |
| Feedback / measurement | Data + MarTech | Outcomes return to the ranker |
| Intake for ideas | Lifecycle | Cheaper than a ticket to rebuild a canvas |

### Job split (do not reverse)

| Job | Owner | If you reverse this |
| --- | --- | --- |
| New hypotheses, copy, offers, constraints | Humans | The program ossifies around last year’s winners |
| Eligibility, ranking, send-time, channel mix | Data and models | Ops grows linearly with every new idea |
| Consent, brand, legal, inventory, quiet hours | Policy, encoded as gates | Speed without a perimeter |
| Keep or kill a treatment | Measurement loop | Meetings replace evidence |

---

## 6. Guardrails

| Guardrail | What it prevents |
| --- | --- |
| One declared outcome per compiler | Ranking fiction against mixed KPIs |
| Catalog-not-canvas | Unique trees for every idea |
| Gates before rank | Policy being “someone remembered to check” |
| Always-on holdout | Shipping volume with no evidence |
| Exploration budget | Exploit-only loops that starve new content |
| Channel is not system of record | ESP journey maps becoming the org chart |
| Intake cheaper than a rebuild | Ideas dying in a ticket queue |
| Ops leverage as a metric | Headcount tracking send volume |

Contracts before more journeys. Velocity with a perimeter.

---

## 7. Ecosystem health

Operational telemetry the review function actually uses:

- Time from idea to live test.
- Count of concurrent tests the same team can run without growing.
- Share of eligible traffic in holdout vs exploitation vs exploration.
- Catalog size: active, exploring, killed.
- Gate failure rates (consent, frequency, inventory).
- Outcome lift vs holdout for the declared scoreboard.
- Ranker input freshness (identity, eligibility, last-touch).

The canonical model is not the vendor canvas. Schema and eligibility live in governed warehouse tables; channels execute.

---

## 8. A change, end to end

**Example:** add a new piece of content for the declared outcome.

1. **Hypothesis** — one sentence, one outcome, done-when.
2. **Catalog** — row with copy/offer, eligibility notes, channel, exploration flag.
3. **Policy** — if it fails a gate, it does not rank.
4. **Allocate** — exploration traffic (or rules ranker) until there is enough evidence.
5. **Activate** — channel sends the compiled treatment. No new journey tree.
6. **Feedback** — events and outcomes return to the same loop.
7. **Keep/kill** — winner stays in rotation; loser leaves the catalog.
8. **Health** — idea-to-live time and test capacity are the ops scoreboard.

Catalog, owner, contract, gate, telemetry.

---

## How to start without pretending you have a research lab

You do not need a research lab on day one. You need to stop encoding every idea as a unique path.

1. Pick **one outcome**. One scoreboard.
2. Inventory the treatments you already send for that outcome. Put them in a catalog with eligibility rules.
3. Stop adding branches. New copy becomes a variant in the catalog, not a new journey.
4. Add a holdout and a simple ranker: rules first, then a model when you have enough outcomes.
5. Give humans an intake path for ideas that is cheaper than a ticket to rebuild a canvas.
6. Measure ops leverage — time from idea to live test, and how many tests the same team can run without growing.

AI belongs here as a way to draft variants and documentation, not as a replacement for the ranking loop.

---

## What this is not

- It is not “turn off human review.” Consent, brand, and high-risk offers still need gates.
- It is not “the model writes the emails.” Humans still introduce the ideas and the content. The model allocates traffic among things people put in the catalog.
- It is not a reason to keep a suite that can only express the prescribed tree. If the tool cannot treat content as inventory and decisions as a compile step, it will drag you back into manual ops.

Prescribe less. Compile more. Let data keep what works. Let people inject what has never been tried. Build the operations so a new idea does not require a new org chart.