Replenishment Flows: Timing the Refill to Real Consumption
Most replenishment programs are a calendar reminder wearing the costume of a system. You pick 30 days, or 45, or whatever the agency template suggested, and you fire the same “time to restock” email to everyone who bought. It converts a little, so it stays. But a flat timer treats a 14-day product and a 90-day product identically, and it treats a heavy user and a light user identically. That mismatch quietly bleeds the highest-margin revenue an owned channel can produce.
This is a how-to for fixing the timing. The goal is a replenishment email flow that fires against each SKU’s real consumption cycle — not a guessed interval — so the nudge lands when the customer is genuinely running low, not weeks early (ignored) or weeks late (already rebought elsewhere, or churned).
For the adjacent growth decisions, compare Why Your DTC Email Flows Aren’t Hitting the Inbox and then use Subscription vs Replenishment: When Each Model Actually Fits to pressure-test the operating plan.
Why the refill is your best revenue, and why timing is the whole game
Replenishment revenue is structurally cheaper than anything you buy. You already paid the acquisition cost on the first order; every reorder you trigger through an owned channel carries almost no incremental acquisition load. That’s why a well-timed reorder nudge can show a return profile several multiples better than cold prospecting — treat that as a reasonable planning expectation, not a assurance, because it depends entirely on your repeat-purchase rate and margin.
The catch: that economic advantage only exists if the message arrives inside a narrow window. Send too early and you’re asking someone to buy a thing they can still see on their shelf — low intent, and you’ve burned the trigger. Send too late and the customer has either run out and improvised a substitute, or worse, your paid retargeting has already re-bought them at full cost. A mistimed reorder isn’t just a missed open. It’s margin you handed back to your own acquisition budget.
Start with the consumption unit, not the calendar
The fix begins by refusing to think in days. Think in units of consumption. For each replenishment SKU, ask: how much does one purchase contain, and how fast does a typical customer use it?
- A serum with 30 doses used once daily empties in roughly a month.
- The same serum used twice daily empties in two weeks.
- A 90-count supplement at two-per-day empties in 45 days; at one-per-day, 90.
- A bag of pet food sizes its cycle to the animal’s weight, not the buyer.
The point is that the cycle is a property of the product and its usage, not of your sending schedule. A single flat timer is wrong for almost every SKU you sell. The work is to estimate the cycle per SKU — and ideally per variant size — then let the flow inherit that number.
Build the cycle from your own reorder data
You don’t have to guess. Your order history already contains the answer for any SKU bought more than once. The cleanest signal is the observed inter-purchase interval: for customers who reordered the same SKU, take the gap between consecutive purchases and look at the distribution.
Use the median, not the mean — a handful of stockpilers and lapsed-then-returned buyers will drag an average around. A simple working table per SKU:
| Signal | What it tells you | How to use it |
|---|---|---|
| Median reorder gap | The “typical empty” point | Anchor your send window here |
| 25th percentile | Heavy users / multi-unit households | Earlier branch of the flow |
| 75th percentile | Light users / single users | Later branch, or suppress early |
| Pack size on order | Doubles or halves the cycle | Multiply the base interval |
For a brand-new SKU with no reorder history, estimate the cycle from the physical math (doses per unit ÷ expected daily usage), label it as provisional, and let real data overwrite it as orders accumulate. The estimate gets sharper every week you run.
Time the nudge to land before empty, not after
Once you have a per-SKU cycle, place the send before the projected run-out, not on it. People reorder when they notice they’re low — the last few doses — not when they hit zero. A practical pattern:
- Lead nudge at roughly 80–85% of the estimated cycle. Framed as convenience: “you’re probably getting low.” This is the money send.
- At-empty nudge near the projected run-out for anyone who didn’t act, with a slightly stronger reason to act now (bundle, replenishment perk, or a one-tap reorder).
- Lapse catch past the cycle, which quietly hands off to win-back logic — because past a point this stops being replenishment and becomes reactivation, and the message should change accordingly.
Keep the lead time proportional to cycle length. A 14-day product needs a 2–3 day lead; a 90-day product can lead by a week or more without feeling early. A fixed “send 3 days before” rule breaks at the extremes the same way a flat 30-day timer does.
Segment by consumption behavior, not RFM alone
Classic recency-frequency-monetary segmentation tells you who is valuable. It does not tell you when someone is empty. For replenishment you want a behavioral overlay:
- Quantity per order — someone who buys three units per order is on a 3× cycle. Don’t nudge them on the single-unit clock.
- Multi-SKU households — if one customer reorders several consumable SKUs, stagger the triggers or consolidate into one well-timed basket reminder rather than three separate pings in a week.
- Cycle drift — heavy users compress their interval over time; light users stretch it. The flow should read each customer’s own observed gap and bias toward it, not just the SKU median.
This is where a flat program and a real one diverge most. The flat version asks “has it been 30 days?” The real version asks “given what this person bought, in what quantity, and how fast they’ve historically come back — are they low right now?”
Make the flow self-correcting
A replenishment system that never updates its intervals decays. Consumption changes with season, with product reformulation, with usage habits. Build in a feedback loop:
- Recompute SKU cycles on a rolling window so recent behavior outweighs year-old data.
- Watch the reorder-after-send lag: if most conversions land days after your nudge, you’re sending early — pull the window in. If a chunk of reorders happen before your nudge ever fires, you’re sending late and losing them to memory or to retargeting.
- Track suppression health. The flow should never nudge someone who already reordered through another path; nothing erodes trust faster than “restock now” landing the day after they restocked.
This is also where an operator’s intelligence layer earns its place. A tool like Bach can read the consumption cadence sitting in your order data, surface which SKUs have enough reorder signal to model confidently versus which are still guessing, and flag where your current timer is misaligned with observed behavior — so you tune the window deliberately instead of by feel. Bach surfaces and recommends; it doesn’t change anything until you approve.
Measure it as incremental, not attributed
One honest caution: replenishment flows attribute beautifully because they fire at high-intent moments — which means they happily take credit for reorders that would have happened anyway. The number that matters is incremental lift. Periodically hold out a small, random slice of the eligible audience from the flow and compare reorder rate and timing against the treated group. If the treated group reorders meaningfully more, or meaningfully sooner, the flow is earning its keep. If not, your timer is just stapling itself to organic behavior.
The takeaway
Stop sending refill reminders on a calendar. Pull the median reorder interval per SKU from your own order history, adjust it for pack size and per-customer usage, and place the lead nudge at roughly 80–85% of that cycle — before empty, never after. Let it recompute on rolling data, suppress anyone who already rebought, and prove it with a holdout. Done this way, the replenishment email flow stops being a guess and becomes the least expensive, highest-contribution revenue you have — because you’re meeting demand at the exact moment it reappears, instead of hoping a fixed number lines up with real life.