TL;DR: The post-purchase email that asks "how did we do?" frequently arrives before the product does. Across 1,133 high-scoring marketing automation threads, merchants describe wanting one specific behaviour their tools make awkward: hold the review request until the order is actually delivered, and drop it entirely for refunded or returned orders. The demand isn't more automation — it's automation that knows what happened to the parcel.
The evidence
PainHunt holds 1,133 posts scoring 10 or higher out of 15 about marketing automation, averaging 11.4/15 with a pain intensity of 7.4/10. The bulk of the operational detail comes from Discourse merchant communities, with the rest spread across Bluesky, Mastodon, app stores, and job boards — the last of which is its own signal, since shops hiring for this are describing work they couldn't configure their way out of.
Three requirements recur, and they're unusually concrete for this category.
Wait for delivery, not for a timer. Merchants describe wanting review requests delayed until after expected delivery rather than a fixed interval after purchase. The distinction matters because a fixed delay is a bet on shipping time — one that a slow carrier, a distant destination, or a delayed dispatch turns into a request for feedback about a package the customer hasn't seen.
Exclude the orders that shouldn't be asked. Refunded orders and repeat customers both get named. Asking someone who just returned an item to review it is worse than staying quiet, and treating a fifth-time buyer like a first-time one wastes the one message they'll open.
Don't flood people. Separately, merchants describe the difficulty of getting timing and segmentation right without overwhelming customers with repetitive win-back flows. Post-purchase and retention sequences are usually configured independently, so a customer can land in several at once.
Around this sits a cost complaint that shapes the opportunity: merchants report syncing customer and order data across email platforms, review apps, and the store itself while watching those subscriptions add up. The current answer to "I need delivery-aware timing" is a third tool and a set of manual connections.
Why now
Delivery data is available and underused. Carrier tracking and platform fulfillment webhooks have made the delivery event a queryable fact rather than an estimate. The information needed to trigger correctly exists; most flows still don't consume it.
Reviews carry more weight than they did. Product reviews now feed marketplace ranking, ad extensions, and increasingly what AI assistants repeat about a product. A badly timed request doesn't just fail to collect a review — it collects a worse one, and that has downstream cost it didn't have when reviews were decoration.
Stacked subscriptions are under scrutiny. With merchants actively counting what the email tool, the review app, and the sync layer cost together, a product that collapses one of those seams has an easier argument than it would have had when each was bought separately.
The wedge
The general build is a marketing automation platform. Nobody needs another one — the threads are from people who already have one.
- Make the delivery event the trigger. Subscribe to fulfillment and carrier status; send on delivered, not on
purchase + 7 days. This is the single behaviour merchants asked for by name, and it's the thing generic email tools model badly because their world starts at the contact, not the parcel. - Make exclusions durable, not point-in-time. Re-check order state at send, not at schedule. Refunds and returns land inside the waiting window; a rule evaluated once at the beginning will send the email anyway. This is unglamorous and it's most of the value.
- One frequency ledger across flows. A shared record of what this customer was already sent, so post-purchase, win-back, and review sequences can't stack. Merchants describe the overwhelm problem separately from the timing problem, but a single sending layer fixes both.
- Fit one platform properly. Deep Shopify fulfillment integration beats shallow support for five platforms. The buyers here are judging on whether the tool understands their order lifecycle, not on breadth.
Risks and honest caveats
- This is a feature that platforms may absorb. Delivery-aware timing is a plausible roadmap item for both commerce platforms and the larger review apps. The defensible version is either owning the whole post-purchase flow for one platform or being the layer that spans several tools — thin timing logic alone is not a moat.
- Delivery data is imperfect. Carrier statuses lie, mark delivered early, or never update for some services and regions. A product whose whole promise is "we wait for delivery" inherits every one of those failures and needs an honest fallback rather than a silent one.
- The incremental revenue is hard to attribute. Better-timed requests should lift review volume and quality, but proving that to a merchant takes a controlled comparison most small shops won't run. Pricing against a vague uplift is harder than pricing against a removed subscription.
- Compliance varies by market. The same threads raise regional rules for retention and advertising email. Any product that sends on a merchant's behalf across borders takes on that surface, and it isn't optional.
How to validate this further
The sharpest test is whether merchants describe this as a timing problem or a tooling problem — the two lead to different products. Use the PainHunt dashboard to filter marketing automation threads by intensity and read the ones that mention fulfillment or refunds specifically, since those separate people who want delivery-aware logic from people who want easier flow builders. Then check whether the exclusion rules or the delivery trigger is the thing they'd actually switch tools for, using idea validation.
Related reading: conditional logic that returns nothing, involuntary churn nobody measures.