Build an Abandoned Cart Recovery Workflow with Email & SMS

Start with the cart, not just the visit

A visit to your store does not tell you whether a shopper abandoned checkout. Your store integration must associate the contact with a cart, provide a working recovery link, and report purchases or changes that make the reminder irrelevant. Decide which cart to recover if one person has several.

For a return-visit journey, Google Tag Manager supplies activity for a previously identified contact; your store supplies the cart state. For a checkout-triggered journey, send the relevant activity from your store directly. Neither approach discovers the email address of an unknown visitor.

• Contact identity and the cart or checkout reference your store uses.
• Current cart status, recovery URL, and the time checkout was last updated.
• Purchase and cart-expiry updates associated with the correct contact and cart.
• Email eligibility, and separate SMS or push eligibility if you use those channels.

Give the shopper time to finish

Choose a waiting period that fits the purchase. A shopper comparing an annual subscription may need longer than someone buying an everyday item. Define abandonment in your store integration or audience logic, then re-check the purchase state after the wait.

The journey above starts with a recognized return to an open cart and waits one day after the first email. Treat that timing as a starting point. A checkout-start event by itself should not immediately send an abandoned-cart message while the customer is still paying.

Make the next step easy to complete

Use one clear recovery link and a message that offers help. A subject such as “Your saved items are ready when you are” can lead into a short reminder and a reply address for questions. Add cart details only when your store provides current, reliable data for the template.

Test the recovery link on mobile and after signing out. Let the store validate expiry, availability, pricing, and any authentication needed to reopen checkout. Avoid promising that inventory or a discount is reserved unless your store actually enforces it.

Stop the reminder when the purchase happens

Report the purchase back to SendOps and use a goal exit or a branch before later reminders. Connect the signal to the cart being recovered: an old order or an unrelated purchase should not accidentally decide this journey’s next step.

Also handle carts that expire or can no longer be recovered. A delayed event can arrive after a message has already sent, so keep store updates timely and re-check current state in any service performing an external action. A workflow exit cannot recall a message already delivered.

Add SMS or push through a webhook

After the email and a wait, check whether the purchase is still incomplete. A webhook step can call your registered HTTPS endpoint to request an SMS reminder or a push notification. Your service owns the provider connection, current cart lookup, channel consent, and delivery.

Give repeated webhook requests an idempotent handler so a retry does not produce duplicate reminders. A successful response means your service accepted the request; it does not prove the SMS arrived or the customer purchased. Report the outcome you need as contact activity.

Use the webhook’s failed branch for a suitable email fallback. Check that the fallback still makes sense for the contact, and plan a finite sequence across all channels so a shopper is not repeatedly nudged by separate campaigns.

Rehearse the awkward cases before launch

Define when a shopper can enter again. A page reload should not restart the same recovery sequence, while a later, genuinely new cart may deserve another journey. Keep cart identity in your integration and review the workflow’s re-entry setting together.

Use a fixed cohort for a shadow rehearsal to inspect enrollment, waits, branches, and recorded effects. Test your webhook receiver separately with its provider sandbox; shadow mode does not perform the external calls. Review the full enrollment estimate before live activation.

• Purchase completed during a wait or just before the SMS request.
• Cart link expired, item unavailable, or cart contents changed.
• Two carts for the same person, repeated visits, and duplicate store events.
• Email unsubscribe, missing phone number, or no permission for SMS or push.
• Webhook failure, a repeated request, and the email fallback path.

Count completed purchases, not just clicks

Use your store’s order data to measure purchases and revenue for the enrolled cohort within a defined time window. Inspect delivery failures, skipped sends, and contact timelines to understand why a reminder did or did not happen.

A purchase after a reminder is not proof that the reminder caused it. Compare a suitable holdout where practical, and track unsubscribes and complaints alongside recovery. Change the audience, timing, or message based on that evidence.

SendOps charges a flat platform fee, with no per-contact or per-email SendOps charge. AWS bills SES usage separately; your SMS or push provider’s charges also remain separate.