Checks 1–3: does the trigger fire, is the timing from data, and is the segment defined?
The first three checks are whether a flow starts for the right people at the right time. The trigger must fire on the event it claims: a cart abandonment flow that triggers on any page view is wrong. The timing must match order data: a replenishment flow's interval should sit near the median reorder gap for that SKU, and a win-back threshold near the point where returning customers in this store had already returned. The segment must have a written definition and a current size.
- Trigger: send a test event and verify the flow enters exactly one contact for exactly that event.
- Timing: pull the median reorder gap for the SKU from orders; verify the flow's interval is within a few days of it.
- Segment: read the definition and the count; verify both are visible and the definition excludes who it should.
Checks 4–6: do exits work, does the cap apply, is the suppression list honoured?
The next three checks stop a flow from becoming noise. Exit conditions must remove a contact when the goal is met: a cart flow must stop the moment the purchase happens, a win-back must stop when the customer returns. The frequency cap must apply across flows and campaigns, so a contact in two flows does not receive both in full. The suppression list must be honoured before every send, per contact, not assumed from a setting.
- Exit: complete the goal action for a test contact mid-flow; verify no further message is sent.
- Cap: place a test contact in two overlapping flows; verify the cap holds and the priority rule decides which sends.
- Suppression: add a test contact to the list; verify they receive nothing from any flow or campaign.
Checks 7–8: is SMS consent recorded, and does every message preview correctly?
The consent and preview checks are the ones with legal and reputational weight. SMS consent must be recorded per contact with the source and time of consent; a list imported without that record must not receive SMS. Every message must render correctly on the devices it targets, with working links, correct personalization fallbacks and a visible unsubscribe path.
- Consent: sample contacts in the SMS segment; verify each has a consent record with source and timestamp.
- Preview: render each message on a phone and a desktop client; verify links, fallbacks and the unsubscribe path.
Checks 9–11: are claims sourced, is attribution fixed, and is there a holdout?
The last three checks keep the flow honest. Product claims in a message must be sourced from the catalog or approved copy, the same fact-gate that governs product pages. Attribution must use the window the owner chose before results existed, printed on the report. A holdout, a portion of the segment that receives nothing, must exist on any flow whose incremental revenue the store intends to claim.
- Claims: for each product statement, verify a catalog field or approved copy supports it.
- Attribution: read the report; verify the window is printed and matches the one set in Setup.
- Holdout: verify a holdout group exists for the flow and that its size is reported alongside results.
How should the checklist be run across all flows?
The checklist should be run flow by flow, starting with the flows that carry the most revenue per recipient and the flows that send the most volume, because a broken exit or a missing cap on a high-volume flow does the most damage. Record the result as a pass or fail per check per flow and keep it; the record is the baseline for the next audit and the evidence for what was fixed.
Failures cluster. A missing exit condition on one recovery flow is usually missing on the others; a cap that does not apply to campaigns is a platform setting, not a flow setting. Fixing the cause fixes the cluster.
What does the Retention FTE add to a manual audit?
The Retention FTE on ftes.ai runs all eleven checks on every flow on connection, reports them in the Flows tab, and re-runs them daily so a flow that breaks after a platform update is caught the next morning. It proposes the fix for each failure in Approvals with the reasoning and the preview, and it enforces the cap and suppression list itself rather than relying on the platform's settings alone.
What it does not add is the decision. The owner still approves each fix and still owns the offer rules. The audit becomes a daily state instead of a quarterly project, which is the difference between a function and a task.