Repeat Purchase Reminder Template: Check Before You Send

A reorder reminder is useful only when the product can reasonably be replenished and the customer is still eligible to hear from the business. A fixed delay copied across every SKU can be early, late, irrelevant, or unsafe.

Use this template to expose the assumptions behind timing before any message is scheduled.

Copy and fill this reminder record

Customer and permission state:
Qualifying order ID/date/timezone:
Eligible product/SKU and quantity:
Observed reorder evidence:
Estimated use window and confidence:
Current product, stock and price source:

Trigger and evaluation date:
Exclusions and suppression:
Message purpose and CTA:
Human review required when:
Exit events:
No-response state:
Completion evidence:
QA sample and review date:

Estimated completion time: 25–35 minutes after order, catalog and permission fields are available. Copy the record into the workflow or campaign document, replace every field and assumption, then save or export the approved version with its source dates and owner.

Field guidance

• Limit eligibility to products that can genuinely be reordered; exclude one-time, expired, returned and unsuitable items.
• Use observed order history when available. If timing is only a category assumption, label its confidence and test it conservatively.
• Check current stock, price, variant and purchase route immediately before sending.
• Keep transactional order updates separate from promotional permission.
• Stop when the customer reorders, opts out, returns the item, opens a service issue or becomes ineligible.
• Set the trigger as an evaluation event, not an automatic send; store its date and rule version.
• List exclusions and suppression so a newer order, return or issue wins over the timer.
• Limit the message to verified prior-product context and one current CTA; never infer that the customer has run out.
• Name conditions requiring human review, including compatibility, safety, health, incentive and uncertain identity.
• Define the no-response state separately from opt-out and prevent time-only re-entry.
• Store eligibility, sources, message, delivery and final reason as completion evidence.
• Give QA a named owner, sample, error categories and review date.

Omnisend documents a replenishment automation that uses purchase data and product-specific delays. It is a useful mechanism example, not evidence that one timing rule fits every catalog or that reminders improve results. Review the vendor documentation.

Fictional filled example: replacement filters

Customer and permission state: C-204; permitted service-and-offer email
Qualifying order ID/date/timezone: O-771, 20 July 2026, ICT (UTC+7)
Eligible product/SKU and quantity: Fictional water-filter cartridge WF-2; quantity 2
Observed reorder evidence: This customer has two completed WF-2 reorders, 61 and 66 days apart
Estimated use window and confidence: Evaluate at day 55; medium confidence; never claim the item has run out
Current product, stock and price source: Approved catalog v12 checked 15 August 2026; WF-2 is available; current price is shown only on the verified product page and is not repeated in the message

Trigger and evaluation date: Day-55 evaluation after fulfilled order
Exclusions and suppression: Newer WF-2 order, return/refund, open product issue, out of stock, discontinued SKU, invalid contact, opt-out
Message purpose and CTA: Restore verified WF-2 context with “You previously ordered WF-2 filters. If you need another set, current details are at [verified link]. No action is needed if you still have enough.” CTA: view the current product record; no item is added automatically
Human review required when: Compatibility changed; a price, health or incentive claim is proposed; or identity match has low confidence
Exit events: Purchase, opt-out, service issue, return, contact failure, product ineligible or owner pause
No-response state: Close this reminder; reassess only after a new qualifying purchase
Completion evidence: Eligibility snapshot, message version, delivery state and final reason stored
QA sample and review date: Commerce owner reviews timing errors, complaints, stale links and false eligibility monthly

Every name, ID, product and date in this example is fictional. The 55-day evaluation is an illustrative decision from the fictional history, not a benchmark.

Quality checklist

• Eligibility is based on a reorderable SKU and completed order.
• The timing source and confidence are visible.
• Stock, price, compatibility and link are current.
• Purchase, return, service case and opt-out cancel the action.
• The message does not pretend the customer has run out.
• Sender and unsubscribe controls follow the applicable channel policy; Google's sender guidance is operational context, not legal approval.

Common mistakes

Mistake	Safer correction
One delay for every product	Define SKU/category eligibility and evidence separately.
Treating average timing as individual fact	State uncertainty and avoid “you are out” language.
Sending while the item is unavailable	Verify stock, variant, price and route before send.
Re-entering after every elapsed interval	Require a new qualifying purchase or approved event.

Frequently asked questions

Which products belong in a replenishment workflow?

Products with a legitimate repeat-use pattern, stable identity and current purchase route may qualify. Exclude items where repeat timing is unsafe, highly individual, unsupported or not expected.

Is a discount necessary?

No. A reminder can simply restore the verified product context. Any incentive needs current commercial approval, terms, expiry and eligibility.

Can AI predict the reorder date?

It may estimate a window from permitted history, but the record should expose the evidence, confidence and fallback. Do not present an estimate as observed consumption.

How should the workflow be evaluated?

Review false eligibility, premature/late timing, stale catalog facts, complaints, opt-outs, service conflicts and correctly attributed repeat orders. Do not infer causality from raw purchases alone.

What to do next

Copy the record into a document and fill the order and product fields first. If there is no product-level reorder signal, use a broader lifecycle use case rather than forcing this SKU reminder.

Evidence and limitations

This template does not define consent, medical or safety suitability, a universal interval, product availability, revenue impact, integration, or Easy AI capability.