Audit Your Email Flows Before They Contradict Each Other

Map the journey before you open the canvas

Before opening the automation tool, write down what should happen in a few recognisable situations. In the example, checkout C-41 becomes order O-81. The agreed behaviour: reminders for C-41 should stop asking the customer to finish that purchase. Product guidance for O-81 should follow the store’s approved timing. An unresolved missing-item complaint should affect promotional recommendations according to the store’s chosen service-priority policy.

Add a second transaction: the same customer starts another checkout, C-42, for a different purchase. Decide whether the reminder policy applies to C-42 independently, or pauses all reminders after any recent purchase. Either design needs a reason, eligibility rules and a test — do not let an inherited filter make that commercial decision by accident. Write the expected behaviour for cancellation too: cancelling a later order does not automatically invalidate useful guidance tied to an earlier, delivered order.

Without the expected journey written down, an audit can spot unusual-looking logic but cannot tell whether it contradicts what the business intended.

Once the expected journeys are agreed, build a register of every flow that can reach the same customer around a purchase — campaigns, manual sends and connected service messages included. For each one, record its trigger, identity scope, entry and re-entry conditions, action eligibility, timing and priority, and what a skip or exit actually does next. If nobody can explain why a suppression exists, keep it while you investigate: deleting an unexplained rule can remove a deliberate protection as easily as a defect.

Separate admission, eligibility and exit

Flow labels hide different behaviours. A condition can be evaluated on admission, re-checked later, or applied only at the moment of a specific action — and even within one platform, different trigger types can use different timing. Keep entry, continuing eligibility, action eligibility, re-entry, skip and exit as six separate questions rather than one assumption.

A skipped message does not necessarily remove someone from the flow; they may continue to a later step and qualify there. A pause, a failed filter and an explicit exit are not interchangeable, so verify documentation, settings and test history rather than guessing from a rule’s name. For the storage-box customer, deciding not to send a recommendation during the open complaint may be correct. What happens next still needs a decision: should later recommendations stay eligible once the complaint is resolved, or does a new event need to trigger them? Would restarting the flow from the beginning repeat a message the customer already saw?

A useful audit translates configuration into something a colleague can verify. “This rule suppresses customers” is not a finding. “This condition is checked before the promotional step, skips that step, and leaves later steps scheduled” is.

Follow one customer through the evidence

A reminder can apply the correct rule to the wrong record. Before changing the timing on the C-41 reminder, establish how the checkout and the resulting order are actually linked: did the purchase reach the same profile, did the integration keep the checkout reference, and is the flow reading the intended order or a general profile property? A matching name is not proof of identity — use the store’s documented identifiers and flag unresolved associations instead of merging records by guesswork.

Then check the message content itself. It can link to a different checkout even when the products look similar, or carry a stale product list copied from an earlier event. Keep the C-42 case in the test pack: a fix that stops the wrong C-41 reminder but also blocks every genuinely unfinished later checkout may have traded one defect for another.

The commerce system can also know a fact before the messaging system has processed it, so a rule can behave exactly as configured and still act on stale information. Trace the source event through receipt, processing and the state used for the action, and keep “not received,” “received but not applied” and “applied but ignored” as separate findings — they point to different owners and different fixes.

Review the skips before you reduce them

A skip total is a starting point, not a diagnosis. Some skips are correct exclusions; others reflect missing data or a configuration defect. Inspect the recipient-level reason alongside the actual customer state, not just the count.

In an invented review of twenty skipped product-guide opportunities, twelve were correctly excluded, five were genuinely eligible but blocked by an overbroad condition, and three could not be classified because the order association was missing. That is five verified missed actions to investigate — not “twenty lost messages,” and not proof that every suppression should be removed. Check a comparable set of sent messages too: reviewing only skips misses inappropriate sends, and reviewing only sends misses who was silently excluded.

AI can turn a large configuration export into a readable comparison, but keep extraction, hypothesis and verification separate. Require the exact rule, the assumed customer state and a test journey for every proposed conflict before treating a warning as a confirmed defect; if the evidence cannot be traced to a specific setting, it stays a question, not a finding. Build synthetic test journeys with an agreed expected outcome for each one, including delayed and duplicate events, and add a valid neighbouring case to every failure test so a fix that stops a bad reminder doesn’t quietly block a good one.

Rollback restores settings; it does not retract an email that has already reached a customer.

Before release, capture the current settings and a reproducible description of the defect, make a bounded change, then rerun the affected journeys. Decide what happens to people already waiting in the flow, and keep the previous configuration and a way to pause it.

• Define the expected journeys. Agree what should happen after purchase, service activity, cancellation and a genuinely separate unfinished checkout.
• Build the flow register. Current versions, owners, identity scope, evaluation timing, re-entry and the real effect of a failed condition.
• Trace the shared customer state. Transaction associations and authoritative purchase, support and permission data into the action decision.
• Review sends and skips together. Separate inappropriate sends, correct exclusions, missed eligible actions and unresolved evidence.
• Use AI for testable findings, not verdicts. Require the exact rule, the record and a proposed test before calling a warning a defect.
• Run synthetic journeys over time. Delayed and duplicate events, later eligibility changes and valid neighbouring cases that should still work.
• Release a bounded, versioned repair. Verify saved settings and queued-action treatment, and keep an owner for the recovery route.