Abandoned Cart Recovery

Most of the people who put something in a cart do not buy it on that visit. That is not a fault in the store; it is how browsing works. People compare, get interrupted, hit a shipping cost they did not expect, or simply run out of attention on a train. The failure is not the abandonment. The failure is that nothing happens afterwards, or that what happens is three identical emails from the same template inside twenty-four hours.

Two opposite mistakes are common, and both cost money. The first is doing nothing: the platform's built-in recovery email is switched off, or it goes out once, twelve hours later, from a no-reply address, and nobody looks at the open rate. The second is doing too much: an aggressive sequence that hits email and SMS simultaneously, discounts on the first touch, and keeps going after the customer has already bought something else. That version trains a customer base to wait for the discount, and it generates unsubscribes and spam complaints that degrade deliverability for every other message the business sends.

Underneath both sits a measurement problem. Without a frequency cap and a suppression layer, a shopper who abandons three carts in a week receives three overlapping sequences and concludes the brand is broken. Without channel-level tracking, nobody can say whether the recovery revenue came from the email, the SMS, or from people who would have come back anyway. This build runs a disciplined three-touch, two-channel ladder with a hard cap, an explicit discount policy, and attribution that distinguishes recovered revenue from revenue that was never at risk.

Pipeline and stages

A lightweight pipeline, Cart Recovery, used as an operational board rather than a sales forecast. Carts are high-volume, so the stages are deliberately few.

• Cart Active: items added, session still live. No messaging fires from here; a 30-minute hold prevents messaging someone who is still typing their card number.
• Cart Abandoned: 30 minutes of inactivity with items present and a contactable identity.
• Recovery In Progress: at least one touch sent, sequence running.
• Recovered: order placed with cart overlap, attributed to this sequence.
• Expired: the full ladder ran with no purchase. Not a failure state to be re-sequenced, just a closed one.
• Suppressed: recovery stopped deliberately: opted out, frequency cap hit, bought something else, or an open support ticket.

Custom fields

• Cart ID: the store's own identifier, the join key for everything
• Cart Value: number, drives the value-tier branch
• Cart Item Count
• Cart Top Item Name and Cart Top Item Image URL: the single highest-value line, used in message copy and the preview image. Naming the actual product outperforms “your cart” consistently.
• Cart Recovery URL: the tokenized link that restores the cart. Without this the whole build is just a reminder.
• Cart Abandoned At: timestamp, the clock every wait is measured from
• Cart Category: primary product category, used for routing and copy
• Recovery Touch Count: integer, incremented per send and checked against the cap before every send
• Recovery Channel Last Used: Email / SMS / Chat, so the next touch alternates instead of repeating
• Discount Offered: switch, with Discount Code Issued and Discount Expires At
• Recovered Order ID and Recovery Attributed Channel
• Abandonment Reason Given: dropdown: Shipping Cost / Delivery Time / Price / Payment Issue / Out Of Stock / Changed Mind / Still Comparing / Technical Problem. Populated by BO or by a one-question reply, and the most useful field in the build for anyone who wants to fix the store rather than paper over it.
• Lifetime Order Count and Last Order Date: pulled from the store, used to treat a repeat customer differently from a first-timer
• Marketing Consent SMS and Marketing Consent Email: separate switches, never inferred from a purchase

Tags

• cart-abandoned: applied on entry, removed on recovery
• cart-recovered, cart-expired
• cart-high-value: above the value threshold, gets the extra human touch
• cart-repeat-customer: Lifetime Order Count of 1 or more, changes the tone and skips the trust-building content
• cart-first-timer
• cart-discount-issued: prevents a second discount inside the cooling-off window
• cart-recovery-suppressed: the master brake
• cart-serial-abandoner: three or more abandoned carts in 30 days, drops to email only
• sms-opted-out, email-unsubscribed: hard suppression

Frequency caps and suppression rules

This is the part most cart builds skip, and the part that determines whether the list survives.

• Maximum 3 recovery touches per cart, ever. Recovery Touch Count is checked before every send.
• Maximum 1 SMS per cart. SMS is the expensive, intrusive channel; it gets one shot and it is the second touch, not the first.
• Maximum 4 recovery touches per contact per rolling 30 days across all carts. A shopper who abandons every week gets one sequence, not four.
• Minimum 7 days between sequences for the same contact. A new cart inside that window updates the existing card rather than starting a new ladder.
• Three or more carts in 30 days applies cart-serial-abandoner and restricts that contact to email only. These are usually wishlist users, not hesitant buyers.
• Hard stops: any order placed (even for different items), an open support conversation, a return or refund in progress, sms-opted-out or email-unsubscribed, or a reply to any recovery message, which hands the thread to BO.

Forms and pages

• One-Question Abandonment Survey: a single-question page linked from the third touch: what stopped you? with the eight Abandonment Reason Given options and an optional comment. No contact fields, one click. Response rates on a single-question survey are a different order of magnitude from a multi-field one.
• Cart recovery landing page: used when the tokenized cart URL has expired. Rather than a dead page, it shows the remembered items with an add-to-cart action and the shipping policy.
• Back-In-Stock Notify form. For carts abandoned because an item ran out, which is a different problem wearing the same clothes.

BO's role and guardrails

• BO does: answer replies to recovery messages on SMS, email and web chat; answer shipping cost, delivery time, returns-window, sizing and stock questions from the knowledge base; capture Abandonment Reason Given conversationally; re-send a fresh cart link; apply a pre-approved discount code where the discount policy allows it; register a back-in-stock notification; hand off to a human.
• BO does not: invent or negotiate a discount beyond the pre-approved code, promise a delivery date the shipping rules do not support, process a payment, override a stock position, or handle anything about an existing order, a refund or a complaint.
• Escalation triggers: the words refund, return, damaged, wrong item, complaint, chargeback or fraud; a payment failure the customer describes; cart-high-value; any pricing negotiation; two stalled turns; an explicit request for a person.
• Knowledge base: shipping costs and thresholds by zone, delivery timeframes by method, the returns and exchange policy in plain words, sizing guidance by category, which payment methods are accepted, how to apply a discount code at checkout, and the most common technical checkout failures and their fixes.

Numbers and channels

• A dedicated store number for SMS so order and recovery traffic is separable from any other messaging the business does.
• Two-way SMS enabled. A recovery SMS that cannot be replied to wastes the one channel people actually answer on.
• Missed-call text-back on the store number, since a recovery SMS will generate inbound calls.
• Email sending on an authenticated subdomain, warmed before launch. Cart recovery is high-volume and will expose a cold domain immediately.
• Web chat on the cart and checkout pages specifically, not just the homepage, with BO primed to answer shipping and returns questions, because those two questions cause most checkout abandonment.
• Channels unified per contact, so a reply by SMS, a web chat message and an email all land in one thread rather than three.

One cart, from the add-to-cart tap to the recovered order.

1. 9:12pm, Wednesday. A returning customer adds two items to their cart on a phone, enters an email address at the first checkout step, then stops when the shipping options load. Card created at Cart Active. Nothing is sent.
2. 9:42pm. Thirty minutes of inactivity. The card moves to Cart Abandoned, Cart Abandoned At is stamped, and cart-abandoned is applied. The 30-minute hold exists because messaging someone who is still mid-checkout is the fastest way to lose the order.
3. The suppression checks run before anything else. No order in the last 30 minutes, no open support conversation, Recovery Touch Count under the per-contact 30-day cap, no sequence in the last 7 days, not sms-opted-out. All clear.
4. Segmentation. Lifetime Order Count is 3, so cart-repeat-customer is applied and the first-timer trust content is suppressed. This person already knows the returns policy. Cart Value sits below the high-value threshold, so no human task is created.
5. 10:42pm, one hour after abandonment. Touch one, email. Subject names the product, not the cart. The body shows both items with images, the shipping cost spelled out plainly, and a single button restoring the cart. No discount. Recovery Touch Count = 1, Recovery Channel Last Used = Email. The send is inside the email window; the SMS window would have held it until morning.
6. Thursday 11:00am. No order. Touch two, SMS. The one SMS this cart will ever get, and it goes out mid-morning rather than at the same time as the email. It names the item, carries the recovery link, and ends with the opt-out. Recovery Touch Count = 2.
7. 11:04am. The customer replies: is the shipping really that much to Scotland? Reply detection pauses the sequence instantly and hands the thread to BO.
8. BO answers from the shipping table: the rate for that zone, the free-shipping threshold, and how far this cart is from it. It writes Abandonment Reason Given = Shipping Cost. That single captured field is worth more to the business than the order, because it is the fourth time this week.
9. BO offers the pre-approved route. Because the cart is close to the free-shipping threshold, BO suggests the qualifying addition rather than a discount: “You're not far off free shipping: adding one more of the [item] would cover it. Want the link?” The discount code stays in the drawer; it is the third touch's tool, not the second's.
10. The customer adds the item and checks out. The order webhook fires, matched on Cart ID.
11. Attribution and cleanup. Card moves to Recovered, Recovered Order ID and Recovery Attributed Channel = SMS are written, cart-abandoned is removed and cart-recovered applied, and every remaining step of the ladder cancels, including the third touch that would otherwise have arrived the next day offering a discount on an order already paid for.
12. The contact exits cart recovery and enters the post-purchase flow, which is a separate build and must not overlap with this one.
13. Meanwhile, on the carts that did not recover: touch three goes out 48 hours after abandonment, carrying the time-limited discount code where policy allows it, plus a link to the one-question survey for anyone who is not going to buy but will tell you why.
14. 72 hours after abandonment with no order, the card moves to Expired and the contact is locked out of cart recovery for 7 days. They stay on the general marketing list if consent exists; they do not get re-sequenced on the same cart.
15. Weekly, the Abandonment Reason Given distribution is reviewed. If Shipping Cost dominates, the answer is a shipping-policy change, not a better email. That is the real output of this build.

Seven workflows. Workflow 1 is the gatekeeper: nothing else sends until it has cleared the contact. Every send also checks the channel's own window and the per-contact daily cap.

1. Cart Capture and Eligibility Gate

Trigger: cart-updated webhook from the store, with at least one line item and an identifiable contact (email or mobile captured at checkout, from an account login, or from a previous order).

Actions:

1. Create or update the card at Cart Active. Write Cart ID, Cart Value, Cart Item Count, Cart Top Item Name, Cart Top Item Image URL, Cart Recovery URL, Cart Category.
2. Wait 30 minutes. Condition: no further cart activity and no order? Move to Cart Abandoned, stamp Cart Abandoned At, apply cart-abandoned.
3. Run the eligibility gate. Any failure moves the card to Suppressed and exits:
4. : an order was placed in the last 30 minutes, for any items;
5. : an open support or returns conversation exists on this contact;
6. : sms-opted-out and email-unsubscribed are both present (if only one is, continue on the other channel);
7. : Recovery Touch Count across all carts in the last 30 days is already 4 or more;
8. : a recovery sequence ran for this contact inside the last 7 days;
9. : three or more abandoned carts in 30 days → apply cart-serial-abandoner, restrict to email only, and allow a maximum of one touch.
10. Segment: Lifetime Order Count 1 or more → cart-repeat-customer; zero → cart-first-timer. Cart Value above the high-value threshold → cart-high-value.
11. Move to Recovery In Progress and hand to workflow 2.

Exit: gate failure, or any order placed.

2. Touch One: Email Reminder

Trigger: handed from workflow 1.

Actions:

1. Wait 1 hour from Cart Abandoned At. Short enough that the intent is still warm, long enough not to look like surveillance.
2. Condition: still no order, Recovery Touch Count under 3, not email-unsubscribed? If the email window has closed, hold until it opens.
3. Branch: cart-first-timer: send the version that includes the returns window, the delivery promise and the payment methods accepted. A first-time buyer's hesitation is usually about trust, not price. Subject: “Your [Cart Top Item Name] is still in your basket”. Body opens: “No rush: we've kept it for you. Here's what you had, along with the bits people usually want to check before ordering: delivery takes [X] working days, returns are [Y] days, no questions asked.”
4. Branch: cart-repeat-customer: shorter, warmer, no policy content. Subject: “Left something behind, [First Name]?” Body: “Your [Cart Top Item Name] is still saved. One tap and it's back in your basket.”
5. Both versions: item images, the line-item list, shipping cost stated plainly rather than hidden until checkout, and exactly one call to action pointing at Cart Recovery URL. No discount.
6. Reply-to is a monitored address, not no-reply. Set Recovery Touch Count = 1, Recovery Channel Last Used = Email.

Exit immediately on: order placed, any reply (hand to workflow 5), or email-unsubscribed.

3. Touch Two: SMS

Trigger: 1 hour after touch one sent, with no order.

Conditions, all required: Marketing Consent SMS is true, not sms-opted-out, not cart-serial-abandoner, Recovery Touch Count = 1, and a cell number exists. Any failure skips straight to workflow 4.

Actions:

1. Wait until the next occurrence of 11:00am local time, inside the SMS window. Never send a recovery SMS at the same moment as the email, and never overnight. This single scheduling rule does more for opt-out rate than any copy change.
2. Send one SMS, and only one: “[First Name]. Your [Cart Top Item Name] is still saved at [Store Name]. Finish up here: [Cart Recovery URL], or just reply if you have a question about delivery or sizing, a real person (or BO) will answer. Reply STOP to opt out.”
3. The invitation to reply is deliberate. It converts a broadcast into a conversation and is where Abandonment Reason Given comes from.
4. Set Recovery Touch Count = 2, Recovery Channel Last Used = SMS.
5. Branch: cart-high-value: additionally create a task on the customer-service owner: Personal follow-up: high-value cart, [Cart Top Item Name], due in 4 business hours. A high-value cart justifies a human; a low-value one does not.

Exit immediately on: order placed, any reply, or sms-opted-out.

4. Touch Three: Obstacle Removal and Survey

Trigger: 48 hours after Cart Abandoned At with no order.

Conditions: Recovery Touch Count under 3, no reply received, channel consent intact.

Actions:

1. Branch on the discount policy, decided before launch, not improvised here:
2. : Discount permitted and cart-first-timer and Cart Value above the minimum: issue a unique, single-use, 72-hour code. Write Discount Code Issued and Discount Expires At, apply cart-discount-issued and Discount Offered. Email: “Still thinking about the [Cart Top Item Name]? Here's a code that takes a bit off, valid until [Discount Expires At]: [code]. After that it's gone. We only send these once.” The honesty about it being once-only is what stops the code becoming an expectation.
3. : Discount not permitted, or cart-repeat-customer, or cart-discount-issued within 60 days: send the no-discount version, which removes an obstacle instead of cutting the price: free-shipping threshold and how close the cart is to it, stock position on the top item, the returns promise, and a prompt to ask a question. “Last note about the [Cart Top Item Name]. It's still in stock and still saved. If something's holding you up, tell me what it is and I'll sort it: [link]”
4. Both versions include the One-Question Abandonment Survey link, framed as a favor rather than a form: “Not going to buy? That's completely fine. One click to tell us why genuinely helps: [link]”
5. Set Recovery Touch Count = 3.
6. Wait 24 hours. Condition: no order and no survey response? Move the card to Expired, apply cart-expired, remove cart-abandoned, and lock the contact out of cart recovery for 7 days.

Exit: order placed, reply received, or expiry.

5. Reply Handling and BO Conversation

Trigger: inbound reply on any channel from a contact carrying cart-abandoned, or a new web chat on the cart or checkout page.

Actions:

1. Pause every scheduled step on this cart immediately. A sequence that keeps firing while the customer is mid-conversation is the most damaging failure mode in this entire build.
2. Hand to BO with the shipping, delivery, returns, sizing and payment knowledge base, plus the live stock position on the cart items.
3. BO classifies the message and writes Abandonment Reason Given from the eight options. Classification happens before the answer, so that even a conversation that goes nowhere leaves the reason behind.
4. Branch: Shipping Cost: state the rate for their zone, the free-shipping threshold and the gap. Offer the qualifying-item route before any discount.
5. Branch: Delivery Time: give the real window by method, and the cut-off for next-day if it exists.
6. Branch: Out Of Stock: confirm the position, offer the Back-In-Stock Notify form, and suggest the nearest in-stock alternative in the same category.
7. Branch: Payment Issue or Technical Problem: apply cart-escalated, create an urgent task, and notify a human. This is not a marketing problem, it is a broken checkout, and it is probably affecting other customers right now.
8. Branch: Price or Still Comparing: BO answers on value, not price: materials, guarantee, what is included. It applies a discount code only if the pre-approved policy allows it at this touch, and never invents one.
9. Branch: Changed Mind: BO thanks them, applies cart-recovery-suppressed, moves the card to Suppressed, and stops. Honouring a no is what makes the next sequence credible.
10. Escalation: refund, return, damage, complaint, chargeback or fraud language, or two stalled turns → assign to a human with the full thread.
11. On resolution with intent to buy, BO sends a fresh Cart Recovery URL (the original token may have expired) and resumes the ladder only if the remaining touch count allows and at least 24 hours have passed.

Exit: order placed, suppression applied, or human takeover.

6. Recovery Attribution and Sequence Teardown

Trigger: order-created webhook from the store.

Actions:

1. Match the order to an open card on Cart ID first, then on contact identity with any line-item overlap, then on contact identity alone within the recovery window.
2. Branch: matched to an open recovery card: move to Recovered, write Recovered Order ID and set Recovery Attributed Channel from Recovery Channel Last Used plus the link click, apply cart-recovered, remove cart-abandoned.
3. Cancel every pending step across workflows 2, 3 and 4 for this contact. Test this path specifically; a recovery discount arriving after the customer paid full price is the single most expensive bug in a build like this.
4. If Discount Code Issued exists and was not used on the order, void the code so it cannot be redeemed later.
5. Branch: order with no matching cart: record it as organic, not recovered. Resisting the temptation to claim it is what makes the whole report believable.
6. Apply cart-recovery-suppressed for 7 days, then clear it, so a next-day abandonment does not immediately re-sequence a fresh customer.
7. Hand the contact to the post-purchase build and exit.

Exit: on completion.

7. Holdout Group, Reporting and Weekly Review

Trigger A: holdout assignment: on entry to Cart Abandoned.

1. Assign a deterministic 5 percent of eligible carts to cart-holdout, hashed on Cart ID so the assignment is stable and reproducible.
2. Holdout carts receive no recovery messaging at all and are tracked for organic purchase within 7 days.
3. The difference between holdout and treated purchase rates is the real incremental recovery rate. Without it, you are reporting the behavior of people who were coming back anyway.

Trigger B: weekly report, Mondays 7am:

1. Compile and send to the store owner and the marketing owner: carts abandoned, carts with a contactable identity, recovery rate against that denominator, recovered revenue gross and net of discounts and SMS cost, recovery rate by touch and by channel, holdout comparison, discount dependency, opt-out and unsubscribe rate on recovery sends specifically, and the Abandonment Reason Given distribution.
2. Create a recurring task: Review abandonment reasons: action the top cause. The report is not the deliverable; the shipping-policy change or the checkout fix it prompts is.

Trigger C: guardrail alarms, daily 8am:

1. If recovery-message opt-outs exceed the agreed threshold for two consecutive days, notify the owner and automatically reduce to email-only until reviewed. A build that can throttle itself is worth more than one that needs watching.
2. If Abandonment Reason Given = Technical Problem or Payment Issue appears three or more times in 24 hours, alert immediately. That is an outage, not an abandonment pattern.
3. If any contact receives more than two automated messages in a day from this build, log it as a cap breach and notify. Caps that are not monitored are not caps.

Exit: none; these run continuously.

What is different afterwards

• Abandonment is answered, once, properly. Three touches across two channels over 48 hours, each one with a different job: remind, then re-offer, then remove the obstacle. Not four copies of the same email.
• The discount is a tool, not a reflex. No discount on touches one or two. A customer who was always going to come back is not paid to do so, and the customer base does not learn to wait.
• Frequency caps make the program survivable. Three touches per cart, one SMS per cart, four touches per contact per month, seven days between sequences. A serial abandoner gets one email ladder rather than a stream, and the sender reputation that every other campaign depends on stays intact.
• Replies get answered. Most cart recovery messages are broadcast from a no-reply address, which wastes the single most valuable response a hesitant buyer can give. Here a reply pauses the sequence and starts a conversation.
• You learn why carts are abandoned. Abandonment Reason Given, captured conversationally and by the one-question survey, turns a volume problem into a list of fixable causes. Shipping cost, delivery speed and payment failures are store problems; the recovery sequence is only the symptom management.
• Recovery is attributed honestly. Touch-level attribution plus a holdout group means the reported recovered revenue is defensible rather than a number that counts everyone who would have returned anyway.
• Post-purchase and recovery stop colliding. Recovery exits the moment an order lands, so nobody receives a 20% recovery code an hour after paying full price.

Metrics to watch

• Cart recovery rate: recovered carts as a share of abandoned carts with a contactable identity. Measure against that denominator, not all carts, or the number is meaningless.
• Recovered revenue, net of discount. Gross recovered revenue flatters the program. Subtract the discounts issued and the cost of the SMS before deciding it works.
• Incremental recovery against a holdout. Hold back 5 to 10 percent of abandoned carts from all messaging and compare purchase rates. This is the only honest measure of whether the sequence causes anything, and it is worth the revenue you give up to know.
• Recovery rate by touch: which of the three touches produces the orders. If touch three carries most of it, your customers have learned to wait for the code and the policy needs rethinking.
• Channel conversion: email versus SMS versus chat reply, per touch.
• Discount dependency: the share of recovered orders that used a code. Watch the trend, not the level.
• Unsubscribe and opt-out rate on recovery messages specifically, separate from broadcast. A rising number here is the early warning that the caps are too loose.
• Spam complaint rate and inbox placement. Cart recovery is high-volume; it will be the first thing to damage deliverability.
• Abandonment reason distribution: reviewed monthly, treated as a product and operations backlog rather than a marketing report.
• Serial abandoner share: what proportion of carts come from contacts using the cart as a wishlist. If it is high, a real wishlist feature will outperform any recovery sequence.

Decisions to make before building

• The discount policy, written down. Whether a code is offered at all, at which touch, to which segments, how long it lasts, and whether repeat customers are excluded. Decide this before the sequence is built, because every other decision depends on it and because a discount policy improvised during launch week becomes permanent.
• The high-value threshold that earns a human follow-up task.
• The abandonment window. 30 minutes is a sensible default. A considered-purchase store with long browsing sessions may want 60–90 minutes; a fast-moving consumer store may want 20.
• Whether SMS is in scope at all. If marketing consent for SMS is thin, run email-only at launch and add SMS once consent collection is in place. An SMS program built on weak consent is a liability, not an asset.
• Holdout size. 5 percent is usually enough to measure and small enough to afford. Agree it explicitly with the owner, because it means deliberately not messaging some abandoned carts.
• Who answers replies, and within what window. Inviting replies and then not answering them is worse than not inviting them.

Integrations

• Store platform: Shopify, WooCommerce, BigCommerce or similar. You need three things: a cart-updated webhook or equivalent, an order-created webhook, and a tokenized cart recovery URL. If the platform cannot produce a recovery URL, the build degrades to a reminder with a link to the category page, which performs very differently. Verify this before quoting the work.
• Customer and order history sync for Lifetime Order Count and Last Order Date. Without these, every customer is treated as a first-timer and the segmentation branches are dead weight.
• Live stock feed, so BO does not confirm availability on something that sold out two hours ago.
• Discount code generation: the store must be able to mint unique single-use codes with an expiry via API. Shared static codes end up on voucher-aggregator sites within days and get applied to orders that were never at risk.
• Payment processor (Stripe or the store's own) for the payment-failure signal, which is the most actionable abandonment reason there is.
• Email authentication: SPF, DKIM and DMARC on a dedicated sending subdomain, warmed before you turn on full volume.
• Analytics with UTM parameters distinct per touch and per channel, so attribution is measured rather than assumed.

Numbers and messaging registration

• Provision the store number first. Registration is the longest lead time in the build.
• A2P 10DLC registration is mandatory before automated SMS will deliver reliably in the US. Cart recovery is unambiguously marketing traffic, not transactional, however it is framed internally. Register it as such. A marketing sequence registered under a transactional use case is the most common cause of carrier filtering, and the failure mode is silent: messages are accepted and never delivered.
• Marketing consent for SMS must be explicit, affirmative and separate. Checking out does not constitute consent to marketing texts. Collect it with an unticked checkbox at checkout and at any pop-up capture, with clear wording about what will be sent and how often, and store the timestamp and the wording shown. In the US, SMS marketing without prior express written consent carries statutory damages per message under the TCPA, which makes this the highest-risk element of the entire build.
• Opt-out handling. STOP, UNSUBSCRIBE, QUIT, CANCEL and END apply sms-opted-out and halt every workflow instantly. Include the opt-out instruction in every marketing SMS, not just the first. Test with a real handset before launch, and test specifically that a scheduled future step honors a tag applied after it was scheduled.
• Quiet hours. Set the SMS window to 9am-8pm local to the recipient and the email window wider. Note that recovery triggers fire around the clock while shopping happens at night, so queueing rather than dropping is essential. A cart abandoned at 11:40pm must wait until morning for its SMS, not lose it.
• Frequency caps, enforced in the platform and monitored. Three touches per cart, one SMS per cart, four touches per contact per 30 days. Build the daily alarm in workflow 7 at the same time as the caps, because an unmonitored cap is a hope.

Data protection and compliance

• Cart contents are behavioral data. Under GDPR and similar regimes, tracking and messaging on the basis of browsing and cart behavior needs a lawful basis, disclosure in the privacy notice, and in many cases consent for the tracking cookie or pixel that makes the identification possible. Make sure the cookie banner and the recovery mechanism actually agree with each other.
• Identified-but-not-registered shoppers. Capturing an email at the first checkout step and then messaging about an abandoned cart is the specific case regulators look at most closely. Be clear in the checkout flow what that email will be used for.
• Retention. Agree how long abandoned cart records, recovery URLs and behavioral data are kept. Expired recovery tokens should be invalidated, not left live indefinitely.
• Product sensitivity. If any part of the catalog could reveal something personal about the buyer (health, medical or intimate categories among them) exclude those categories from SMS and from any message whose preview text names the product. A message naming an item on a lock screen that someone else can see is a real harm, not a theoretical one.
• Right to erasure and access must reach cart and recovery records, not just the contact row.
• BO discloses that it is an automated assistant when asked, and proactively where required.
• Discount and pricing claims in recovery messages must be accurate and the stated expiry must be honoured. A code described as expiring in 72 hours that still works a week later is a misleading-practice exposure.

None of this is legal advice. SMS marketing consent standards, cookie and tracking consent, behavioral-data lawful basis and retention all vary substantially by jurisdiction, and the penalties for getting SMS consent wrong in the US are significant. Confirm the specifics with the client's own counsel before launch, and keep a record of the consent wording and the policy decisions made.

Scoping

What this build costs depends on the store platform, whether recovery URLs and unique discount codes are available via API, and whether SMS is in scope. Book a call at bookings.appbo.io to scope it against the actual store.