How to test marketing automation: 22 checks before you switch it on.

You cannot test a workflow with a contact who looks like nobody.

The record most people test with is a blank one: a new email address, no history, no purchases, no attendance. It passes, because a blank record takes the simplest path through everything.

Build one seed per segment you genuinely have. If the workflow treats a returning customer differently from a first-time lead, you need a seed who owns something and a seed who owns nothing. If it branches on whether somebody attended, you need one of each. The starting state is the test — the message is just what falls out of it.

Give each seed an inbox you can actually open. Plus-addressing on a mailbox you already own is usually enough to make several identities that all arrive in one place, and reading the delivered message is the only way to catch the failures that a preview screen hides. Then tag every seed as a test record, because in three weeks somebody will run a report and quietly include them, and in three months somebody will send them a campaign.

The branch nobody tests is the branch most people take.

Testing tends to follow the happy path, because the happy path is the one you were imagining while you built it. The else branch — did not open, did not click, did not buy — is where the majority of a real audience ends up.

Write the paths down before you start. Literally list them: engaged, not engaged, already a customer, missing data, matched two rules at once. A written list turns testing from a feeling into a count, and the count is what tells you when you are finished. Firing each one at least once is the whole standard, and it is a standard most sequences have never been held to.

Two paths deserve special attention. The first is the contact who satisfies two conditions at once — engaged and already a customer, say — because branch order decides the outcome and branch order is invisible until something goes to the wrong person. The second is missing data. Records arrive without a first name, without a source, without the field your condition depends on, and a condition tested only against complete records will behave in a way nobody predicted.

Compress the clock to test it. Then put the clock back.

Nobody waits thirty days to find out whether a thirty-day sequence works. Shorten every delay to minutes, run the paths, and you have an afternoon’s work instead of a month’s.

The technique has one requirement and it is the item people skip: write down every delay you shortened. Not “I changed a few” — a list, with the step name and the real value beside it. The single most common automation incident is not a broken condition. It is a sequence that went live still compressed, so somebody received five emails in eleven minutes, and the reply that followed was not about the offer.

A compressed clock also hides an entire class of failure. Anything defined against real time — quiet hours, weekday-only sending, a delay that lands at 03:00 for somebody eight hours ahead — cannot be observed at two-minute intervals. Run at least one path at its real length before the first cohort, and check a seed who lives somewhere other than where you do. A send scheduled for nine in the morning is nine in the morning somewhere; you should know where, and it should be a decision rather than a default.

Hi [FIRSTNAME], and other things that reach real people.

Everybody has received one. A merge field that did not merge, sitting at the top of an otherwise careful email, telling every recipient exactly how much attention was paid.

It happens for a specific reason: the message was tested against a record that had the value. The fallback is the part being tested, so render every merge field twice — once on a complete record and once on one where the field is empty. And check what the fallback actually produces, because a greeting that resolves to “Hi ,” with a floating comma is only marginally better than the placeholder it replaced. Where a name is not guaranteed, the safest fallback is often a greeting that does not need one.

Then read the delivered message rather than the editor. Click every link in it: tracked links break in ways that only appear after the redirect, campaign parameters get pasted twice, and the unsubscribe link is the one nobody ever tests because nobody wants to unsubscribe from their own list. Read it on a phone, in plain text, and with images blocked, since a message whose entire offer lives inside an image says nothing at all to a reader whose client blocks it.

Last, search the whole sequence for leftovers before switching anything on. Sample copy, internal notes to a colleague, a subject line that still says “test”, the paragraph somebody meant to rewrite. These survive because each message was reviewed on its own and never read end to end as a series.

The expensive failures are all about stopping, not starting.

A workflow that fails to send is a disappointment. A workflow that fails to stop sends a discount to somebody who bought at full price yesterday, or a fourth sales email to somebody who asked to be left alone.

Test the unsubscribe end to end, from the delivered message rather than from a settings screen. The specific thing being verified is scope: that opting out stops everything, not only the sequence the click came from. Somebody who unsubscribes on Tuesday and receives a different automated email on Thursday has been told something about your operation that no apology corrects.

Purchase mid-sequence is the other one, and it is the check that most often reveals a structural problem rather than a configuration error. When somebody buys on day two of a five-day sequence, the remaining sales messages have to stop and the delivery or onboarding path has to start. If the purchase lives in one system and the sequence in another, this is where you find out how long the gap between them really is — and that gap is measured in emails, not minutes.

Then decide re-entry deliberately. Can the same person enter this workflow twice? For a welcome sequence the answer is usually no; for an abandoned-checkout recovery it is usually yes, with a cooling-off period. What matters is that it is a decision you made and verified, rather than whatever the default happened to be. The same goes for two workflows that both want to message the same person on the same morning: test it with one contact who qualifies for both and find out what they receive.

Release it to a few people you are prepared to apologise to.

Seeds prove the mechanism. Only real contacts prove the assumptions — about the data, the volume, and the fact that people behave in ways no test identity ever does.

Start with the restore. Read the flow top to bottom against the list of delays you shortened, and confirm each one by looking at it rather than by remembering. This takes minutes and prevents the incident that costs a day.

Then release small and watch. The first cohort is not a marketing decision, it is a test: enough people to be real, few enough that a mistake is a conversation rather than a broadcast. Watch four things while it runs — how many sends actually went out, what came back as replies, what came back as unsubscribes, and what the execution history says about the paths those contacts took. Replies are the most informative and the most ignored: a confused reply is a workflow bug somebody took the trouble to report.

Write the rollback before you launch, not during the incident. Three lines: how the workflow is paused, who is allowed to pause it without asking, and what gets sent to anybody who received the wrong thing. Automation failures repeat themselves at machine speed, so the value of a rollback is entirely in how quickly it can be executed by whoever happens to notice first.

Eight rows, an expectation on each, a result column you fill in.

A test without a written expectation is a demonstration. Deciding what should happen before you trigger anything is what turns clicking around into testing.

Below is an illustrative log for a sequence with an engaged branch, a fallback, a customer exclusion and the usual exits — the paths and seeds are examples, not a prescription. Copy it, replace the rows with your own paths, and add one row per endpoint on your canvas. The empty result column is deliberate: it is the difference between a workflow somebody believes works and one somebody has evidence for.

Keep the finished log next to the workflow. When somebody edits it in four months — and somebody will — the log tells them which paths existed, which seeds to reuse, and what the behaviour was supposed to be before the change.

Half of this list is only difficult because the data lives in two places.

This is the one place on the page where the products you chose genuinely change the work rather than the preference, so it is worth being specific about which checks get harder.

The distinction matters most in the exits group. Every check in it depends on one system knowing what another system just learned, and each hop adds a place where the chain can stop without telling anybody. That is also why stitched automations fail silently rather than loudly: nothing errors, a message simply does not stop, and you find out from a reply.

For a first workflow, stitching is a reasonable choice and this list works exactly as well — you just budget more of the testing time for the connections. The threshold is the point where the number of workflows exceeds the number of hours anybody has to re-verify them after every change.