The Best Time to Ask for a Review (and Why)

The best time to ask for a review is the moment the customer can answer, not a set number of days after dispatch. How to find that moment in your data.

The Brandfeel Team
Published: September 7, 2026Updated: September 11, 2026
An overhead flat-lay on pale grey paper of four printed dispatch cards laid in a row, each stamped with one stage word, with a small ruled ledger strip beside them
Quick Answer

The best time to ask for a review is shortly after the customer has used the product in the way that forms an opinion, which is a different moment for every category and is almost never a fixed number of days after dispatch. You can find that moment in data you already hold: first support contacts and return initiations both cluster around the point customers actually engage with a product. Set the request a few days after that cluster. Timing changes response rate and review quality at the same time, and quality is the half that keeps paying.

Key Takeaways
  • Dispatch is a logistics event and carries no information about whether the customer can answer yet.
  • Your support ticket curve and returns curve already mark the opinion formation point, per category.
  • There is no universal day count, and any figure quoted without a category attached is guesswork.
  • A second ask works when it changes the question, not when it repeats the first one louder.
  • Good timing raises review quality as well as volume, and quality is what helps the next buyer decide.

The best time to ask for a review is the moment the customer can answer the question, and most stores are not asking then. They are asking a fixed number of days after a parcel was marked delivered, because that is the trigger the platform offered, and it is a trigger built from warehouse events rather than customer ones. Last updated: September 2026.

Omniconvert has measured how stores collect customer feedback across the CROBenchmark dataset of 7,000+ websites in 15+ industries, against 248+ audit criteria, over 13 years in eCommerce. The stores with strong, specific review coverage are rarely the ones sending the most requests or the most reminders. They are the ones asking at a moment their customer has something to say, and that moment is knowable from data most merchants are already sitting on. If you need the wider programme around this one decision, our guide to how to build a Review-Generation system covers ownership and routing, and the survey of all three levers is in get more product reviews.

This article goes deep on one lever: where the right moment is, how to find yours without new tooling, what to do when it genuinely cannot be measured, and why the second ask obeys different rules from the first.

Why the dispatch date is the wrong trigger

A fulfilment event tells you a parcel moved, not that a person formed an opinion. A request fired from it reaches customers who may not have opened the box, so the only honest answers available are a rating of the packaging or silence. Deferral is refusal in practice, because almost nobody returns to the email later.

Watch what the standard request actually asks. It arrives some fixed interval after a carrier scan, and it invites the customer to evaluate a product they may have unwrapped and put away. The customer has three options. Rate the delivery experience, which is not what you asked. Write something vague and generous, which is worse than nothing because it adds volume without information. Or defer, which is what most do.

Deferral is the outcome worth understanding, because teams model it as a delay and it is not one. An email that is not acted on within its first day is very unlikely to be acted on at all. So a mistimed request does not shift a review later in the calendar. It removes that customer from your review programme entirely, and no amount of reminder frequency recovers them, because the reminder repeats a question they still cannot answer.

There is a second, quieter cost. Requests sent before a customer can answer teach that customer what your emails are worth. The next one is less likely to be opened, and the one after that less again. A programme that mistimes its first ask is not neutral, it is actively spending the attention it will need later.

The opinion formation point, and how to find yours

The opinion formation point is the moment a customer has used a product enough to hold a specific view of it. It varies by category from days to months, and two datasets most stores already have will locate it: first support contacts and return initiations, both plotted against days since delivery.

The useful reframe is to stop asking how many days to wait and start asking when the customer first engages. Those are different questions with different answers, and only the second one is measurable from your own records.

Support tickets are the better of the two signals. Plot first-contact tickets for one category against days since delivery and the shape is rarely flat. There is a cluster, and that cluster is customers meeting the product: unpacking it, setting it up, discovering the thing they need to ask about. Whatever day that cluster peaks on, the customer had an experience specific enough to write to you about, which is the same threshold a useful review requires.

Returns corroborate it from the other side. Return initiations plotted the same way tend to sit just after the ticket cluster, because a return is what happens when the first real use disappoints. If your two curves agree, you have located the moment with two independent measurements and can stop guessing.

The third source costs nothing and is routinely ignored: your existing review text. Customers volunteer elapsed time far more often than teams expect, in phrases about how long they had something before forming a view. Sample a hundred reviews in a category, count the ones that mention duration, and you have a rough distribution of when people felt qualified to write.

Source: Omniconvert, where the opinion formation point sits by category shape, and what a dispatch-triggered ask captures instead
Category shape Opinion forms Best signal to locate it What a dispatch trigger captures
Consumable, immediate use Within days of delivery Support tickets, tight cluster Roughly the right moment
Apparel, try-on decides it At first try-on Returns curve, very sharp Fit, if the customer opened it
Durable goods with a setup After setup and repeated use Support tickets, broad cluster Unboxing and delivery only
Seasonal or occasional item At the occasion, possibly months later Review text mentioning duration Almost nothing usable
Replenishment of a known item Already formed before purchase No wait needed A valid but uninformative repeat rating
Gift purchases Never, for the buyer Not applicable, ask differently A rating from someone who never used it

The last two rows are the ones that change programmes. Replenishment buyers do not need a waiting period at all, so applying one costs you your easiest reviews. Gift buyers never form an opinion of the product, and asking them for one produces exactly the shallow, positive, uninformative reviews that make a review section useless to a shopper.

What to do when the moment cannot be measured

Fall back to the shape of the category rather than to a default number. Ask early for consumables and replenishment, late for durables with a learning curve, and at the occasion for seasonal goods. A rough rule chosen deliberately beats a precise one chosen by a platform default.

Plenty of stores lack the volume to see a clean curve, particularly in a long tail of low-selling products. That is a reason to reason by category rather than a reason to accept whatever the platform ships with.

The practical approach is to sort your catalogue into three or four groups by how quickly an opinion forms, set one window per group, and accept that each window is approximate. Four thoughtful groups outperform one default applied to everything by a wide margin, and the exercise takes an afternoon per catalogue rather than a project.

It is also worth saying plainly what not to do, which is to test many windows simultaneously on a low-volume catalogue. Review response rates are noisy, seasonal and confounded by product mix, so a store sending a few hundred requests a month will not distinguish a good window from a bad one inside a quarter. Choose deliberately, hold it for a full purchase cycle, and judge on review text quality as well as count.

Why the second ask is a different question

A follow-up that repeats the first request performs poorly, because the customer already declined that question. A follow-up that narrows to one specific thing performs far better, since answering one concrete question from memory is a much smaller commitment than composing a review.

Most programmes treat the reminder as a frequency problem: send it again, perhaps with a stronger subject line. That misreads why the first was ignored. The customer did not miss the email so much as decline the task, and the task was open-ended.

The alternative is to change what you are asking. Rather than inviting a review, ask one narrow question the customer can answer in a sentence, chosen from what future buyers are actually uncertain about in that category: how the sizing ran, how it held up after a month, whether the setup was straightforward. A specific question is a smaller request, and the answers are more useful than the open ones because they address a real hesitation.

Two limits apply. One follow-up is usually worth sending and a third almost never is, since incremental responses fall away faster than unsubscribes do. And the specific question has to vary by category, because a question that fits apparel is meaningless for a consumable, which is a reason to keep the number of category groups small enough to maintain.

What this changes downstream

Better timing produces reviews that name specifics, which is what a hesitating shopper reads. Volume without specificity adds a bigger number beside a rating and changes nobody's decision, so the count is a poor measure of whether the programme is working.

The commercial argument for timing rests on what a review is for. A shopper deciding between two products is not counting reviews, they are looking for someone whose situation resembles theirs. That requires text describing a situation, and text like that only comes from a customer who had the experience recently enough to recall it precisely.

Baymard Institute's product-page research has documented for years how heavily shoppers rely on reviews that match their own circumstances rather than on aggregate scores [Baymard Institute]. The corollary is unforgiving: a hundred vague five-star ratings can be less persuasive than eight specific accounts, and mistimed asks produce the first kind almost exclusively.

There is a retention argument too. Bain and Company's work with Fred Reichheld holds that a five percent improvement in retention can raise profits by twenty-five to ninety-five percent [Bain and Company]. A well-timed request is also the moment you discover a recurring product problem early enough to fix it, which is the same lever seen from the other end. To see how your review coverage compares with others in your category, where you stand on reviews is one of the six dimensions a benchmark score reads.

Timing is one input into a customer picture that most stores keep in pieces. Nexus by Omniconvert is an AI for eCommerce growth engine that unifies commerce data, segments customers by behaviour and value, and ranks the next actions worth taking, with a human approving what goes live. The relevant part here is unification: the support, returns and review data this article asks you to plot together usually live in three systems that do not speak. Omniconvert's guide to collecting customer data well covers that foundation.

Timing is half the problem. For the other half, see how to ask for reviews without being annoying.

FAQ: the best time to ask for a review

What is the best time to ask for a review?

Shortly after the customer has used the product in the way that forms an opinion, which is a different moment for every category and is rarely the same as a fixed number of days after dispatch. For a consumable it can be days. For a seasonal or occasional item it can be months. The dispatch date is a logistics event and carries no information about whether the customer has anything to say.

How many days after delivery should I send a review request?

There is no universal number, and any specific figure quoted without reference to a category is guesswork. Find your own by plotting first support contacts and return initiations against days since delivery: both cluster around the point customers actually engage with the product. Set the request a few days after that cluster rather than adopting a default.

Why do fulfilment-triggered review requests underperform?

Because they ask a question the customer cannot answer yet. A request arriving days after a parcel was marked delivered reaches someone who may not have opened it, so the honest responses available are a rating of the packaging or nothing at all. Deferral is functionally identical to refusal, since almost nobody returns to the email later.

What if I cannot measure when customers first use a product?

Use the shape of the category instead of a number. Ask early for consumables and anything bought for immediate use, and much later for durable goods with a learning curve or seasonal items. Then read your own review text for mentions of elapsed time, because customers volunteer that detail more often than teams expect and it costs nothing to collect.

Should I send a second review request?

One follow-up is usually worth sending and a third rarely is. The second request works best when it changes the question rather than repeating it, because a customer who ignored an open invitation will often answer one specific thing. Repeating the same ask at higher frequency raises unsubscribes without raising responses.

Does better timing improve review quality or only volume?

Both, and quality is the half that compounds. A customer asked at the moment they have formed an opinion writes about the specific thing that formed it, which is what helps a future buyer decide. A customer asked too early leaves a star rating about delivery, which adds to your count and tells a shopper nothing.

The bottom line

Stop asking how many days to wait and start asking when your customer first meets the product, because only the second question has an answer in your own data. Plot first support contacts and return initiations against days since delivery for one category, and the cluster will show you the moment. Set the ask a few days after it, group the rest of the catalogue by how quickly an opinion forms, and leave each window alone long enough to read the result. Where you cannot measure, reason from the shape of the category rather than accepting a platform default, and treat replenishment buyers and gift buyers as the special cases they are. Then make the follow-up a different question rather than a louder one. None of this costs money or software, and it changes both how many customers answer and whether what they write is worth reading.