# Build an Abandoned Cart Recovery Workflow with Email & SMS Type: Playbook Canonical: https://sendops.dev/guides/abandoned-cart-email-workflow/ Publisher: SendOps Updated: 2026-10-04 An abandoned cart recovery workflow helps a known customer finish an incomplete purchase. Connect your store’s cart and order data, wait long enough to distinguish a pause from abandonment, and check that the cart is still recoverable before each reminder. Send email through your own Amazon SES account and use webhooks to reach your SMS or push service when appropriate. ## Journey at a glance - **Who it helps:** Known shoppers with a recoverable cart and permission for the intended channel. - **What starts it:** A recognized return visit with an open cart, or a store event that identifies an abandoned checkout. - **The sequence:** Check cart → send recovery email → wait → check purchase → optional SMS webhook or final email. - **When it stops:** Purchase completed, cart no longer recoverable, or the final follow-up. Check channel eligibility before sending. - **What to measure:** Completed purchases among enrolled shoppers, time to purchase, and revenue alongside unsubscribes and complaints. - **Beyond email:** Call your SMS or push service; it checks current cart state and channel consent before delivering. ## 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. ## Common questions ### Do I need Google Tag Manager for abandoned cart recovery? No. A store integration can supply the cart and checkout activity directly. Google Tag Manager is useful when a recognized return visit is part of the trigger; it does not replace cart or purchase data. ### Does SendOps send SMS natively? No. A workflow webhook calls your service, which sends through your chosen SMS provider and checks channel consent. Email is delivered through your own Amazon SES account. ### How many cart reminders should I send? Use a short, finite sequence appropriate to the purchase. Begin with a useful email, check purchase state before any follow-up, and add another channel only when it helps the customer. There is no single schedule that fits every store. ### Will reminders stop as soon as someone buys? Your integration must report the purchase, and your workflow must use that information in an exit or branch. Timely state updates matter: SendOps cannot undo a reminder that already sent before the purchase signal arrived. ## Sources and related reading - [Returning visitors and Google Tag Manager](https://sendops.dev/guides/website-triggered-email-workflows/) - [Test your email workflows](https://sendops.dev/guides/test-email-workflows/) - [Workflow webhook receiver documentation](https://developers.sendops.dev/api-reference/workflow-webhook) - [SendFlow webhook reference](https://help.sendops.dev/workflows/flow-reference#calling-your-own-systems) - [Workflow pricing](https://sendops.dev/pricing/)