Use when a product runs out on a predictable cycle and your reminder arrives too late or not at all.
replenishment-reorder-timing.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.
Sustituye cada hueco por tus propios datos. Cuanto más concreto seas, menos se inventa el modelo.