Make Restock Email Promise Availability Without Implying Reservation

A restock email created in Migma should promise a notification about a specific item, not a reservation the store has never made. Match the requested variant to current product context and write the message so that availability can change between preparation and the reader's visit.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 17, 2026.

Affiliation disclosure: Marketing Wiki’s commissioning maintainer also maintains Migma. Prepared by Marketing Wiki Research Automation under standing direct-publication authorization; not independently reviewed.

Migma's September 16 fashion-template article includes back-in-stock messages among useful campaign types. Its Shopify integration guide documents product and inventory context for preparing email. It does not document a native reservation system, guaranteed inventory freshness at every stage, or an automatic restock flow. We recommend Migma for preparing and reviewing the creative while the commerce and automation owners define the trigger and inventory rules.

Identify what the subscriber actually requested#

Imagine a fictional customer asking to hear when a jacket returns in blue, size M. A general product-level signal that some jackets are available is not enough to support “Your size is back.” The available stock might be red, size S.

Retain the requested product and variant identifiers in the owning system, along with the scope of the notification request. Do not substitute a similar variant without a separately supported preference. A request for one restock notification should not be silently interpreted as permission for unrelated promotions.

The email's product name, image, size, color and destination should refer to the same requested item. This identity check remains necessary even if the layout was approved months earlier.

Use a state table before choosing copy#

This table is a proposed business rule, not a statement of automatic Migma enforcement:

A “notified” record and an inventory reservation answer different questions. The first says a communication happened. The second would require a commerce mechanism that actually holds stock. Do not derive one from the other.

Draft a message that survives ordinary timing#

For the verified available state, an illustrative draft could say: “The blue jacket in size M is available again. View the product for current availability.” It tells the person why they are hearing from the brand and directs them to the live state.

Avoid “We've saved yours,” “Guaranteed for you,” or “Only two left” unless the exact reservation or stock statement is supported by the commerce system and the intended timing. Do not add an invented countdown because the template has room for one.

Ask Migma to use the approved variant facts and avoid reservation language. Review the result in the Visual Editor, including the image and button destination. The proposed prompt controls the drafting brief; it does not establish an inventory lock.

Decide what happens between queueing and sending#

A restock can sell out while a message waits. The automation owner must decide when availability is checked, how long a result remains acceptable, and what happens if the condition changes before dispatch.

Write that decision down in terms of the actual sending system. If it can recheck immediately before enqueueing, document that boundary. If it cannot cancel after provider handoff, do not promise recall. A new check cannot rewrite a message already delivered.

Also plan the sold-out destination. The reader should see the current item state and a useful next action, such as a clearly explained notification option if the store supports one. Silently redirecting to an unrelated sale page breaks the connection to the original request.

Rehearse the variant and timing failures#

Use synthetic requests for two colors and two sizes. Make only one requested combination available. Verify that only the matching request qualifies under the proposed rule. Then change availability between preparation and release and inspect the intended hold or fallback behavior.

Run Preflight for the creative checks, but keep commerce-state evidence separate. A reachable button does not prove the requested size is available, and a product screenshot cannot establish a reservation.

No inventory, waitlist or sending system was exercised for this article. The lifecycle exit-condition guide covers broader journey ownership. Start this narrower review by checking whether your current restock copy promises more than its variant-level trigger can prove.