Cart-flow launch sheet

One place to define a checkout-recovery flow and prove it behaves as designed. Write the design, run ten launch cases in a test store or test checkout, and record what actually happened before widening the audience.

Completed example: one checkout flow

An illustrative design for a store that already sends a cart reminder and is adding a checkout flow. It shows the level of detail each line needs. The choices are examples to adapt, not recommended settings, and timing must follow your provider’s current rules and your approved consent design.

Trigger: Checkout started event from the store integration. The test checkout identifier and event time are recorded when it reaches the messaging platform.
Eligibility: Opted-in SMS subscriber, no purchase since the event, not suppressed, not already in another recovery path for this checkout.
Current-state cancellation: Immediately before the send, recheck for a completed purchase, an opt-out and a newer checkout. Any one of these cancels the message.
Message owner: The checkout flow owns the next message. The earlier cart path is suppressed for this shopper while the checkout flow is active. Copy owner: retention lead.
Link check: Return link opened on a phone shows the same items. After an item is removed, it shows the current cart rather than an error.
Reply owner: Product and bundle questions go to the named reply service using approved product information. Order problems go to support during stated hours, with the question attached.
Evaluation window: Orders and contribution counted for 7 days after the checkout event, against eligible shoppers held out from the message. The 7 days is an illustrative choice, set before launch.
Launch status: Design written. Launch cases not yet run, so the flow is not yet verified.

Launch log

Write your own design first, then run each case. An empty observed field means the case has not been tested, even if the intended design is clear.

Your flow design

Trigger Eligibility Current-state cancellation Message owner Link check Reply owner Evaluation window

Summary

0 Tested

0 Matches expected

0 Mismatch

10 Not run

A case only counts as tested once the observed outcome is recorded. Investigate every mismatch before widening the audience.

01Purchase before send

Setup: Start a test checkout, then complete the order before the delay ends.
Expected behaviour: The scheduled message is cancelled and nothing is sent for that purchase.

Observed outcome Status

02Opt-out

Setup: Start a test checkout, then opt the test subscriber out before the send.
Expected behaviour: No recovery message is sent, and the suppression holds across the rest of the programme.

Observed outcome Status

03Repeat cart

Setup: Abandon one checkout, then start a second one with different items.
Expected behaviour: One recovery path is active under your precedence rule, with no duplicate sends, and the message reflects the current cart.

Observed outcome Status

04Checkout advancement

Setup: Add to cart, wait until the cart path is scheduled, then move into checkout.
Expected behaviour: The cart path is cancelled or suppressed as designed, and the checkout flow owns the next message.

Observed outcome Status

05Unsubscribed shopper

Setup: Start a checkout as a known customer who is not currently subscribed to SMS.
Expected behaviour: The shopper does not enter the flow and receives no recovery text.

Observed outcome Status

06Link after the cart empties

Setup: Remove every item from the cart, then open the return link from the message.
Expected behaviour: The link lands on a useful page with a clear route to the items, not an error or a blank checkout.

Observed outcome Status

07Cross-device return

Setup: Start checkout on a desktop browser, then open the text link on a phone.
Expected behaviour: The link restores the checkout or gives a clear route back to the same items.

Observed outcome Status

08Overlapping email

Setup: Let the email recovery message send for the same checkout first.
Expected behaviour: The text follows your agreed channel precedence and spacing. No near-simultaneous duplicate.

Observed outcome Status

09Unmatched reply

Setup: Reply to the message with Does this include the refill, or do I buy that separately?
Expected behaviour: The reply reaches the named owner within stated hours and the shopper gets an answer or a clear next step.

Observed outcome Status

10Offer exclusion

Setup: Abandon a checkout containing an item excluded from the current offer.
Expected behaviour: The message makes no offer promise for the excluded item, and any discount applies only under the offer rules.

Observed outcome Status

Sources and limits

This sheet records tests. It does not send, schedule or change anything in your messaging platform, and it makes no statement about legal or regulatory compliance. Timing, frequency and consent handling must follow your provider’s current rules and the programme’s approved compliance design.

The completed example and cases are original teaching material. A matching result shows the flow behaved as designed for that case at that time. It is not a forecast of recovered orders. Re-run affected cases after any change to the integration, the delay or the precedence rules.

Provider documentation cited in the companion article. Recheck the applicable setup before implementation, because instructions can change.

Postscript: current recovery guide

Attentive: checkout-started examples