Merchant Center catalog operations workshop / 5 MIN READ
Make preorder and backorder dates describe the shipping promise
Create a release-state mapping that separates preorder, backorder, order acceptance and expected shipment.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-07
A future date can refer to announcement, launch, warehouse receipt or customer shipment. Availability fields need the event the platform defines, supported by an approved operational expectation.
What you will leave with: Create a release-state mapping that separates preorder, backorder, order acceptance and expected shipment.
Use this when
- A catalog accepts orders before launch or while existing stock is depleted.
- A supplier arrival date is copied directly into availability_date.
Not a lesson on choosing a waitlist versus preorder, accepting customer payment or guaranteeing a supplier delivery date.
Classify the offer state before attaching a date
Google distinguishes preorder for unreleased products from backorder for previously available products being ordered while temporarily unavailable. It requires availability_date for these states and describes it as the expected shipping date. Check current product-specific exceptions and formatting before implementation.
Record whether customers can actually place an order, whether the product has been released and whether fulfillment can support the intended promise. A notify-me form does not become a preorder merely because a launch date is known. Likewise, a returning best seller should not be labeled preorder simply because a new shipment is coming. Build the state mapping from those operational facts rather than campaign vocabulary.
Translate the operational milestone into a justified expectation
Ask the fulfillment owner what the supplied date means. A vessel arrival, warehouse receipt and quality-release date may all precede the point when customer orders can ship. Record the dependencies and the approved expectation that will be represented to shoppers. Avoid adding an arbitrary handling buffer without understanding the actual process.
If the date is estimated, keep that uncertainty visible in the internal record and use customer wording consistent with current platform guidance and consumer obligations. Do not create false precision by converting an uncertain month into a confident first-day promise. The owner should decide what estimate is supportable and when new evidence triggers revision. A feed format requiring a date does not manufacture operational certainty.
Keep date fields attached to their distinct events
Maintain separate fields for release date, expected stock receipt, expected shipment and any promotional price window. Do not reuse one date across all attributes merely because the integration provides a convenient timestamp. Give every field a semantic label and a source owner.
Test time-zone conversion and the selected variant. Two sizes may arrive in separate deliveries, so a parent-level date may be wrong for one child item. Check how the landing page displays the expectation and whether structured data agrees. Include an example where stock arrives before launch but cannot ship until release, and another where launch has already happened but replenishment is delayed. These distinguish preorder semantics from ordinary future inventory.
Reassess the state when evidence changes
Monitor the operational event that supports the date, not only the passage of time. If the supplier slips, route a review of the offer state, date and customer-facing information. Existing customer communications belong to their authorized service process; updating the feed alone does not notify people who already ordered.
When the product becomes genuinely available, verify the transition to the appropriate current state and remove obsolete future-date assumptions where the specification requires. Do not automatically declare stock available at midnight on the estimated day. Close the release record only after the source evidence and processed offer agree. The goal is a truthful status and supportable shipping expectation throughout the lifecycle, not a permanently populated date field.
Make the reasoning concrete.
A fictional board-game retailer advertises a new release and a restock of an older game. Both supplier files contain an expected warehouse-arrival date, and the export calls both products preorder.
Use the supplier date for every future offer
Opening: Copy warehouse arrival into availability_date and label both preorder.
Hypothesis: The file is easy to generate.
Risk: Release state and shipment timing are conflated.
Map state and milestone separately
Opening: Use release history and order acceptance to classify each item, then obtain an approved shipping expectation.
Hypothesis: The submitted date expresses the intended customer promise.
Risk: Variant arrivals and supplier changes require ongoing review.
The team distinguishes the unreleased game from the backordered existing title and verifies the shipping-date basis. It does not treat the forecast date itself as proof that stock has arrived.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
State
Is the product unreleased, temporarily unavailable or not accepting orders?
Milestone
What event does the source date actually describe?
Expectation
Who approves the expected customer-shipment date?
Variant
Does the expectation apply to this exact item?
Trigger
What new evidence requires a date or state change?
Watch for the wrong conclusion.
- Calling every future delivery a preorder.
- Copying warehouse receipt directly into a shipment promise.
- Automatically marking stock available when an estimate passes.
Your next action
Trace one future-availability date to its operational milestone and verify the correct offer state.
Sources & scope
Workflows, worksheets and fictional examples are original editorial analysis, not Google instructions or measured business results. Sources support only the specifically attributed platform facts. Platform controls and eligibility can change; verify current account guidance before implementation.
- Google Merchant Center: Availability →Primary platform documentation · Supports: Supports the preorder versus backorder distinction, order-acceptance context and availability-date requirement. Milestone mapping is original editorial analysis.
- Google Merchant Center: Availability date →Primary platform documentation · Supports: Supports availability_date as the expected shipping date, its date-time format and estimated-date guidance.