Return Volume Forecasting

A reverse-logistics planner does not win the week by explaining yesterday's dock congestion. The job is to have people, dock doors, and inspection capacity ready for the units that will actually come back. Return volume forecasting is the SKU-and-week estimate that makes that possible.

Machine learning models trained on historical returns, the sales mix that created them, promotion calendars, and product traits produce a forward view of inbound units. The planner still owns the labor plan. The model does not staff the building. It tells you which SKU families will load the receiving line in each of the next several weeks so overtime, temp labor, and sort capacity can be staged before the trailers arrive.

Returns do not arrive as a smooth leftover of outbound shipments. A promotion on a size-sensitive apparel SKU, a first production run with a known fit complaint, or a shift in mix toward kits and accessories can move inbound units in a week without a matching change in overall sales. Treating returns as a fixed percentage of last month's shipments therefore puts labor in the wrong week and the wrong work center.

The speed outcome in the return stage is mostly receiving flow. Credit issuance, grading, and restock cannot start until units are unloaded, identified, and queued. When the inbound volume is wrong in the plan, the first failure is idle people or a backed-up yard. A SKU-week forecast exists so those failures happen less often.

The grain matters. A plant-level weekly total is enough for a rough headcount, but it is not enough to pre-stage the right labor. Bulky SKUs need more cube and more hands per unit. Small, high-return accessories need more scan and sort time. A forecast that cannot distinguish those families forces you to staff for the worst case every week.

Outbound demand and return volume share some drivers, which is why Multi-Signal Demand Forecasting is a useful sibling plan. They are not the same number. Demand forecasting answers what you will ship. Return volume forecasting answers what will come back, with a lag, a different SKU mix, and a different labor profile.

The useful feature set is narrow and operational.

Sales mix is the primary volume driver. Units sold, by SKU, by channel, by week, with enough history to see the typical return lag for that family. A SKU that sells in week 1 and comes back in weeks 3 through 6 needs that lag in the model. A model that only looks at this week's shipments will miss the bulge from last month's sell-in.

Promotions change both volume and return propensity. Deep discounts, bundles, and offer types that pull extra units often raise return rates, not only units sold. The calendar, the offer type, and the SKUs on deal belong in the feature set. A promotion flag with no offer type is usually too coarse.

Product traits capture why two SKUs with similar sales return at different rates. Size complexity, first-run versus mature production, kit versus single unit, seasonal wear, and known quality holds are typical. These are not marketing attributes. They are the fields a quality or product engineer already uses to explain return spikes.

Leave out of the feature set: one-off quality holds that have no analogue in history, brand-new SKUs with no sales, and unstructured customer comments. Those belong in planner notes and overrides.

The output should be units by SKU, or a tight SKU family, by week, with a statement of how thin the history is. A point estimate without a history flag is how a new launch gets a confident wrong number.

The planner still sets the labor plan. That is not a limitation of the software. It is the job. Forecasts do not know union rules, training mix, overlapping inbound from suppliers, or a plant shutdown. They produce a volume signal. You convert volume into hours.

A practical conversion looks like this. Take the SKU-week units. Apply a receiving minutes-per-unit rate by family: unload, identify, sort, and queue for inspection. Sum hours by week and by work center. Compare to the roster already committed. The gap is overtime, a temp request, a shifted start, or a dock-slot change, not a model retraining.

Pre-staging is the speed lever. If a later week shows a spike in a bulky family, you need the people and the floor space before that Monday, not after the first trailers sit. If the following week is light, do not keep the overtime on the books unless the forecast history for that family is thin.

Review cadence should match the labor market, not the model refresh. Weekly is typical: lock the next week, watch the two or three after that, and only reopen the locked week if a promotion pull-forward or a quality event changes the inbound story. Daily model updates that never change the roster are noise.

Downstream work still depends on this roster being roughly right. Automated Return Processing and Credit Issuance cannot credit what has not been received. Returned Item Condition Grading cannot grade a queue that has not been built. Those processes have their own models. They inherit delay if receiving was understaffed.

Empty is a valid output. A cell with no number is better than a number invented from a handful of sales weeks.

Thin sales history is the main stop condition. A new SKU, a new channel, or a new plant shipping into a return center does not have a stable lag or a stable return rate. The model should refuse the SKU-week, or the planner should blank it, and the labor plan should use a manual analogue: a sibling SKU, a prior launch, or a conservative hours buffer labeled as judgment.

Promotions with no historical match belong in the same bucket. If you have never run a bundle of this type on this family, the promotion feature cannot be trusted. Flag the week, raise the labor buffer, and keep the forecast cell empty or clearly overridden.

Quality events and recalls are not demand signals. They produce a pulse of returns that history will misread as a new baseline if you let the model train through them. Exclude the event weeks from training, keep the live forecast empty for the affected SKUs until the event is over, and put the inbound on a separate receiving plan.

Confidence bands help only if someone reads them. If the band is wider than the labor decision, overtime versus not, treat the forecast as empty for staffing purposes and staff the risk you can explain.

You do not need a side project to get a return volume view. Integrated business planning and supply-planning suites already sit on sales history, promotion calendars, and product masters.

Blue Yonder demand and replenishment planning can carry return forecasts as a demand stream or independent demand, driven by history and causal factors, then feed warehouse labor or inbound capacity views. Kinaxis RapidResponse can hold return volume as a scenario-managed demand signal next to the supply plan, so a promotion change shows its labor implication in the same workspace as the outbound plan. SAP IBP can model returns as a forecast key figure with drivers from sales and product attributes, then pass the result into supply and, depending on the landscape, into warehouse or labor planning.

None of these systems should auto-publish a roster. They should publish units by SKU and week, a history-quality flag, and enough of the driver story (mix, promotion, trait) that a planner can accept, override, or blank the cell. The labor plan remains a human decision because the cost of a wrong overtime call is operational, not statistical.

If your IBP already forecasts outbound well and still surprises receiving every month, the gap is usually the return stream: missing lag, promotions treated as volume-only, or product traits that never left the PLM system. Fix that grain before you buy another labor tool.