Your replenishment email timing is a guess, and guesses cost reorders

A thirty day delay is a schedule, not a strategy

Somebody buys a pouch of GenePro protein powder from your store. Thirty days later an email lands telling them it's probably running low and time to reorder. Except they finish a scoop most mornings and skip weekends. The pouch ran dry days earlier, and Amazon already took the replacement order.

Or the opposite. Smaller household, one scoop every other day, and the pouch is still half full when the email telling them they're nearly out turns up looking presumptuous. The flow did its job on schedule and missed the customer completely.

That's all a thirty, sixty, ninety day replenishment flow really is. A scheduling default wearing a strategy's clothes. Three delays looked tidy on the flow chart and tidy on a retention roadmap slide, and neither kind of tidy has anything to do with when the cupboard runs empty.

Every product empties at its own speed

None of this happens on purpose. Time delays are just the path of least resistance in a flow builder: pick a number, pick another, pick a third, done. Tidy and true are two different things, and only one of them earns reorders.

A daily single-serve supplement does genuinely run out around the month mark for the person who never misses a day. Almost nobody never misses a day. A serum used morning and night from a small bottle empties on a completely different clock to a pre-workout scooped a few times a week from a much bigger tub. Treat them the same and you're running one guess past everybody, hoping the average holds.

It won't, because averages hide the two groups the flow exists to catch. One is already out and searching Google. The other is nowhere near out and now thinks your emails are tone deaf.

Divide the pack by the serving before you touch the builder

Before you set a single delay you want three numbers per product. Serving size, meaning how much one use actually consumes. Pack size, the total the customer bought. And purchase frequency, meaning how often buyers of that specific product come back for more, pulled from your own order history and not assumed.

Divide pack size by serving size and you get a theoretical number of uses. Set that against how the product's used per day or per week and you get a theoretical runout date. Then comes the step everyone skips. Checking that date against what the order history says actually happens.

When the label maths and the median reorder gap disagree, trust the order history. It contains the missed days, the doubled scoops and the people who reorder early because they hate running out. The label can't see any of that. Serving maths is your starting hypothesis, for products that haven't got enough repeat data yet.

Send into the reorder window, not on one flat day

Do the maths properly and the answer lands somewhere awkward between the round numbers. The urge to round back to something tidy is strong. Resisting it is the whole point, because the unglamorous number nobody would pick by default is exactly the one that lines up with an empty cupboard.

Purchase data rarely gives you one exact date anyway. It gives you a cluster. If most repeat buyers reorder somewhere across a spread of days, that spread is the window the replenishment flow should send into. A first nudge meets the earliest reorderers, and a later follow-up catches the ones still deciding.

One flat send hitting everybody on the same day reads like a calendar reminder that happens to mention a product. The window also catches products used faster than the label implies, like a powder marketed as one scoop a day and drunk as a twice-daily shake. That one needs its own earlier window.

Build one flow that holds a different number per tier

A flow built on real consumption data has to do more than swap one delay value for another. A single-product store might get away with one number. A range of products means a range of runout speeds, and the structure's got to hold them all.

• Group products into consumption tiers from real serving-size and repeat-purchase data, instead of one flow per product or one for the whole catalogue
• Set the trigger delay per tier from the actual median reorder gap in that tier's order history
• Send an earlier, softer touch ahead of the fastest reorderers, framed as a heads-up and not a hard sell
• Send a second, more direct nudge near the tail of the cluster, for customers who haven't reordered by the point most others have
• Recheck the numbers every quarter, because seasonality, pricing and bundle changes all shift how fast product leaves the house

None of this is complicated to build. It's the same flow architecture most brands already have sitting in Klaviyo, with delay values pulled from a spreadsheet of real order data instead of whatever felt round at setup. The analysis is a one-off job per tier, and keeping it current is a quarterly check against fresh orders.

A flow timed off real behaviour starts telling on itself

Once the timing tracks real consumption, the flow doubles as a diagnostic. If a product's reorder gap keeps drifting later, somebody should be asking why. Customers topping up elsewhere between your emails, or using less per serving than you expected. A guessed send can never tell you that, because a guess just sits there.

That's the pattern behind the GenePro case study: a consumable brand where email carries the reorder, so the timing work is the revenue work. When a flow built on the real number stops matching reality, the mismatch is the signal worth chasing.

None of this applies to a brand that hasn't got enough repeat history to calculate a real median. There, pack and serving maths is the honest starting point. Not a finished answer, and the delay gets corrected the moment enough order data exists.