Write cart reminders with accurate product information, honest offers, permission checks, and a fresh purchase-status check before each send.
An abandoned cart email asks someone to return to a purchase they did not complete. Treat it as marketing, not as a receipt. The customer may have changed their mind, found an answer elsewhere, or simply run out of time.
A useful reminder makes returning easy. It does not need an invented countdown or a claim that the item is almost gone.
Confirm that you have permission to send marketing to the address. Check whether the cart still exists, the items remain available, and the customer has already purchased. Apply unsubscribe and suppression rules.
Use the cart's actual products, prices, and destination link. If an offer changed since the cart was created, make the current terms clear. Do not promise that a price or item is reserved unless the store really reserves it.
The transactional email guide explains why an incomplete purchase is different from an order confirmation.
In the US, CAN-SPAM classifies an email by its primary purpose, and the FTC's CAN-SPAM compliance guide explains how that test works. A reminder about an order the customer has not placed exists to promote the sale. Give it the same unsubscribe link and postal address as your other marketing email.
A reminder is only as accurate as the data behind it. Before writing copy, confirm that your store sends these fields for each abandoned cart:
The event id lets your integration recognize a duplicate when a request is retried. Build it from values that stay the same across retries of one reminder: the cart, the abandonment, and the step. A timestamp generated at send time changes on every retry, so it cannot catch duplicates. If you fire the event through Brew's API, send that id in the Idempotency-Key header. A retry with the same key and body returns the original result instead of starting a second run. The key stays tied to that stored run for much longer than a day, so a customer who abandons the same cart again needs a new id.
Here is an illustrative draft, with editorial placeholders rather than live merge tags:
Subject: Your cart at [store name]
You left [product name] in your cart. You can review the items and current total before deciding whether to order.
[Return to cart]
Questions about fit or delivery? Reply and our team can help.
Use the help line only if replies reach a team that can answer. Replace each placeholder with verified data through your platform's supported fields. Test the fallback when a product image or name is missing.
If you send another message, give it a reason to exist. Answer a common product question or explain a genuine policy. A discount is a business decision, not a mandatory second step.
Many stores start from delays like the ones below. Treat them as a common convention to test against your own orders. They are not a benchmark, and nothing here shows that these timings recover more carts than any others.
| Common starting delay | What it can do | |
|---|---|---|
| First reminder | 1 to 2 hours after abandonment | Show the cart while the visit is still recent |
| Second email | Around 24 hours | Answer a common question about fit, delivery, or returns |
| Third email | 48 to 72 hours | Remind once more, or state a real offer if you decided to make one |
| Optional final email | 5 to 7 days | Help with a considered purchase, if the cart is still valid |
You do not have to send all four. A single reminder may be enough for an inexpensive item. Each later email needs its own reason to exist, and the purchase-status check described below should run before every one of them.
Use an approved customer quote with its real attribution and permission. If the draft needs a testimonial but none is available, leave an internal placeholder and remove it before sending. Never turn a generated name and five stars into apparent customer evidence.
Likewise, a deadline must correspond to an actual offer expiry. An inventory warning must reflect current stock. A reminder that misstates either fact may get a click while making the store less trustworthy.
A common mistake is a sequence with no exit conditions. The customer buys, then receives two more reminders about a cart they already paid for. Stop the sequence as soon as any of these is true:
Write these down before you build the flow, and test each one with a test cart. The next section explains where the check has to happen when Brew sends the reminders.
In Brew, event payload fields retain the original cart details after a delay. Conditions on contact.<name> can read current Brew contact fields, but they do not fetch the store's cart, order, or inventory records.
When a reminder is due, have the store application check current eligibility. If the customer still has an eligible cart and permission to receive marketing, fire a fresh reminder event with the current cart details. If they bought, do not fire it. Use a stable event identifier to protect against retries in the sending integration.
Do not assume a prompt such as "stop after purchase" creates a live connection to the store's current data. Verify the actual event and integration workflow you have configured.
Define the attribution window and how you handle orders that would have happened anyway. Track discount cost, returns, unsubscribes, and complaints alongside revenue. A holdout can help estimate incremental recovery when you have enough volume.
There is no recovery percentage this sequence can promise. Start with a relevant reminder, verify the state checks, and improve it from your own results. For the wider measurement model, use the ROI guide.
