What a Replenishment Email Flow Actually Is
A replenishment email flow is an automated message, or a short run of them, reminding a customer to reorder a consumable before they run out. It's timed to how long the product actually lasts, not to a generic promotional calendar. Klaviyo's own guidance for the flow triggers it off a Placed Order event, filtered to specific consumable products. Omnisend's pre-built version triggers off Order Fulfilled instead, on the reasoning that ship date is a better start point for a usage clock than the date the order was placed.
Both platforms scope the trigger to consumables rather than every order. Klaviyo's examples include food, beverages, skincare, vitamins, and supplements. A one-time purchase of a durable good has no use-up date, so it has no business being in this flow at all. Skip that filter and a customer who bought something they'll never need again still gets asked to reorder it, which lands as broken personalization, not a helpful nudge.
What the Numbers Show
Every number in this section comes from an ESP that sells the automation platform it's describing, so treat the figures as directionally real, not independently audited. Klaviyo's 2026 benchmark page, built from data across more than 183,000 of its own customers, reports that automated flows as a category (welcome series, abandoned cart, post-purchase, replenishment, and others combined) pull close to an 18x higher revenue per recipient than one-off campaigns, a 13x higher placed-order rate, and a 5.58 percent flow click rate against 1.69 percent for campaigns. Flows generate about 41 percent of total email revenue from just 5.3 percent of sends. None of that is broken out for replenishment specifically. It's what flows earn as a category, and Klaviyo doesn't publish an isolated replenishment number on that page.
The only replenishment-specific figure this research turned up comes from a single case study, not a benchmark. Klaviyo's own customer story for Balance Me, a UK skincare brand, states an 83 percent increase in repeat purchases from replenishment emails timed to each customer's likely repurchase interval. The case study gives no time period, baseline, or methodology, and Klaviyo is again the publisher.
The Three Layers Underneath a Working Flow
A working flow has three layers.
A Data layer holds the customer's order history and the products themselves: what they bought, when, and how much of it. A Decision layer starts the journey the moment an order comes in, works out a replenish estimate, roughly when this customer is expected to need more, based on the product's repurchase rate minus a lead-time buffer, and decides when to trigger a send. A Send layer carries that decision to the customer as a personalized replenishment reminder.
From there, the journey branches two ways. The customer reorders, and that purchase loops back to the Decision layer, restarting the cycle for whatever they just bought again. Or there's no response, and the customer exits into a separate win-back journey built for lapsed customers.
Order, estimate, decide, send, then reorder or hand off. What follows is what has to hold inside each layer for it to actually run that way instead of misfiring.
Who Actually Belongs in the Journey
The Decision layer's first job is deciding who qualifies, not just how to time the send.
- Only consumables enter. A Placed Order event filtered to specific, repeat-use products, not every order a customer places.
- Multi-item orders need a separate estimate per product, not one number for the whole order. Both Klaviyo and Omnisend build timing per product, Klaviyo filtering the trigger event to specific SKUs, Omnisend running its default delay per product (its own examples: 20 days for pet food, 45 for skincare); neither documents the multi-item case directly, but it follows from that per-product design that an order with a vitamin and a candle needs two different clocks, not one.
- A returned or refunded item should reset its own estimate. No ESP documents this directly, but it follows from how both handle purchases: if the order record shows the product came back, the customer no longer has it on hand, and reminding them to reorder something they sent back is just as broken as reminding them to reorder a lamp.
Setting the Estimate, and Letting It Learn
Klaviyo names two ways to calculate the replenish estimate, and neither one replaces the other. A fixed interval suits a product with no order history yet: Klaviyo's own example is a 30-day-supply vitamin getting a 20-to-25-day delay, and Omnisend defaults to a flat 3-week delay, customizable per product. A predictive approach leans on the customer's own "Average Time Between Orders," or an expected-next-order-date model, and sharpens as more of that customer's own order history piles up.
Neither method is a choice you make once and leave alone. Start every product on the fixed interval, since there's no history yet to predict from. Then move to the predictive model once a customer has reordered enough times that their own cadence beats the product's average as a predictor. A flow that never makes that switch is leaving the customer's own cadence unused.
Going Quiet the Moment They've Already Bought
Both ESPs treat mid-flow suppression as a default, not an optional add-on. Klaviyo's own guidance adds a flow filter so the reminder only reaches customers who haven't purchased the product since they entered the flow. Omnisend's default exit condition is "Placed order," which it says exists specifically to keep customers from getting irrelevant emails.
Suppression has to run continuously, as both ESPs build it, and it should also account for reorders through other channels and existing subscribe-and-save plans, though neither ESP documents that cross-channel and subscription piece directly; it follows from how each already treats a purchase as the trigger to stop sending. A customer who reordered through a different channel, or who's already on a subscribe-and-save plan for that same product, shouldn't see the reminder at all.
More Than One Message
General lifecycle-marketing practice, found consistently across secondary sources rather than ESP data, favors a three-touch pattern instead: an early reminder as the customer nears their predicted run-out date, a follow-up a few days later if nothing happened, and a final message near or after the predicted depletion date, often carrying a small incentive.
That same practice consensus recommends splitting channels by role instead of repeating the same message everywhere: email for the fuller reminder with related products, SMS for a shorter nudge to whoever didn't open the email, timed so the two don't land the same day. Omnisend's own automation supports multiple messages across email, SMS, and push, though it leaves the exact cadence to the merchant instead of prescribing one.
The same consensus treats a one-tap reorder link, one that recreates the customer's exact previous order, as the highest-leverage piece of content in the flow, on the reasoning that every extra step between "I should reorder" and "done" loses people along the way. The reminder moment also doubles as a natural point to offer subscribe-and-save, since a customer reordering the same product on a predictable cycle is close to ready for a subscription anyway. A cross-sell or a usage tip belongs in the message too, as a secondary line, never the opening one.
One more branch is worth building instead of skipping: a customer who opened or clicked the reminder but didn't buy isn't the same as one who ignored it outright. Routing both into "no response" throws away the difference between someone who needs a different message and someone who needs a longer wait.
The Wait Before Win-Back
"No response" can't be evaluated without a defined wait window, because without one there's nothing for an automation to check against. None of the sources reviewed names one universal number, since the right wait depends on the product, but every structural source treats a defined wait as a required parameter, not a detail left open for later.
That wait should run out after the full multi-touch sequence, not after the first reminder alone. Win-back flows are built for a different customer state entirely, lapsed or inactive, on a longer time horizon, and general practice recommends, once a win-back flow ends, a cooldown commonly cited at 30 to 90 days, plus an immediate exit if the customer buys mid-automation. Route someone into win-back after skipping one reminder and you've treated "didn't act on this one nudge" the same as "hasn't ordered in a long time." The two call for different messages entirely.
What's Worth Measuring
None of this earns much if nobody can tell whether the flow is actually driving the reorders, or whether those customers would've come back anyway. A holdout, a group deliberately left out of the flow so the rest has something real to compare against, answers that question honestly. Without one, you can still confirm the rules fire correctly, the reminder reaching the right customer at the right time, but not how many reorders the flow caused. Whether one is credible depends on how many customers are moving through the flow.
One last piece, general flow hygiene rather than a documented replenishment rule: a replenishment reminder should carry a frequency cap against a brand's other flows and campaigns, so it never stacks on top of a promotional send the same week. It avoids an obvious kind of noise.
This is what a replenishment flow looks like once every piece above is built in: a data layer, a decision layer, and a send layer that stay in sync with what a customer actually does, order after order.
