Virtual Try-On Only Fixes the Returns Your Reason Codes Can See

Virtual try-on does not reduce returns. It reduces one specific cause of returns, and whether that cause is a large or trivial share of yours is a question your returns data usually cannot answer, because most returns data was designed to route a parcel rather than to explain a decision.

That distinction decides the business case. Two retailers with identical return rates can get completely different results from the same build, because one is returning goods that looked wrong on arrival and the other is returning goods that arrived late, arrived damaged, or were ordered in three sizes on purpose. Only the first is a problem a camera can solve.

The only returns a try-on can touch

A try-on resolves a visual question before the order is placed. Does this shade suit my skin. Do these frames suit my face. Does this watch look absurd on a small wrist. When the customer could not answer that question from the product photography, they resolve it by ordering and looking, which is a return waiting to happen with a delivery cost attached.

Everything else in the returns pile is untouched. A garment that fits badly is a sizing and pattern problem, not an appearance problem, and rendering it on an avatar does not tell the customer whether the shoulders will pull. A product that arrived scuffed is a fulfilment problem. A customer who ordered a 10 and a 12 intending to send one back has not made a mistake at all, they have made a deliberate purchase of optionality, and no amount of pre-purchase visualisation changes that plan.

This is the honest version of the argument, and it is set out in more detail in the guide on whether virtual try-on actually reduces returns and under what conditions. The category effect is real. It is also narrow, and the narrowness is the part that gets skipped in a pitch.

Your reason codes are probably a routing tool

Look at the reason list your returns portal presents. In most implementations it exists to tell a warehouse what to do with the item: restock it, inspect it, write it off. It was never built to distinguish "I did not like how it looked" from "it did not fit", because those two produce the same warehouse action.

So the codes collapse. A single "not as expected" or "changed my mind" absorbs both the addressable returns and the unaddressable ones, and once they are merged you cannot size the opportunity before building or detect the improvement afterwards. You end up in the position of having spent on an experience and being able to report only that overall return rate moved slightly, in a quarter when three other things also changed.

The free-text box is worse than a bad code list, not better. It generates unstructured strings that nobody categorises, and the ones that get written are dominated by customers annoyed enough to type.

Return reason as recorded	What actually happened	Can a try-on address it
Wrong colour or shade	The photography did not represent it on a real person	Yes, directly
Did not suit me	A visual judgement made too late	Yes, directly
Looked different online	Scale, finish or proportion misread	Yes, for placement and worn items
Too small or too large	Sizing and pattern, not appearance	No, needs size guidance or fit data
Poor quality	Material and construction	No, and a good render can make this worse
Ordered multiple sizes	Deliberate bracketing	No, this is a pricing and policy question
Arrived damaged or late	Fulfilment	No

The point of the table is not the classification itself. It is that you need the left column to split into the right column before you can forecast anything, and most catalogues cannot do that today.

Instrument first, build second

The sequence that works is unglamorous and takes a few weeks rather than a quarter.

1. Split your current reason list so that appearance and fit are separate options, with plain wording a customer will pick correctly. "It did not look how I expected" and "it did not fit me" are different sentences and customers answer them accurately.
2. Make the reason mandatory at the point of initiating the return, not optional in a follow-up email that a minority open.
3. Record the reason against the product and the variant, not just the order, so you can see which items generate visual returns and which generate fit returns.
4. Run that for long enough to cover a normal trading cycle, including at least one promotional period, because discounting changes return behaviour.
5. Rank products by addressable return value, not by return rate. A high-return low-margin item may be worth less to fix than a moderate-return expensive one.

At the end of this you have a list of products where the addressable slice is large enough to justify an asset, and that list is almost always shorter than the catalogue and different from the one people expected. That matters, because asset production is the real cost line in this work and what AR and VR marketing actually costs is driven far more by how many products you model than by the experience itself.

The measurement trap waiting at the end

Even with clean codes, the first result you get will overstate the effect. Customers who use a try-on are self-selecting: they are more engaged, further down the decision, and would have converted better and returned less anyway. Comparing users to non-users measures the difference between two kinds of shopper, not the effect of the tool.

The only clean read is a holdout at the product or traffic level, where a comparable slice of visitors does not see the feature at all, and the comparison is made on returns per order for the same products over the same period. That is a small piece of setup work, and it needs to be agreed before launch because retrofitting it is impossible once the feature is on every page.

Be prepared for the answer to be uneven. It is normal for the effect to be clear on eyewear, cosmetics and jewellery, and marginal on garments where drape and sizing dominate. That is not a failed project, it is a correctly measured one, and it tells you where the second phase should go.

What to do next

Pull last quarter's returns and check one thing: can you separate appearance returns from fit returns without reading free text. If you cannot, that is the first piece of work, and it is a returns portal change rather than a technology project.

If you can, rank products by addressable return value and look at the top of that list. If those products are worn or placed in a space, a try-on is a reasonable candidate and the practical questions become delivery and asset production, which is where the AR and VR immersive marketing practice starts. Before commissioning anything, it is worth reading how these builds behave as a category in the guide to what immersive brand experiences are and which formats get used, because the format decision and the placement decision matter more to the return on this spend than the rendering quality does.