Draft a considerate product review request in Migma, then check when the customer will actually be ready to answer it. In BigCommerce, a shipment status and a waiting period can trigger the request before a slow parcel arrives or before someone has used the product.
The email’s wording should match the evidence your store has. If you do not know that a parcel was delivered, do not say “Now that you have enjoyed your order.” If the item needs time to assemble or try, a delivery event alone may still be too early for a meaningful review.
BigCommerce’s official Managing Reviews documentation, checked October 18, 2026, says the built-in review email is sent a configured number of days after an order changes to Shipped or Completed. That is a specific timing rule, not proof of physical delivery.
Find the system that sends the request
Ask the commerce owner whether the store uses BigCommerce’s built-in request or a separate review app. Record the exact owner before editing creative. A new Migma design does not switch off an existing request, and two configured systems can create an experience nobody intended.
The official BigCommerce article places the Product Review Request template under Marketing → Transactional Emails. It describes additional timing settings under Settings → Miscellaneous → Email Settings. Have an authorized store owner verify the current account and storefront configuration rather than changing it based on an old screenshot.
If a separate app sends the request, review that app’s actual trigger and timing. Do not apply BigCommerce’s native rule to every integration or assume that an app sees carrier delivery events simply because it connects to the store.
Compare status time with customer readiness
Use a few recent, suitably minimized examples from the store. The goal is to understand the timing pattern, not to expose individual customer records to the creative team.
| Illustrative order | What the status proves | What still needs review |
|---|---|---|
| Small item dispatched quickly | The order reached the configured status | Arrival and time to try it |
| Made-to-order item | A store process changed its state | Whether manufacture or transit is still underway |
| Several parcels | Some order progress may be recorded | Which item the review request refers to |
| Returned or unresolved order | A past status may remain in history | Whether a request is appropriate now |
These are original review scenarios, not claims about a particular store’s results. Use the actual fulfillment and review-system behavior to decide which conditions the workflow can support.
Choose a delay with a reason
BigCommerce documents a minimum one-day delay and recommends allowing time for receipt and use. That does not mean its example timing is right for every product or shipping route. Ask the store owner to choose a delay that reflects the real experience and current capabilities.
A kitchen accessory and a flat-pack desk can require different time to use. International transit may differ from local delivery. If the native workflow cannot represent the distinction you need, document that limitation and decide with the responsible owner how to handle it.
Do not promise a delivery-aware automation unless your actual sending system has the necessary event and rule. A carefully chosen delay is still a delay. Its wording should remain honest when a parcel is late.
Brief Migma with the right level of certainty
Give Migma approved product context, the review destination, and what the trigger actually establishes. Ask for a simple request that identifies the relevant item and invites an honest account of the customer’s experience.
Where readiness is uncertain, considerate wording can acknowledge that the customer may need more time. Avoid a false delivery claim, pressure to leave a positive rating, or an unsupported suggestion that everyone already loves the product. The purpose is useful feedback, not an invented endorsement.
Make the action specific. Confirm that the link reaches the correct product’s review path and that the recipient can submit through the supported store experience. A generic storefront button can leave the customer searching for the item again.
Verify eligibility and the destination
The official BigCommerce guide explains that customer preferences and store settings can affect whether review emails are sent. It also describes restricting reviews to past customers. Have the store owner verify these settings for the intended recipient experience.
Do not assume that receiving any earlier order message means a customer should receive every later request. Keep the review workflow’s actual eligibility rules with the sending owner, and avoid changing preferences to force a test through.
Use the supported Migma export or file handoff your team has verified. This article does not claim a native BigCommerce connector. The destination owner must preserve required template behavior and inspect the final populated version.
Approve the complete request experience
Review the Migma draft, configured timing, populated email, and review destination together. Check the product identity, sender, action wording, readable layout, and what happens if the customer has not received or cannot use the item.
Save the template version and the reason for the chosen timing. Revisit them when fulfillment patterns, product mix, or review tooling changes. For your next revision, start with one representative product journey and make sure the customer has a fair opportunity to answer the question the email asks.
Frequently asked questions
Does BigCommerce’s Shipped status prove delivery?
No. The official built-in review-email rule uses a delay after Shipped or Completed. Review actual fulfillment evidence and avoid treating that status as physical delivery.
Where are the built-in review email settings?
The official guide identifies Product Review Request under Marketing → Transactional Emails and timing under Settings → Miscellaneous → Email Settings. Have the store owner verify the current storefront configuration.
Should all products use one review delay?
Choose timing based on the real delivery and product-use experience and the rules your sending system can support. Do not assume one example delay fits every product.
Does a new Migma review design replace the existing sender?
No. A design handoff does not change which system sends requests. Verify the destination template and sending ownership separately.