For a physical product, send the review request after delivery when Shopify receives dependable delivery updates. If those updates are incomplete or late, trigger after fulfillment and add a buffer based on your actual shipping time. Then add however long the customer needs to use the product.
That order matters. Choosing “seven days” or “fourteen days” before checking the event that starts the clock is how a reasonable schedule still sends an unreasonable email.
The short answer: choose the most reliable event closest to product use
| Store condition | Best starting event | How to set the delay |
|---|---|---|
| Physical products with dependable delivered events | Delivery | Add the minimum time needed to inspect or use the product |
| Physical products with incomplete or delayed delivery events | Fulfillment | Add a measured shipping buffer, then the product-use window |
| Digital products or genuinely same-day experiences | Purchase | Add only the time needed to experience the product |
| Mixed carriers, countries, preorders, or fulfillment methods | Depends by cohort | Separate materially different lanes where the stack permits it; otherwise use a conservative supported fallback |
Delivery is not automatically the winner. It is a better signal only when the signal arrives reliably. A fulfillment-based request that sends at a measured time is safer than a delivery-based request that leaves a meaningful share of orders waiting forever.
Fulfilled and delivered are different Shopify events
Shopify defines fulfillment time as the period from order placement until the business fulfills the order. For a shippable order, the order is considered fulfilled when the business gives the shipment to the carrier. The customer may not receive it for several more days. Shopify’s fulfillment-time documentation makes that boundary explicit.
Delivery status is closer to the moment the customer receives the package. But it depends on Shopify receiving an update from a supported carrier or tracking app. A shipment without usable tracking can remain “On its way” until it is manually marked as delivered. Shopify’s order-status guidance explains how those updates reach the order status page.
This creates the central trade-off:
- Fulfillment is earlier and usually easier to observe. It needs enough buffer to cover transit.
- Delivery is closer to receipt. It needs complete, timely shipment events.
- Purchase is independent of shipping. It generally suits products that can be experienced immediately.
The trigger starts the clock. It does not decide the whole schedule.
Test delivery-event reliability before selecting delivery
Do not start in the review app. Start with a representative set of recent shipped orders and ask whether the delivered event is trustworthy enough to control customer communication.
Use the Trigger Reliability Matrix below for each materially different shipping lane. A lane might be domestic standard shipping, international tracked shipping, local delivery, a 3PL, or a dropshipping supplier.
| Check | Calculation or evidence | What it changes |
|---|---|---|
| Delivery-event coverage | Orders with a delivered timestamp ÷ eligible shipped orders | Low coverage favors fulfillment plus a buffer |
| Missing-event rate | Orders without a delivered timestamp by your fallback cutoff ÷ eligible shipped orders | Defines the need and urgency of fallback timing |
| Event latency | Time between credible receipt evidence and the delivered timestamp, when comparable evidence exists | Late events can make a delivery trigger unnecessarily slow |
| Fulfillment-to-delivery time | Delivery timestamp minus fulfillment timestamp, grouped by lane | Supplies the transit buffer for fulfillment timing |
| Split-shipment behavior | Orders fulfilled or delivered in multiple parts ÷ eligible orders | Reveals whether a request could arrive before the full experience |
| Product-use window | Minimum time required for a customer to form a useful opinion | Adds delay after receipt, regardless of trigger |
There is no universal coverage percentage that makes delivery “good enough.” Set the acceptable missing-event and early-send risk before looking at the result. A store shipping tracked parcels through a stable domestic carrier can use a stricter standard than a store with several international suppliers and patchy carrier updates.
If the sample is small, use every recent eligible order and label the finding directional. Do not turn a handful of clean deliveries into a permanent operating assumption.
A practical decision rule
Choose delivery when:
- most eligible orders receive a delivered event within an acceptable time;
- missing events have a tested fallback;
- the delivery event is available in the review workflow you intend to use;
- split shipments will not prompt customers to review products they have not received.
Choose fulfillment when:
- delivery events are absent, delayed, or inconsistent across important lanes;
- a fulfillment timestamp is consistently available;
- you can calculate a transit buffer from your own order history;
- the risk of a missed request is greater than the remaining early-send risk after buffering.
Choose purchase when the experience does not depend on shipping or fulfillment, such as a digital product or a same-day service. Loox also identifies digital products and same-day delivery as use cases for purchase-based timing in its current review-request timing guide.
Calculate the delay after choosing the trigger
The best delay has two components:
- Time until the customer receives the product.
- Time until the customer can form a useful opinion.
For a delivery trigger, the first component is already represented by the event:
Delivery-based delay = minimum product-use window
For a fulfillment trigger, add a transit allowance:
Fulfillment-based delay = selected fulfillment-to-delivery percentile + minimum product-use window
Use a percentile that matches the early-send risk your store is willing to accept. The median may be too aggressive if a large minority of customers receive orders later. A high percentile can be too slow if tracking data includes unusual exceptions. Calculate the distribution by lane, inspect the outliers, and document the choice rather than copying a generic number.
Suppose a merchant’s domestic lane has a selected fulfillment-to-delivery value of four days, and the product normally needs three days of use. The starting fulfillment delay would be seven days. That is an example of the method, not a benchmark for another store.
The product-use window also varies:
- A phone case can be inspected almost immediately.
- Apparel may need to be tried on and washed.
- Skincare or supplements may require repeated use before a review is informative.
- A gift may not be opened by the buyer at all.
Research published in the Journal of Marketing supports avoiding a one-size-fits-all rule. Two field experiments found that requesting reviews as soon as possible was not always the best strategy and that the product experience affected appropriate timing. The study does not provide a universal Shopify interval, but it supports testing timing rather than treating “sooner” as automatically better. See Ask for Reviews at the Right Time: Evidence from Two Field Experiments.
Configure Loox without creating a silent failure
Loox currently documents review-request timing from 1 to 70 days after purchase, fulfillment, or delivery. It also says setting changes apply immediately to unscheduled orders, so changing a live account is an operational change—not just a preference update. Review Request Email Timing is the current setup reference.
For delivery-based timing, Loox relies on shipment-status updates reaching Shopify or on a delivered webhook through its AfterShip integration. Its setup guide warns that when shipment_status is not tracked, Shopify does not notify Loox that the package was delivered and the request will not send. The same guide documents fallback timing for orders whose delivery status is not reported. See Scheduling Emails According to Delivery Timing.
Before enabling delivery timing:
- Check the Delivery Status column for each important carrier and fulfillment lane.
- Confirm that recent delivered orders actually reach a delivered state.
- Set fallback timing before relying on that state.
- Inspect preorders, partial shipments, local delivery, manual fulfillment, and 3PL orders separately.
- Record the change date so old and new schedules are not mixed in analysis.
There are two additional Loox behaviors to include in the plan:
- Loox says it sends one request per order for products fulfilled together. Products fulfilled on different days can generate separate requests tied to those fulfillment dates.
- Its current timing documentation says separate domestic and international schedules support purchase and fulfillment triggers, but not delivery. A global merchant should verify the current interface before assuming every lane can use a different delivery schedule.
Treat the current plan boundary as unverified
Loox’s delivery-setup article still refers to “Scale plan and up,” while its current pricing page uses Beginner, Convert, and Unlimited, and its quota documentation describes Scale as a legacy plan. That naming is inconsistent.
Do not choose or upgrade a plan based on the old label. Confirm that Delivery based scheduling is available in the current Loox plan screen for the store before making the trigger decision. The capability and the commercial entitlement are separate facts.
Timing does not solve email ownership or consent
Inventory every system that can ask for a review. Shopify Shop can send its own review notification after delivery, and Shopify currently lets merchants select an interval from 1 to 180 days. If Shop, Loox, or another lifecycle platform sends independently, a perfectly timed Loox request can still become an unwanted duplicate. Review the current Shop review notification settings.
Loox also distinguishes promotional from transactional review-request emails and manages opt-outs within its own sending system. Integrations can behave differently. Use the applicable consent settings and obtain legal guidance for the markets you serve; changing the trigger is not a compliance strategy. Loox documents its current behavior in Emails: Unsubscribes and Compliance.
Run a timing test without changing five things at once
A timing change is useful only when its result can be interpreted. Freeze email copy, incentive, reminder count, sender identity, and major product mix while evaluating the trigger.
Use this worksheet for the baseline and test periods:
| Metric | Definition | Why it matters |
|---|---|---|
| Eligible orders | Orders that should enter the request workflow | Denominator for event coverage and scheduling |
| Delivery-event coverage | Orders with delivered timestamp ÷ eligible shipped orders | Shows whether delivery is operationally usable |
| Requests scheduled | Orders with a scheduled request ÷ eligible orders | Exposes missing triggers or scheduling gaps |
| Requests delivered | Successfully delivered request emails | Denominator for response and complaint measures |
| Premature-send rate | Requests sent before the comparable delivered event ÷ requests with comparable delivery evidence | Measures the problem the change is intended to reduce |
| Response rate | Submitted reviews ÷ delivered requests | Measures request effectiveness without claiming revenue |
| Media-review rate | Reviews containing photo or video ÷ submitted reviews | Shows whether timing affects the desired review format |
| Timing-related complaint rate | “Not arrived” or timing complaints ÷ delivered requests | Captures customer friction hidden by response rate |
| Unsubscribe signal | Unsubscribes associated with the request cohort ÷ delivered requests | Monitors list and trust cost |
Use equal observation windows and let the entire request-and-response window close before comparing cohorts. If your stack supports randomized assignment, use it. If it does not, a sequential before-and-after test can still guide operations, but it is directional: seasonality, carrier mix, inventory, and product mix can explain the difference.
Predeclare rollback conditions. Examples include a material increase in missing scheduled requests, timing-related complaints, or unsubscribes relative to the store’s own tolerance. Do not wait for a conversion-rate story to decide whether the workflow is failing at its first step.
Loox’s request dashboard can show scheduled, sent, canceled, and review-received statuses. These are useful operational checks, not proof that a timing change caused more revenue. See Tracking Loox Emails.
When Loox is the right implementation—and when it is not
Loox is a credible fit when the merchant:
- wants native review-request automation tied to Shopify order events;
- can supply dependable delivery status or calculate a fulfillment buffer;
- wants photo and video review collection in the same review workflow;
- is willing to monitor fallback, split shipments, consent, and duplicate sends.
It is not the automatic answer when:
- another review or lifecycle platform must remain the sending owner;
- important carriers do not produce dependable delivered events;
- the current Loox plan does not expose the required trigger;
- the store needs segmentation or experimentation the documented setup cannot provide;
- the merchant wants a universal timing benchmark instead of using store data.
If you still need to decide whether the complete product fits your stack, read the ShopSideK Loox review before installing it.
If the fit checks above pass, Loox gives you a direct way to implement the delivery-or-fulfillment decision and measure the resulting request workflow.
>> Start Your 30-Day Free Trial with Loox
Frequently asked questions
Is delivery always better than fulfillment for review requests?
No. Delivery is closer to receipt, but it is useful only when delivered events are complete and timely. Fulfillment plus a measured transit buffer is safer when delivery events are missing or unreliable.
How long after delivery should a Shopify store ask for a review?
Use the minimum time a customer needs to form a useful opinion about the product. Do not copy one interval across immediate-use and repeated-use products. Test equivalent cohorts and watch response, media-review, complaint, and unsubscribe signals.
What if Shopify does not show a delivered status?
Check whether the carrier or tracking app sends shipment-status updates to Shopify. If the gap cannot be fixed, use fulfillment plus a buffer derived from observed transit time, or configure the documented fallback in the review workflow.
Should a dropshipping store use fulfillment timing?
Often, but not automatically. A dropshipping merchant should measure each supplier and shipping lane. Fulfillment timing can work when the supplier reliably marks fulfillment and the merchant adds a realistic transit buffer. Delivery timing is better only when downstream tracking is dependable.
Can Loox send review requests after delivery?
Yes, Loox currently documents delivery-based scheduling through Shopify delivery tracking or an AfterShip delivered webhook. Verify shipment-status coverage, fallback timing, and availability in the store’s current Loox plan before enabling it.
What if Shopify Shop also sends a review request?
Treat Shop as a separate request owner. Inventory its notification timing alongside Loox and any email platform, then remove or suppress overlaps so the customer does not receive several requests for the same purchase.
Make the event reliable before optimizing the day
The practical sequence is simple:
- Measure whether delivered events can be trusted.
- Choose delivery or fulfillment from that evidence.
- Add the product-use window.
- Configure fallback and suppress overlapping request owners.
- Run the test long enough for responses to mature.
That produces a timing decision the store can defend—and change—without pretending one trigger or one number of days is right for every order.



