# Playbook: Klaviyo Flow Stack

**Deliverable type this produces:** `ecom-flow-set`
**Derives from:** the ecommerce email-platform canon popularized by Klaviyo — not a single named guru but a company-level doctrine built from aggregate data across its merchant base. Klaviyo publishes Revenue Per Recipient (RPR) benchmarks by flow type; the canon is: welcome, browse-abandon, cart-abandon (3-touch), post-purchase, winback as event-triggered automations.
**Engine (the science):** BJ Fogg's B=MAP applied at the moment of a real behavioral event — a triggered flow fires precisely when Motivation and Ability are both near their peak (someone just viewed a product, added to cart, or bought), which is exactly the Fogg "prompt when M and A peak" mechanism. Also Perry Marshall's 80/20 power law (§4.6): automated flows are a small fraction of total sends but typically drive the majority of email revenue.

## When to use it

- There is a real behavioral event to trigger on: product view, cart add, purchase, or a lapse in purchase cadence. Requires actual ecommerce/transactional data — a CRM or store platform emitting these events.
- For 19Keys: ZIION product/Passport purchase funnels, once there is a live storefront/checkout event stream to hook into.
- As the "always-on" backbone underneath episodic campaigns (`daily-email`, `plf-launch-sequence`) — flows run continuously in the background regardless of what's being actively promoted.

## When NOT to use it

- On a pure relationship/newsletter list with no purchase events to trigger on (§4.10 explicit failure case) — there is nothing for the flow to listen to. Use `daily-email` or `newsletter-growth-engine` instead.
- Before Layer 0 is cleared — a triggered flow is still a commercial email under CAN-SPAM/Gmail-Yahoo rules; it needs the same authentication, compliance tags, and exit conditions as any broadcast.
- As a substitute for segmentation strategy — flows are trigger-based, not RFM-based; still run `rfm-segmented-sending` underneath to decide who's even eligible to receive flows (e.g., suppress dead/complained contacts from all flows regardless of trigger).

## The step-by-step build

Build all five canonical flows; each is specified identically:

1. **Name the trigger event precisely.** Not "customer activity" — the literal event name the platform emits (e.g., `product_viewed`, `checkout_started`, `order_placed`, `no_purchase_90d`). A vague trigger is a hard fail (§8.1).
2. **Define the exit/suppression condition.** What stops the flow — e.g., "exit if `order_placed` fires mid-sequence" (cart-abandon shouldn't keep chasing someone who already bought) or "exit if unsubscribed/suppressed." **Missing exit = infinite-loop risk = fail.** This is the single most common way an ecom-flow-set fails review.
3. **Set email count and timing offsets per flow.** Specify below per flow.
4. **Attach a per-flow success metric with a named benchmark reference** (e.g., "cart-abandon RPR target: Klaviyo benchmark range for cart-abandon flows" — cite the reference, don't invent a number).
5. **Compliance tags on every email in every flow** — no flow is exempt.
6. **Build the five flows as follows:**
   - **Welcome flow** — trigger: `subscribed` (no purchase yet). 3-4 emails, first within minutes/hours of signup. Highest-RPR flow per Klaviyo benchmarks — build this first.
   - **Browse-abandon** — trigger: `product_viewed`, no purchase within a window (e.g., 24h). 1-2 emails. Exit: `order_placed` for that product.
   - **Cart-abandon (3-touch)** — trigger: `checkout_started`, no `order_placed` within window. Touch 1 (~1h later, Facilitator: reduce friction, "finish checking out"), touch 2 (~24h, add social proof/reviews), touch 3 (~72h, Signal-type urgency if a real incentive exists — never fake). Exit: `order_placed`.
   - **Post-purchase** — trigger: `order_placed`. 2-4 emails: order confirmation/logistics, usage/onboarding tips, review request, (optional) complementary-product suggestion. Exit: none needed (terminal flow) or re-entry suppression to avoid duplicate confirmation spam on repeat purchases.
   - **Winback** — trigger: no `order_placed` in N days (e.g., 90-180d) for a previously purchasing customer. 2-3 emails. Exit: `order_placed` or move to sunset/suppression if no response (hands off to `nine-word-reactivation` logic).
7. **Instrument at Layer 4** — clicks + RPR + reply rate + complaint rate per flow, benchmarked against Klaviyo flow norms, not opens (MPP caveat).

## Worked mini-example (19Keys / ZIION Passport storefront)

| Flow | Trigger event | Emails/offsets | Exit condition | Success metric (benchmark ref) |
|---|---|---|---|---|
| Welcome | `subscribed` | 3 emails: 0h, 24h, 72h | Suppressed on unsubscribe | RPR — Klaviyo "welcome flow" benchmark tier (highest-RPR class) |
| Browse-abandon | `product_viewed` no purchase 24h | 1 email at 24h | `order_placed` for viewed SKU | CTR — Klaviyo browse-abandon benchmark |
| Cart-abandon | `checkout_started` no `order_placed` | 3 emails: 1h, 24h, 72h | `order_placed` | RPR — Klaviyo cart-abandon benchmark (highest-RPR class alongside welcome) |
| Post-purchase | `order_placed` | 3 emails: 0h (confirm), 5d (onboarding), 14d (review ask) | none (terminal) | Reply/review rate |
| Winback | no `order_placed` 120d | 2 emails: day 0, day 7 | `order_placed`, or hand off to sunset | Reactivation rate — Klaviyo winback benchmark (lower RPR, compounding) |

## How the verify gate applies

Per §8.1 `ecom-flow-set` rubric, checked for:
- **All five canonical flows present** — missing any one flow is a hard fail.
- **Trigger event name specified for each** — vague or missing trigger fails.
- **Exit/suppression condition specified for each** — missing exit fails (infinite-loop risk).
- Email count and timing offsets stated per flow.
- **Per-flow success metric with a benchmark reference** — an invented number or a bare "good open rate" claim fails; must cite Klaviyo (or equivalent) benchmark class and must not present opens as the success metric (§8.2 #1).
- Compliance tags present on every email in every flow.
- Cross-check §2.9 (Rogers/adopter waves) is not directly enforced by this rubric but should inform whether flows are cascaded to whale segments first when overlapping with a launch — note it in the deliverable if relevant.