Key takeaway
Email automation is a set of standing rules: a trigger says when, a condition says who, an action says what goes out. The rules are the product, not the emails. Carts are abandoned at an average 70.22%, so on a storefront that one flow reaches more people than every other automation combined. Build signup first, then that one. I've never seen a programme fail for too few branches, only for stop conditions nobody checked.
What automating email marketing actually means
Automating email marketing means writing standing rules that decide who gets which message and when, so a trigger fires the send instead of a person. Every rule you write is a decision you keep paying for long after you've forgotten making it. Most teams buy a builder and end up with four flows nobody can explain, because a rule that fires on data you never collect never fires at all.
I've been building email platforms for over a decade, and the flows that survive are the ones somebody could still read a year later. Almost none of the automation I've seen work came from clever branching. It came from a small number of rules that were obvious enough to keep.
Every automation has the same three parts: a trigger that says when, a condition that says who, and an action that says what goes out. Scheduling isn't the same thing. A scheduled campaign has a date, an automated one has a condition, and that's why a schedule fires once while an automation keeps firing until somebody stops it.
Automation is a multiplier on a decision you already made. If the decision is wrong, you've automated being wrong at volume, and it now happens while you're asleep.
The four triggers worth building on
A trigger is the event that starts a flow, and four of them account for almost everything worth building. They're in rough order of what they return for the effort.
- Signup: the one trigger every list produces from day one, and the only one you have before there's any behavior to fire on.
- An abandoned action: a checkout, a trial, or a half-finished form, which carries the highest intent per send of anything here.
- Inactivity: a rule about absence, which is why it needs a window you've defined rather than a feeling that somebody has gone quiet.
- A date: a renewal, a birthday, an anniversary, or a contract end, cheap to build and the only trigger that fires whether or not anybody did anything.
Abandonment is the largest pool of the four. Online carts are abandoned at an average rate of 70.22%, so on most storefronts one flow addresses more people than every other automation put together. It's also the one most often built wrong, by firing a minute after the tab closes, which reaches people who are still deciding and teaches them the mail is noise.
A trigger is only as good as the event behind it. Most teams can't fire on a purchase, because the purchase never reaches the email system as an event, and choosing a nicer builder doesn't fix that. On our side that event is one you send us: there's no product-feed sync with an ecommerce storefront doing it for you.
Manual, bulk, and automated, and which one you are choosing
Every send falls into one of three modes, and the dimension separating them is who chose the timing.
- A manual send: one person picks the recipient and the moment, which is a reply, an introduction, or a nudge to a single account.
- A bulk send: the calendar picks the moment and you pick the audience, which is a newsletter, a launch, or an announcement.
- An automated send: the recipient picks the moment by doing something, and a rule you wrote earlier decides what happens next.
Most teams need all three, and automating doesn't retire the broadcast. The price change, the outage note, and the thing you decided on Tuesday all still want a bulk send, because no rule written last year knows about them. What automation replaces is the repeated manual send: the same message, to the same kind of person, at the same point in their week.
A list of a few hundred people with no event data is better served by a broadcast you wrote this morning than by a six-step branch. The branch costs a day to build and a day a quarter to keep, and at that size a person can just do it.
Build one flow, then earn the second
The first flow is a test of whether the plumbing works, not of whether you're good at email. Pick the trigger you already have clean data for, which is almost always signup, and write one message for it. Not a series. One.
Then measure it against the thing it replaced. If the welcome note used to go out inside Monday's broadcast, compare the automated version against that broadcast over the same window, on the same kind of person. A flow performing worse than the send it replaced is common and almost nobody catches it, because the flow's own numbers look fine in isolation and there's nothing sitting next to them.
Only once you have that comparison should you branch. A branch doubles the paths you have to test, and every extra message doubles the number of things that can go stale. The failure shape is easy to describe and I've watched it happen in a lot of accounts: six flows built in a fortnight, none reviewed since, all still running.
The second flow is where the maintenance starts, and nobody budgets for it. Two people can build ten flows in a week and can't read ten flows in a week, ever again.
Building an automation tool takes time. We dedicated one year to developing our visual editor before launching it. Users can now "literally draw out all these deep flows" on a screen, a detail I covered on In the Ring with SUMO Heavy. Logic becomes manageable when you map it visually. This clarity helps you construct your first sequence properly. You can then move on to building the next one.
What a standing flow does to your deliverability
A flow keeps sending after you stop looking. That's the point of it, and it's also the problem, because the addresses it reaches get worse over time while the volume stays flat. The welcome sequence set up two years ago is the worst list you own, and it's the one you never review.
Broadcasts get cleaned, because somebody opens the segment before hitting send and sees the size of it. A flow has no such moment. It enrolls whoever meets the rule, including the typo addresses, the role accounts, and the people who signed up for one thing and got caught by a rule written for another. Every complaint those sends earn lands in the same pile as everything else.
The receiving side publishes what it expects. Google asks senders to keep a spam rate below 0.10% in Postmaster Tools and never to reach 0.30% or higher, with SPF or DKIM on the sending domain, and SPF, DKIM, and DMARC together once the volume counts as bulk. That rate is a live measurement rather than a setup-day setting, and an unattended flow moves it in one direction.
The rate is measured across everything leaving your domain, so a bad automated flow is paid for by your transactional mail. Receipts, password resets, and the messages people are actually waiting on are what sits in the spam folder while a marketing flow nobody has opened in a year keeps enrolling. At my last company we auto-flagged any list the moment unsubscribe and complaint rates crossed 0.5%, against an industry average nearer 0.02%. An unreviewed flow is exactly how a list gets there without anyone deciding it should.
The stop conditions that have to interrupt a flow in progress
A stop condition is a state that pulls somebody out of a flow they're already inside. Four of them matter, and each one has to be checked at every step rather than once at the door.
- An unsubscribe: the person asked you to stop, and that request covers the steps already queued, not just the next campaign.
- A complaint: the person pressed the spam button, which is the same request made to the mailbox provider instead of to you.
- A hard bounce: the address doesn't exist, so another attempt is a reputation cost with nothing at all on the other side of it.
- A suppression entry: somebody was excluded on purpose, and a flow is exactly where that decision gets quietly overridden.
Checking at enrollment is the bug. Somebody who unsubscribes at step 2 already has steps 3 through 6 queued, and a flow testing the rule only on entry will send all four. Those four are the most expensive sends in the programme: a person who has already told you to stop is the likeliest name on the list to reach for the spam button rather than the link. The header pair that makes one click enough is defined in RFC 8058, which asks for no confirmation screen in between, and the suppression check belongs immediately before each send rather than at enrolment.
Compliance is the floor, not the target. Yahoo's two days is the published expectation and an operational embarrassment, and the only answer worth building stops the mail at the next step of whatever flow the person is standing in.
A flow you can read, review, and rebuild
A flow built in a visual builder exists as a drawing, in one account, in one vendor's database. Boxes and arrows on a screen are the only complete description of it anywhere.
You can't diff a drawing. You can't review it the way you'd review any other change, copy it to a second brand, or hand it to somebody who wasn't there when it was drawn. Ask what changed in the abandoned-checkout flow last quarter and the honest answer in most accounts is that nobody knows, because the record of the change is the change itself.
A flow described as an instruction is a different object. It's text, so it can be read, versioned, reviewed, and explained back to you in a sentence. It can be created and changed by an agent, which is what MCP-first means for us: every capability is an API endpoint and an MCP tool before it's a screen, so what an agent reaches is the platform itself rather than a summary of it.
That's where the rest of the category struggles. Every existing email platform was designed for humans clicking buttons, and an agent bolted onto a dashboard is still a dashboard. The AI in most automation products picks a send time or a next-best-action inside a flow a human drew, which is optimization of the picture rather than operation of the system.
A builder is genuinely faster for a marketer who wants the branch laid out in front of them, and on a two-flow account the difference never pays for itself. It only bites once you own more flows than you can hold in your head.
Reviewing email sequences requires a visual interface. The goal was a tool where users could "see all these drawn out flows" in one place, a design choice I defended on SaaS District. You need a clear layout to check logic. A visual canvas lets you spot missing steps. It also makes it easier to activate draft designs.
When not to automate, and what to switch off
Automation programs only ever get added to. Three tests find the flows that should come back out.
- A trigger that hasn't fired this quarter: the flow is maintenance you're paying for and mail nobody is receiving.
- An open rate under the broadcast it replaced: the automated version is doing worse than the manual one, on the same people.
- A flow nobody in the room can explain: if the rule can't be said out loud, it can't be defended the day it misfires.
Subtraction is most of the maintenance. Retiring three flows makes the remaining four legible, and that's the only condition under which the next one gets built properly.
Flows nobody can read are flows nobody retires. Nitrosend takes a flow as a sentence: campaigns, flows, contacts, and segments all run from one agent command, so a flow gets described, changed, and explained back to you instead of redrawn. Start free, 8,000 emails and then 500 a month with unlimited contacts and no card, and write one flow you already run down as an instruction.
Sources
- Google, Email sender guidelines: the spam rate to keep below 0.10% and never let reach 0.30%, plus the SPF, DKIM, and DMARC requirements for bulk senders.
- RFC 8058: signalling one-click unsubscribe in the List-Unsubscribe header pair, with no confirmation step in between.
- Baymard Institute, cart abandonment rate: the 70.22% average documented rate, collected across 50 studies.
Common questions
<p>A schedule has a date and an automation has a condition. A scheduled campaign goes out once, to whoever is in the segment at that moment. An automation keeps firing every time somebody meets the rule, which is why it needs reviewing long after you built it and a scheduled send doesn't.</p>
<p>There's no universal number, and the size of the list is the wrong test. The right one is how often the trigger fires: a rule that catches two people a month costs more to maintain than the mail it sends is worth. If you can comfortably send those messages by hand, do that until you can't.</p>
<p>The one whose trigger you already have clean data for, which is almost always signup. A welcome message fires from the day somebody joins, needs no behavioral tracking and no ecommerce events, and gives you a baseline to compare every later flow against.</p>
<p>As many as somebody can still explain. Three tests find the ones to switch off: a trigger that hasn't fired this quarter, an open rate under the broadcast the flow replaced, and a flow nobody in the room can describe out loud. Retiring flows is most of the maintenance work.</p>
<p>Not by being automated. They hurt it by running for years against addresses that stopped engaging, because a flow has no moment where somebody looks at the list before hitting send. Google asks senders to keep the spam rate in Postmaster Tools below 0.10% and never to reach 0.30% or higher, and that rate covers everything leaving your domain, including your transactional mail.</p>
<p>Before the next send, which for a flow means immediately, because the steps after an unsubscribe are usually queued already. Yahoo's published expectation for bulk senders is two days, and a sequence is the shape most likely to miss it. Check suppression at send time rather than at enrolment and the deadline never comes up.</p>
<p>Yes. Nitrosend is MCP-first: every capability is an API endpoint and an MCP tool before it's a screen, so campaigns, flows, contacts, and segments can be created and changed through MCP tools, the REST API, or the CLI. A flow described as an instruction can be versioned, reviewed, and explained back to you, which a drawing in a builder can't.</p>
<p>Compare it against the send it replaced, over the same window and on the same segment. A flow's own open and click numbers look fine in isolation because there's nothing next to them. The only question worth answering is whether the automated version beats the broadcast you were sending before it existed.</p>