betterreviews.Journal 
XXXIV·On Timing·02 October 2026

Q4 returns and the review your customer leaves in February.

The most useful review a brand will collect this winter comes from the buyer who returned the wrong size in December and bought the right one in January. Most platforms suppress that buyer by default.

BetterReviews Editorial·Studio note
CONTENTS · 08
  1. 01What the return-and-rebuy buyer knows
  2. 02What most flows do instead
  3. 03The FTC angle, and why this matters compliance-wise
  4. 04The shape of the post-exchange request
  5. 05What the review reads like, when it gets written
  6. 06Operationalising the post-exchange flow
  7. 07What the operator audits this quarter
  8. 08The closing turn

Holiday return windows extend through January at most apparel and gift-category brands. Lululemon's holiday window extends to January 15. Everlane's runs to January 31. Allbirds keeps an extended window through February for orders placed between Black Friday and Christmas. The longer return window is the operational norm. The companion fact, which almost no brand has reckoned with, is that the review flow goes silent for the entire window.

A buyer who orders a sweater on December 14, receives it on December 19, returns it on January 8, and exchanges it for a different size that arrives on January 22 spends 38 days in flow purgatory. The standard review request was suppressed when the return ticket opened. The replacement order may or may not have triggered a fresh request, depending on the platform's flow logic. In practice, most flows treat the exchange as a different order and never ask. The buyer goes silent.

The buyer should not have gone silent. They have the most useful story in the corpus to tell.

What the return-and-rebuy buyer knows

A buyer who bought once, was disappointed, and walked away tells a brand nothing public. They write a one-star review or, more often, they write nothing and never come back. The corpus does not capture them.

A buyer who bought once, was disappointed, and re-bought a corrected version has been through the failure mode and out the other side. Their review, if asked, is a different artifact entirely. It contains the failure ("the medium ran small"), the path to the fix ("I exchanged for large"), and the outcome ("it fits perfectly now and I wear it twice a week"). One paragraph contains the answer to the next buyer's most common pre-purchase question: which size do I need.

This is the highest-signal review a brand can collect in apparel, footwear, and any category where fit is a variable. It is also the most citation-shaped. When an answer engine is asked "does this sweater run small," it is looking for a sentence written by a specific buyer about a specific size on a specific date. The exchange buyer is the writer of that sentence. The brand asking the question after the exchange has completed is the brand getting cited.

The buyer who returned the medium and re-bought the large has already done the work the next buyer needs to read.

What most flows do instead

Open the flow builder of Klaviyo, Postscript, Yotpo, Okendo, or Junip and the canonical review flow has a return-initiated branch. The branch is almost always "exit flow." The reasoning is intuitive: do not send a "tell us what you loved" email to a buyer who is filing an RMA. Suppressing the request during the return is the polite thing to do.

The suppression is correct at the moment of the return. The suppression is wrong as a permanent state. The platform exits the flow and never re-enters it. The exchange order, when it arrives, is a new order in the system. Whether it triggers a fresh request depends on whether the operator has built the corner case into the flow. Most have not, because the flow builder does not surface "this is a replacement order, request a review at delivery + N days" as a default node.

The buyer falls out of the request queue silently. The brand never sends the email. The review never gets written. The corpus stays thin in exactly the place where it would have been thickest.

The FTC angle, and why this matters compliance-wise

The Federal Trade Commission's final rule on consumer reviews and testimonials (16 CFR Part 465, in force October 2024) prohibits a specific behavior: suppressing reviews from customers based on whether the customer was happy with the product. The rule was written to prevent brands from gating reviews behind sentiment ("you can leave a review only if you give us five stars"). The rule's plain text is broader. It treats the systematic non-solicitation of reviews from buyers who experienced a problem as an instance of suppression, when the non-solicitation is the result of a policy decision rather than an operational accident.

A flow that fires for happy buyers and exits permanently for return-initiated buyers is, on a strict reading of the rule, a sentiment-shaped suppression. The buyer who returned the item is a buyer who had a problem. Never asking that buyer to write about the resolution is suppressing the writeable record of how the brand handled the problem.

The FTC has not, as of late 2026, brought an action specifically on this point. The risk is not the enforcement letter. The risk is that the rule reflects what a fair-dealing brand should already be doing. The buyer who solved their problem with your help wrote the most useful entry your corpus will collect this year. Not asking them is not a compliance triumph; it is a content cost dressed up as caution. The FTC rule reads as a content brief when read closely.

The shape of the post-exchange request

A working post-exchange request is a different artifact from a standard review request. It acknowledges what happened. It does not pretend the return did not occur. It asks about the resolution.

Subject line: "How is the large working out?" Not "Leave a review." The specificity signals that the brand knows what the buyer bought, returned, and re-bought. The from-name is a person at the brand, not the brand's marketing automation address. The body, three short sentences, reads as a follow-up rather than a request.

The form behind the link asks two questions, not one. First: "What didn't work about the original size?" Second: "How is the replacement working?" Both questions have generous text boxes. The placeholder text in the first box reads "Was it the fit, the fabric, the color in person, the way it sat on the shoulder?" The placeholder is doing work; it is teaching the buyer that the brand wants specifics rather than a star rating.

Most buyers, asked these two questions in late January about a December exchange, write something substantive. The exchange is recent enough to remember and resolved enough to evaluate. The buyer has worn the replacement a few times and formed a verdict. The verdict, written down, becomes a paragraph the next buyer reads when they are deciding between sizes.

What the review reads like, when it gets written

A real example, paraphrased from a corpus we read in early 2026 for a Pacific Northwest knitwear brand. The buyer's first order was a medium merino crewneck, gifted to herself in mid-December. The return ticket opened January 6 with the reason "ran small in the shoulders." The exchange order, a large, delivered January 19. The post-exchange request fired February 4.

The buyer wrote 167 words. "I almost did not exchange because I assumed the medium was just the wrong silhouette for me. I am normally a medium in every brand. I exchanged because the return process was simple and there was an obvious 'wrong size' option. The large fits the way the medium looked on the model. The shoulder seam sits where it should. The sleeves are still a little long but I prefer that. I have worn it three times in two weeks. I would tell a friend my shoulder measurement compared to the model's and recommend they size up if their shoulders are at all wider than typical. The wool itself is fine, which I expected from the price. The fit guidance on the product page is what needs work."

The paragraph contains a falsifiable claim, a specific recommendation, a critique, and a verdict. It is the most citable piece of writing on that product page. It is first-person, dated, signed, and it answers a specific pre-purchase question better than any line of marketing copy on the same page. It exists because the brand asked, with specificity, three weeks after the replacement arrived. The default Klaviyo flow would have asked at delivery plus 14 days, in late January, when the buyer was still wearing the sweater for the first few times and would not yet have had a verdict.

Operationalising the post-exchange flow

The flow has three triggers and one wait state.

Trigger one: the return ticket opens. The action is exit-from-current-flow, set a buyer attribute (let's call it `return_in_progress = true`), and pause any pending review requests for this buyer.

Trigger two: the exchange order is created and delivered. The action is start a new flow with a different shape. The flow waits 21 to 28 days from delivery and then fires the post-exchange request. The wait is longer than the standard 14-day default because the buyer needs time to evaluate the replacement, and shorter than 56 days because the exchange is still mentally proximate.

Trigger three: the buyer does not complete an exchange. The return is processed as a refund and the buyer walks away. This is a separate flow, much more cautious. A brand can send a single message at 30 days, asking what would have made the product right, without phrasing it as a review request. Many buyers will not respond. The ones who do produce internal-feedback material rather than public-review material, and that's a different artifact.

The infrastructure is mostly already in the platform. Klaviyo can read return-status events from Shopify's `OrderRefund` and `Fulfillment` resources. Postscript can wait on these events through its Shopify connector. The friction is not technical. The friction is that the platforms ship the standard 14-day flow as a template and ship the post-exchange flow as something the operator builds from scratch. Software that remembers which buyer exchanged what for which size would treat the post-exchange flow as a default branch rather than a bespoke build.

A platform that took the corpus seriously would ship the post-exchange flow as a default, alongside the standard flow. It would treat the buyer who exchanged as a first-class buyer rather than as an edge case. Most have not. The build is two hours of operator work, not two months. The corpus impact is substantial.

What the operator audits this quarter

Three checks, against the current flow setup.

First: open the flow builder and confirm what happens when a return is initiated. Most flows have "exit flow" on the return-initiated branch and nothing afterward. The exit is fine. The nothing-afterward is the bug.

Second: confirm whether the exchange order fires a fresh request. Pull a sample of the last 50 exchange orders and check whether any of them received a review-request email. If the answer is fewer than 25, the flow is leaving exchange buyers in the silent state.

Third: read what the exchange buyers who did write a review actually said. They are usually buried in the back pages of the review widget, posted weeks after the standard cohort. Read ten of them. Note how often they answer the next buyer's question more directly than the rest of the corpus. The exercise takes 20 minutes and changes how the operator thinks about the flow.

The closing turn

Most flows are built around the buyer who orders, receives, uses, and stays. That buyer is the majority. They are not the most useful writer in the corpus. The most useful writer is the buyer who ordered, returned, exchanged, and stayed. That buyer has been through the failure and the fix. Their review tells the next buyer how to avoid the failure or how to recover from it.

The platforms that built the default flow built it for the simple case. The brands that take the corpus seriously build it for the resolved case. The review that gets written in February is the one the brand will be glad to have all year. It belongs to the buyer who almost left. Asking that buyer is the work that almost no software that takes language seriously would skip.

If any of this reads like something your store could use,write to us.

We will write back.

Corrections

corrections@better-reviews.com

Mistakes are listed at the foot of the page when found.