Returns management software, and the returns that never happen

Returns management software is the operational layer that runs after a customer has decided to send something back. It authorizes the return against your policy, issues the label, tracks the parcel, records receipt and inspection, sets disposition — restock, refurbish, liquidate, recycle — and settles the refund, credit, or exchange order. It is a workflow and accounting system for a decision already made. What it cannot change is how many parcels there are; that number is set earlier, when a shopper picks a size. ShirtMath works on that earlier moment. It is not a returns platform.

Strip the category down and it is a state machine over a parcel, with money attached at the end. Six stages, in order:

Around those stages sits what brands shop for: policy engine, branded portal, exchange incentives, reporting. Loop Returns and Happy Returns are two widely used platforms in the category — the first built around exchange-first flows for Shopify merchants, the second around box-free drop-off at physical return points.

Reason codes. Every return carries a captured reason, and that split decides whether prevention is worth anything. If your volume is mostly damage, wrong item, or changed mind, a sizing tool cannot help — those are packing, picking, and merchandising problems. If a large share is too small, too big, or did not fit, that decision was made on a product page weeks earlier. No sizing vendor can tell you the split; your returns platform knows it, at SKU and size granularity.

Different jobs, not competing products. The table is by capability category rather than by vendor: everything in the platform column sits on the same side of the dashed line.

Two honest readings. A brand that adds a prevention layer still needs a returns platform: returns never reach zero, and someone still has to print the label. And a brand with an excellent returns platform is still paying for every parcel it processes efficiently — efficiency is a cost multiplier, not a volume control. Reducing fit returns covers the volume side.

The mechanism is unglamorous: replace a letter with a comparison in inches. A size label names a position in one brand's size run, not a measurement. In ShirtMath's blank-tee specifications, a ladies'-cut Gildan G500L Medium publishes a 17.5" flat chest against 20.0–20.5" for the unisex Mediums — three inches apart on the same letter, and 3.5" at Large (19.0" against 22.0–22.5"). Both charts are accurate; a shopper who knows only their letter can use neither.

A fit matching layer takes a garment the shopper already owns and trusts and compares its numbers against each catalog garment point by point, reporting differences in inches rather than a score. The comparison is the product. How ShirtMath measures covers where the numbers come from, the t-shirt size chart holds those styles' specs in full, and vanity sizing documents the letter's drift inside one brand.

The limits, plainly. Matching numbers are necessary, not sufficient: taper, drape, fabric weight, and stretch are not on a spec sheet, so two garments with identical published chest and length can wear differently. The photo scanner a shopper uses on their own garment is experimental — about half of readings land within an inch of a real tape, and sleeve opening and bicep are the least reliable.

The input is data most brands already hold — the factory produced it before the first sample was cut: per-size garment measurements, taken flat, in inches or centimetres, keyed to your storefront's variant IDs, with a stated point of measure for every field. For tops the comparison uses eight weighted points:

Chest and body length carry just under half the weight: those two fields, per size, are enough to start. Bottoms use a parallel set of eight points led by waist, inseam, and front rise; "eight points of measure" is a tops-only claim. Pit to pit is worth auditing first.

Per size is the load-bearing phrase. A usable run — the Gildan G500, already in the catalog:

Four rules make a feed usable. State the tolerance you hold — the styles above are published at ±0.3", the Comfort Colors C4017 at ±0.8". Keep the point-of-measure definition attached to the field: a chest taken at the pit and one taken an inch below the armhole are different numbers. Send a machine-readable feed, not a chart rendered into a JPEG. And where a field does not exist, leave it out — ShirtMath excludes a garment rather than inventing a number.

What that rule costs shows in the catalog today. Of 677 rows, 601 carry both a chest and a length; only 17 carry a waist; all 74 bottoms come from merchant feeds rather than brand spec sheets. That is a data gap, not a modelling gap — the gap a brand closes for its own catalog. Size chart integration covers field mapping and feed formats.

ShirtMath is not a returns platform and should not be evaluated as one. It issues no RMAs, prints no labels, holds no inspection workflow, moves no money, and integrates with no carrier, 3PL, or refund ledger. Once an order ships, it does nothing.

What it argues with is the size chart: a fit matching layer acting before checkout, built on measurements a brand already publishes, sitting alongside a returns platform and reading its reason codes rather than replacing its workflow. ShirtMath for Brands is pre-launch and not generally available. There are no customers and no published results, because there are none yet.