AI Returns Prediction DTC Brand: A Copyable Template

AI returns prediction DTC brand: what it actually does

AI returns prediction DTC brand programmes work by scoring a placed order — usually within minutes of checkout, sometimes at the point of purchase itself — for the probability it will be returned. The score is a number between zero and one, produced from signals already sitting in your order data, and its only job is to inform three downstream decisions: how much inventory buffer to hold for a category, whether a style’s size chart needs another look, and whether a specific order is worth a sizing-confirmation nudge before it ships. It is not a verdict on the customer, and it does not decide whether their refund is honoured. That distinction is worth stating plainly before anything else, because a model like this is genuinely useful in the hands of a merchandising or ops team and genuinely harmful the moment someone repurposes it to gate service.

The structure that follows is a template you can copy, with every assumption named, not a finished model tuned to your catalogue. The signals that follow are candidates worth testing against your own return data, not guaranteed predictors — validate each one before you trust it with a live decision.

The ethical line, stated before anything else

A return-risk score may inform merchandising, sizing guidance and inventory planning. It must never be used to degrade service, refuse an order, delay or suppress a refund, or quietly penalise a customer for behaviour a model merely predicted. A refund right is not conditional on a model’s guess about what a customer is likely to do — it is conditional on your stated policy and, where applicable, the law that governs it, full stop. A model that is wrong about a specific customer (and any model scoring probabilities will be wrong about specific customers regularly, even while being useful in aggregate) causes real harm the moment its score changes how that customer is treated at checkout, in shipping speed, in support queue priority, or in refund handling. Build the access controls before you build the model: the prediction should live in a system that inventory and merchandising can see, and that customer service, fulfilment prioritisation and refund processing cannot use as an input, ever. If your organisation cannot draw that line operationally — if the score would end up visible to whoever approves refunds, for instance — do not build this yet, because a score that leaks into service decisions is worse than no score at all.

The signals worth testing

Four signals carry information in most DTC apparel-adjacent catalogues, though “most” is doing real work in that sentence — validate each against your own data before weighting it against your own return outcomes.

Size mix in the basket. An order containing two or more sizes of the same style is a strong candidate signal: it often means the customer is uncertain about fit and plans to keep one, return the other, which is a deliberate and entirely legitimate way to shop, not a red flag on the customer. Track this as a basket-level feature (does the order contain multiple sizes of one style, yes or no, or a count) rather than inferring it from anything softer.

First-time-buyer status. A customer with no order history on your store has no history with your specific sizing either, and size-driven returns are frequently concentrated in first orders. This signal is simple to compute (a flag already sitting in most order or customer tables) and worth testing early, but its effect size differs by category — a brand selling one universally-fitting product (a candle, a supplement) will see this signal do almost nothing, while a brand selling fitted apparel across a wide size range may see it do a lot.

Discount depth. A steep discount lowers the cost of ordering speculatively — multiple sizes or colours “to try”, with the expectation of returning what doesn’t work. This is sometimes called bracketing in retail analytics, and it is worth testing as a hypothesis specific to your catalogue, not assuming it holds: some brands see discount-driven orders return at the same rate as full-price ones, particularly in categories with no size variable at all. Test discount depth as a continuous feature (the percentage off) rather than a binary discounted-or-not flag, since the relationship is unlikely to be a step function.

Category-level historical return rate. A style or category with a known a higher-than-average return history is itself a signal for a new order in that category — not because of anything about the specific customer, but because the product or its size chart has a demonstrated fit problem. This one differs from the other three in kind: it is a property of the product, not the order, and if it dominates your model’s output the actionable response is usually to fix the size chart or the product description, not to keep predicting around the same underlying problem season after season.

Shipping address or geography is a fifth candidate worth naming and setting aside deliberately. Using it risks encoding proxies for protected characteristics into a score that could, even unintentionally, correlate with income or demographic patterns in a given area. If you test it at all, treat it with more scrutiny than the four signals covered so far, document the reasoning, and be prepared to drop it if its predictive value is marginal — which, in most catalogues tested this way, it is.

What a high-risk score may trigger, and what it must never trigger

The legitimate uses of this score are all upstream of the customer’s experience with any individual order. A high predicted risk on an order can trigger a sizing-confirmation email sent before the item ships, framed as help rather than suspicion — “here’s how our medium compares to the brand you mentioned in your size question” — never as a warning that the order is under review. It can trigger a category-level flag for merchandising to revisit a size chart or product photography if a style’s predicted risk sits well above its category average. It can feed inventory planning: a category carrying higher predicted return volume this season needs a different safety-stock and markdown plan than one that doesn’t, and that’s a planning input, not a customer-facing action at all.

What it must never trigger: slower shipping, a lower support-queue priority, a longer refund processing time, a requirement for additional verification before a return is accepted, or any visible flag on the customer’s account that colours how a support agent treats their next contact. None of these are hypothetical slippery-slope concerns — they are the specific, concrete ways a returns-risk score turns into discriminatory treatment if it’s wired into the wrong system, and the wiring is a decision your team makes when you decide which systems the score’s output is allowed to touch. Build the score into a merchandising or inventory dashboard first, keep it out of the systems your support and fulfilment teams use to make per-order decisions, and treat any request to change that boundary as a decision serious enough to need sign-off above the team building the model.

The validation method

A returns prediction score is worthless, or worse than worthless, until you know how it performs against orders whose actual outcome you already know. The method:

Step 1: Build a labelled holdout set

Pull a window of past orders long enough to include a full return cycle for your typical delivery-to-return time (if returns typically arrive within 30 days of delivery, your window needs at least that much runway after the latest order in it). Label each order with its actual outcome: returned, or not, within that window.

Step 2: Score the holdout set with the candidate model

Run the same signals and weights you intend to use live against this historical, already-labelled set, producing a predicted risk score for every order in it.

Step 3: Compare predicted risk against actual outcome

Build a table sorting orders into risk deciles (lowest predicted risk to highest) and show, for each decile, what share of orders in it were actually returned. A model carrying real signal shows a rising actual-return-rate as predicted risk rises; a model with no real signal shows a flat line across deciles, whatever its scores claim to represent.

The table is a diagnostic, not a report to publish: what it tells you is whether the model’s ranking of orders by risk lines up with what actually happened, which is the only property that matters before you let it inform anything.

Step 4: Check the false-positive rate at your candidate threshold

Whatever risk score you’re considering as a trigger point, count how many orders above that threshold were not actually returned. This number sets the real cost of acting on the score: every false positive is an order that gets a sizing nudge, or gets counted into an inventory buffer calculation, for no reason. A high false-positive rate doesn’t necessarily rule out using the score — it depends what the trigger costs — but it should change what you’re willing to trigger on it, and it should stop you from wiring it to anything that touches a real customer’s experience of the order.

Step 5: Set a schedule to re-validate, not a one-off check

A catalogue’s actual return drivers move: a new product line, a new discount strategy, a seasonal shift in buyer mix can all change which signals carry weight. Re-run steps 1 through 4 on a rolling basis, and retrain when validation accuracy visibly degrades rather than on a fixed calendar date that has nothing to do with when your catalogue actually changed.

Illustrative arithmetic, to show how a threshold decision gets made rather than to state a real number: imagine a candidate threshold of 0.6 predicted risk flags 200 orders out of a holdout set of 2,000, and of those 200, 90 actually returned — a hypothetical 45% precision at that threshold, meaning 55% of what it flagged didn’t return. Whether that’s usable depends entirely on what the trigger costs: a free sizing-confirmation email at that same hypothetical precision is probably fine; an inventory hold at the same hypothetical precision might not be, because tying up stock on a mostly-wrong signal has a real carrying cost. Set the threshold to the action, not the other way round, and always test the actual precision on your own holdout set — the numbers here are a worked example only.

Setting the threshold: a decision, not a formula

There is no fixed risk score that universally means “act on this order.” The right threshold depends on three things you set deliberately, not on a formula the model hands you. First, what the trigger costs — a sizing email costs almost nothing to send to a false positive; an operational change costs more, so it needs a higher-precision threshold before it’s worth acting on. Second, your team’s capacity to act — a threshold that flags 500 orders a day into a review queue built for exceptions will get ignored within a week, which makes the model worse than useless because it trains your team to stop looking at flags at all. Third, the actual shape of your decile table from validation — if actual return rate only starts separating meaningfully at decile 8, a threshold set at decile 5 is acting on noise regardless of what the raw score number looks like.

Pick a starting threshold conservatively — high enough that the flagged volume is small and the precision is defensible — and widen it only once your team has confirmed it can act on the current volume without the queue backing up. Loosening a threshold is easy to do later; tightening it after a team has built a process around a wider net is a much harder change to make stick, because the process is already running.

Does the model need to tell an exchange from a return?

Yes, and most first attempts at this template don’t, because the raw label in most order systems is just “item came back,” with no distinction between a customer exchanging a medium for a large and a customer sending the item back for a refund with no replacement ordered. That distinction matters for the model in two ways. First, an exchange for a different size is arguably a success case for fit guidance working as intended — the customer stayed, just needed a different size — and folding it into the same “returned” label as a straight refund dilutes the signal you’re trying to detect, because an exchange and a lost sale are not the same outcome for the business even though both start with a box coming back. Second, if your inventory planning use case cares about net units lost rather than gross return volume, an exchange nets close to zero units lost (one size out, a different size back in) while a refund-only return nets a full unit lost, and a model trained on an undifferentiated “returned” label can’t tell your inventory team which is which.

The fix is a data problem, not a modelling one: split the outcome label at the source, in whatever system processes returns, into “exchanged” and “refunded” before it reaches the model, and train separate risk scores for each if your catalogue’s exchange volume is large enough to support it. A brand with a low exchange rate can reasonably fold exchanges into a single “returned” label as a simplification, but should say so explicitly in the model’s documentation, because a threshold tuned against a mixed label means something different than one tuned against refunds alone, and whoever reads the model’s output later needs to know which one they’re looking at.

What breaks in the first month of running this

Three things go wrong in the first weeks of most versions of this template, worth naming so you’re not surprised by them. First, the join between order data and return outcomes is usually messier than expected — a return processed through a third-party logistics provider, a partial return on a multi-item order, or a return-to-store event a Shopify-only data pipeline never sees, all produce gaps in the outcome label your validation depends on. Fix the join before trusting any validation number that comes out of it. Second, a discount-depth signal built during a sitewide sale period looks stronger than it is, because the sale window itself changes buyer mix — validate across at least one full pricing cycle, not just a discount period, or the model will overweight a signal that was really measuring the sale, not the discount. Third, whoever owns the merchandising dashboard the score feeds into will ask, almost immediately, whether it can also flag individual customers for support, and the answer stays no — a returns-risk score never feeds a per-customer service decision, regardless of how reasonable the request sounds in the moment. Fourth, someone will ask why the model’s precision looks worse in production than it did in validation, and the usual answer is that the holdout set was drawn from a period with a different buyer mix than the live traffic scoring against it now — a seasonal spike, a new acquisition channel, or a marketing push into a new customer segment all shift the mix enough to move real-world precision away from what validation predicted, which is exactly why rolling re-validation on a fixed cadence exists rather than a one-off check at launch.

This model works alongside, not instead of, the earlier-stage work that prevents a size-driven return before the order is even placed — fit guidance and attribute enrichment, covered in a separate piece on what actually cuts returns for fashion brands — and a catalogue running both should expect the returns-prediction score to get quieter over time as fewer size-driven returns happen in the first place.

Predicting which orders are likely to return is fundamentally an operations problem: routing a probability into the right downstream process, with the right access controls, on a validated and re-validated basis, is exactly what Pointerflow’s ops automation service exists to build for a DTC brand that has outgrown a spreadsheet version of this template.