Send replenishment reminders for consumable products

01/The build

How to build it

1. 01

   Work out each consumable's real run-out date — and which products even qualify

   Needs a human

   This is the judgment call the whole flow rides on, and it's the one part software can't do for you. For each consumable, compute days-of-supply: pack size divided by the typical usage rate. A 30-serving tub used once a day is ~30 days; a 60-capsule bottle taken twice daily is also ~30; a 90-day skincare jar is ~90. Then subtract a lead buffer — shipping time plus a couple of days — so the reminder arrives a few days before they hit empty, when reordering is still a 'top it up,' not an 'I already ran out and bought elsewhere.' While you're here, decide which products are actually consumable: a reusable bottle, a one-time device, or a gift-only SKU should never trigger a 'running low?' email, and sending one there reads as a store that doesn't know what it sold you.

2. 02

   Encode the cadence so the order event carries it

   Runs itself

   Klaviyo flow delays are fixed per branch, so the consumption window has to live on the product, not in your head. The pragmatic native approach is cadence buckets: tag your consumables (or drop them into Shopify collections) like replen-30, replen-60, replen-90, grouping items whose run-out windows are close. That keeps the flow count sane while still tracking a daily supplement and a quarterly refill on different clocks. If a few hero SKUs deserve exact timing, give them a per-product metafield (e.g. consumption_days) instead — that's more precise but means more branches to maintain. Either way, this is the data the next step keys off, and it flows into Klaviyo through the native Shopify integration with the Placed Order line items.

3. 03

   Trigger a flow per bucket on the purchase, not on a date guess

   Runs itself

   Build one Klaviyo flow per cadence bucket, each triggered on the Placed Order metric with a trigger filter that the order contains a product in that bucket's tag or collection. Triggering on the actual purchase — not a blanket calendar send — is what makes the timing personal: the clock starts the day this customer bought this consumable, so two people who ordered the same tub three weeks apart get reminded three weeks apart. If you went the per-SKU metafield route in step two instead of buckets, this is one flow with a conditional split that routes each consumable to its own delay branch; the mechanics are the same, just consolidated.

4. 04

   Set the time delay to the run-out window, minus lead time

   Runs itself

   Add a time delay equal to that bucket's consumption window minus the lead buffer from step one — a 30-day bucket waits ~24-26 days, a 90-day bucket waits ~84. This single delay is the entire value of the build: too short and you're nagging someone who's still half-full and trained them to ignore you; too long and they already ran out, already reordered somewhere fast, and your email is a reminder that you were late. Start from the math, then tune it against the actual reorder rate (step eight) rather than guessing twice.

5. 05

   Guard the send: didn't already reorder, isn't a subscriber

   Runs itself

   Right before the email, add a conditional split: 'Placed Order [this consumable, or its collection] zero times since starting this flow.' Anyone who already restocked the same item drops out here — reminding a customer to buy something they bought last week is the version of this automation that makes you look broken. Then suppress active subscribers: if you run Recharge, someone with a live subscription to this product already has their next shipment scheduled, so a 'time to reorder' email teaches them to cancel and buy manually. Suppress on Recharge's active-subscriber signal (exposed through its Klaviyo integration), and let Klaviyo's built-in handling exclude unsubscribed and suppressed profiles for free.

6. 06

   Write the reminder around reordering, not a discount

   Runs itself

   The email should name the specific product they're about to run out of and make buying it again trivial: a one-click reorder link (a Shopify cart permalink, /cart/{variant_id}:{qty}, pre-loads the same item and quantity so it's one tap to checkout). Lead with convenience and the subscribe-and-save option as the upgrade — 'never run out, save 10% on every refill' turns a one-time reorder into recurring revenue and is the right place to spend margin. Hold back a blanket discount: a consumable customer is reordering because they need more, not because they need a coupon, and opening with one teaches people to let themselves run out to earn a deal. If you do offer an incentive, point it at the subscription, not the single reorder.

7. 07

   Handle quantity, bundles, and gifts honestly

   Runs itself

   Real orders break the clean math, so guard the obvious cases. Quantity scales supply: someone who bought two tubs lasts twice as long, so factor line-item quantity into the delay (a per-SKU exact-date build computes order_date + consumption_days × quantity − lead; with buckets, route multi-unit orders to a longer bucket). A sampler or trial size shouldn't be treated as a full restock window. And gift orders are a trap — if the buyer's address differs from the shipping address or the order is tagged a gift, don't email the purchaser 'you're running low,' because they aren't the one using it. When a single account-wide cadence is genuinely fine for your catalog (one consumable, or everything reorders on roughly the same clock), Klaviyo's native Predicted Date of Next Order property is the simpler honest path — use it and skip the per-bucket flows.

8. 08

   Measure the reorder rate and tune the window

   Runs itself

   The flow lives or dies on timing, and timing is invisible unless you watch it. Track the reorder rate of each bucket's flow — the share of recipients who place an order for that consumable within, say, a week of the reminder. If a bucket underperforms, it's almost always the window: customers are reordering before the email (delay too long, shorten it) or the email is landing after they've gone elsewhere (lead buffer too thin, send earlier). Tune one bucket at a time so you can read the effect, and revisit when you change pack sizes or formulas, since that quietly changes everyone's run-out date.

02/The stack

What it’s built on

Klaviyo

Owns the whole build: the Placed Order trigger per cadence bucket, the consumption-window time delay, the 'already reordered' and active-subscriber guards, the dynamic reorder email, and the frequency cap that keeps replenishment from colliding with your other flows. The Placed Order data, the Recharge subscriber signal, and the catalog behind the email all arrive through Klaviyo's native integrations, so there's no custom event to wire for the common case.Klaviyo's free tier is enough to build and test this, and you're almost certainly already running it. Its native Predicted Date of Next Order property handles the simple, single-cadence case on its own — if that's your catalog, use it and don't build the per-bucket version. This recipe is for multi-product stores where one account-level prediction smears a daily supplement and a quarterly refill into the same wrong date.

Shopify

Read through Klaviyo's native integration: the source of the Placed Order data that starts each customer's clock, the product tags or collections that encode the cadence buckets, the metafield that can carry an exact consumption window per SKU, and the cart permalink that powers the one-click reorder in the email. No custom Shopify code is needed for the bucket build — the integration surfaces the orders, products, and tags inside the flow.

03/Questions

Before you build