Replenishment and reorder timing

Use when a product runs out on a predictable cycle and your reminder arrives too late or not at all.

replenishment-reorder-timing.md

Download .md

You are an ecommerce retention strategist. You are working out when to send, not designing a loyalty programme.

Products, with pack size and typical consumption rate: {{PRODUCT_CYCLES}}
Repeat purchase data I hold, such as median days between orders: {{REPEAT_PURCHASE_DATA}}
Subscription or saved basket option available, or "none": {{SUBSCRIPTION_OPTION}}
Time from order to arrival: {{DELIVERY_TIME}}

Output a timing table: Product | Cycle length from {{PRODUCT_CYCLES}} | Evidence in {{REPEAT_PURCHASE_DATA}} or "assumed" | First send day after purchase | Second send day | Stop day | Reason for the timing.

Then, for the two products with the clearest cycle, write both sends: subject, preheader, body under 90 words, call to action.

Rules:
- Work each send date back from the day supply runs out, allowing for {{DELIVERY_TIME}}. A reminder that arrives on the empty day is late.
- Where {{REPEAT_PURCHASE_DATA}} disagrees with the cycle stated in {{PRODUCT_CYCLES}}, trust the purchase data and say so in the reason column.
- Mark any product with no repeat data as assumed, and name the figure to measure before it is automated.
- Mention {{SUBSCRIPTION_OPTION}} in the second send only, and not at all if it is none.
- State the rule that suppresses anyone who has reordered since the trigger.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{PRODUCT_CYCLES}}
{{REPEAT_PURCHASE_DATA}}
{{SUBSCRIPTION_OPTION}}
{{DELIVERY_TIME}}

Getting a better result

Median days between orders beats any estimate of how long a pack lasts. Pull it per product, not for the catalogue.
Vary timing by pack size where you sell several. One schedule for all variants misses at both ends.
Leading with a subscription in the first reminder suppresses the one-off reorder you would have had anyway.

Questions about this prompt

When is this better than a general campaign to past buyers?

When the product is consumed on a cycle you can estimate, such as coffee, filters or supplements. A broadcast reaches most people at the wrong moment. This works each send date back from when supply runs out, which only makes sense for products that genuinely run out.

What data do I need per product?

Pack sizes and consumption rates, whatever repeat purchase data you hold such as median days between orders, your time from order to arrival, and whether a subscription or saved basket exists. Pull the median per product, not for the catalogue, since one figure hides the fast and slow lines.

What does the timing table return?

Cycle length per product, whether it is evidenced or assumed, first and second send days, a stop day and the reasoning, then full copy for the two clearest cycles. The evidence column is the useful bit, because it shows which schedules you can safely automate now and which need measuring.

What is the mistake in reorder timing?

Automating a cycle marked assumed. Those are guesses until you measure the figure the output names, and a wrong cycle sends every reminder at the wrong moment indefinitely. The other is leading with the subscription in the first reminder, which suppresses the one-off reorder you would have had anyway.