Campaigns and automations are two different systems — and only one of them runs while you sleep

A campaign calendar is visible work. Somebody writes it, somebody approves it, and on Thursday it goes out and the graph moves. An automation is invisible work: it was built once, it fires on a trigger nobody watches, and it either quietly earns money for two years or quietly does nothing for two years and looks identical either way. The two systems are also constantly interfering with each other, because nothing in a default setup stops a promotional campaign landing in the middle of somebody's abandoned-cart sequence at a different price.

Most stores can name every campaign they sent last month and cannot name a single automation that is currently running.

1. 01

   A campaign is an event; an automation is an asset

   They are budgeted, staffed and reviewed as one line item called email, which means the calendar wins every week because it has a deadline attached. The architecture separates them so the automations have an owner, a review date and a reporting row of their own.

2. 02

   Every automation needs an exclusion rule or it will fight the calendar

   Someone sitting in a cart-recovery sequence should not receive a sitewide promotion for the same product at a lower price four hours later. Entry conditions are easy to write and exclusion sets are the part people skip, which is why the two systems appear to work individually and contradict each other in a real inbox.

3. 03

   Back-in-stock only exists if the product page captures it

   The flow is downstream of a form that has to sit on a sold-out variant, survive a theme update and write to the right list. Built in the wrong order, the flow exists for weeks with nothing feeding it and reports zero, which reads as the flow not working.

4. 04

   Reporting that sums email revenue hides which half is working

   One number for the channel makes it impossible to tell a well-run calendar from a well-built automation set. Every flow gets its own row, with sends, click rate, conversion rate and revenue per recipient, and the calendar is reported separately from all of them.

Cart abandonment has averaged **70.22% across 50 studies (2006–2025)** and hasn't moved through two decades of checkout redesigns (Baymard Institute) — it's a behaviour, not a defect, so the money is in the *post-abandonment* automations, not another checkout tweak.

Each flow is a named object with a trigger, an entry condition, an exclusion set, a suppression window and its own reporting row: welcome, browse abandonment, cart abandonment, checkout abandonment, back-in-stock, post-purchase, replenishment and winback. Capture points are built first and treated as product-page components — a back-in-stock control on every sold-out variant, an email capture that survives a theme change. The campaign calendar reads flow membership before it sends, so an active recovery sequence suppresses the promotion rather than colliding with it. Nothing goes live without a row in the reporting sheet naming its owner and its next review date.

1. 1

   Week 1

   Capture points

   Back-in-stock control on sold-out variants, email capture rebuilt as a theme-safe component

   Owner: OmniFlow

2. 2

   Weeks 1–2

   Flow definitions

   Eight flows named, each with a trigger, entry condition, exclusion set and suppression window

   Owner: OmniFlow

3. 3

   Weeks 2–4

   Build and QA

   Flows built, seeded and tested against a real cart and a real sold-out variant

   Owner: OmniFlow

4. 4

   Week 4

   Calendar rules

   Campaign calendar reads flow membership before sending; collision rules written down

   Owner: OmniFlow + client

5. 5

   Week 5

   Reporting

   One row per flow with owner and review date, campaigns reported separately

   Owner: OmniFlow

This entry makes no performance claim. It documents an architecture and the order it has to be built in. The design test applied throughout was whether somebody who joins the business in a year can open the reporting sheet and say which flows exist, what triggers each one, who owns it and when it was last reviewed. That test is the reason every flow carries its own row rather than contributing to a single channel total.

These are the surfaces this engagement is run and measured from, shown with representative figures built around the benchmarks cited on this page. Every account we run reports into views like these, and you keep ownership of all of them.

We built the flows before the capture points on the first pass, so back-in-stock existed as a fully tested sequence for three weeks with no form feeding it and reported nothing. It looked like a broken flow and it was a missing input. Capture points now go in first, and no flow is marked live until something has actually entered it.

Real client work that shipped. No performance figures are published, because none have been verified and approved for release. See all our work