A replenishment email is only worth sending if it arrives while the customer is deciding whether to reorder, and a flat 30-day timer misses that window for most of your catalog. Some products deplete in 18 days, some in 90, and a single interval treats them as if they were the same. The fix is not a better guess. It is deriving the send interval per product from the repurchase gaps already sitting in your order data, then sending early enough that the reorder lands before the customer runs out.
This is a depth problem, not a template problem. The mechanism is a median, a lead-time subtraction, and a handful of exclusion rules that stop the flow embarrassing you at scale.
Key takeaways
- Repurchase intervals vary widely by category, from roughly 28 days for supplements to 60 days or more for skincare, so one timer cannot fit a mixed catalog.
- Derive each product's interval from the median gap between consecutive orders of that SKU, not the mean, because a few outliers drag the average.
- Klaviyo's expected date of next order needs 500 customers with orders and 180 days of history, and falls back to how other customers behave when an individual has no clear pattern.
- Send the email at the interval minus your fulfillment lead time, so the reorder arrives before the current supply is gone.
- The flow breaks on gift orders, variant and bundle SKUs, and subscription overlap, so exclusions matter as much as timing.
When should a replenishment email actually send?
At the product's typical repurchase interval minus the time it takes you to fulfill, so the replacement arrives just before the customer runs dry. If a supplement lasts 30 days and you ship in 4, the reminder should land around day 22 to 24, not day 30. By day 30 the bottle is empty and the customer has either reordered elsewhere or lapsed.
Klaviyo frames the same logic in its own guidance, recommending you set the delay based on how long customers take to consume the product, sending a 30-day supply reminder around day 20 to 25. The number that matters is the consumption cycle of that specific item, and that number lives in your order history, not in a best-practice article.
Why is a flat 30-day reminder wrong for most of your catalog?
Because repurchase intervals differ by product and vertical by a factor of three or more, so a single timer is early for half the catalog and late for the other half. An analysis of 156,110 direct-to-consumer brands puts median repurchase intervals at roughly 28 to 35 days for supplements, 30 to 60 days for food and beverage, and 60 to 120 days for beauty and skincare. A 30-day timer sends a skincare reminder while the jar is two-thirds full and a coffee reminder a week after the bag ran out.
The interval, not the repeat rate, sets the cadence. Two brands with the same percentage of repeat buyers can need completely different timing if one sells a 20-day consumable and the other a 90-day one. Averaging across a mixed catalog produces a timer that fits nothing in it.
How do you derive the interval from your own data?
Pull every customer who bought a given product at least twice, measure the gap in days between their consecutive orders of that product, and take the median of those gaps. The median is deliberate. A handful of customers who reordered a year later, or twice in a week because the first arrived damaged, will drag a mean interval away from the typical case. The median holds steady.
Do this per SKU where volume allows, and per category where a SKU is too new or too thin to be reliable. A product needs a meaningful number of repeat purchasers before its own interval means anything, and until it clears that bar you borrow the interval from its category. Recompute quarterly, because reformulations, size changes, and new customer mixes move the curve.
The practical output is a table of intervals: this SKU sends at 21 days, that one at 58, this category default at 40. That table becomes the time delay on a Placed Order flow filtered by product, which is the trigger Klaviyo recommends for consumable replenishment, rather than one flow with one delay for everything.
Can you just trust Klaviyo's expected date of next order?
For a subset of customers, yes, but the metric leans on population behavior more often than operators assume. Klaviyo's predictive analytics require at least 500 customers with placed orders, 180 or more days of order history, and some customers with three or more orders before the account gets predictions at all. For an individual, the expected date is pattern-based only when that person's own orders show a pattern.
When they do not, Klaviyo states plainly that it makes a reasonable prediction based on how your other customers behave, and that predictions work best averaged over many customers and are not expected to be exact for any single individual. For a first-time or second-time buyer, that means the expected date is closer to your store average than to their real consumption rate.
Treat the predicted date as a useful input for customers with three or more orders and a per-SKU derived interval as the default for everyone else. If you are going to lean on a predictive field, understand where its cousin metric goes wrong first, because the same population-fallback behavior that skews predicted lifetime value skews the expected date. That failure mode shows up when predicted lifetime value is wrong about your store.
Which timing method fits which situation?
The right method depends on how much per-customer history you have and how mixed your catalog is. A single flat timer is the weakest option for anything beyond a one-product store.
| Method | How timing is set | Data needed | Where it breaks | Best for |
|---|---|---|---|---|
| Flat timer | One delay for all products | None | Wrong for any mixed catalog | Single-SKU stores |
| Per-category interval | Median gap for the category | Order history by category | Blurs fast and slow SKUs within a category | New or low-volume SKUs |
| Per-SKU derived interval | Median gap for that product | Enough repeat buyers per SKU | Thin data on new products | Established consumable catalogs |
| Klaviyo expected date | Predicted per-profile date | 500+ customers, 180+ days, 3+ orders per person | Falls back to population for light buyers | Customers with a real order pattern |
How far before depletion should it land?
Send the interval minus your fulfillment and shipping time, so the replacement is in hand before the current one is gone. If the SKU interval is 40 days and you deliver in 5, the reminder goes at day 35. The goal is continuity of supply, not a reminder that arrives after the lapse.
Do not send so early that you prompt a purchase the customer does not need yet, which erodes trust and can pull forward revenue you would have captured anyway. The window is narrow on purpose: after the product is likely half consumed, before it is likely empty. That is why the per-SKU interval matters more than any universal rule of thumb, because the safe window on a 20-day product is only a few days wide.
What breaks a replenishment flow at scale?
The timing math is the easy part. What generates complaints is the flow firing on orders that were never a personal reorder signal. Gift purchases are the clearest case: someone buys a product once for another person, and the flow starts nagging them to restock something they never used.
Variant and bundle SKUs distort the interval when a product sells as a single, a three-pack, and inside a starter kit, because each format depletes on a different clock and pooling them produces a meaningless median. Subscription customers are already on an auto-ship cadence, so a one-time replenishment flow that does not exclude active subscribers double-prompts them. Add returns and cancellations, which should reset or suppress the timer rather than count as a consumption cycle. Each of these is an exclusion condition, and a replenishment program is only as good as the orders it declines to act on.
What to watch and where the trade-offs sit
Watch reorder rate within the send window, unsubscribe rate on the flow, and the share of recipients who buy without the reminder, which tells you whether the timer is landing before or after the natural repurchase. A rising unsubscribe rate usually means the interval is too short and you are prompting people who already reordered or never intended to.
The core trade-off is precision against coverage. Per-SKU intervals are the most accurate but need volume, and chasing SKU-level precision on a long tail of low-selling products buys little. Reserve derived per-SKU timing for the consumables that drive repeat revenue, use category defaults for the tail, and layer the predicted date only where a customer has enough history to earn it. Timing built from your own curve beats any borrowed benchmark, because your customers, not the vertical average, decide when they run out.