Returns Processing in an Automated Warehouse: Handling the Returns Wave With the Robots You Already Have

Every third-party logistics (3PL) operator plans for the outbound peak. Far fewer plan for what comes back. From the first working day of January, a share of everything shipped in November and December turns round and arrives at the same dock, one parcel at a time, in packaging it did not leave in.

On a manual floor the answer is more people on a returns bench. On an automated floor it is less simple, because returns do not only need people. They need the same robots, the same locations and the same putaway capacity that picking is using, and picking does not stop in January.

Most returns advice treats returns as a department with its own equipment. On a shared fleet, they are a competitor for the fleet.

The short answer

• Returns are not goods-in. Planned inbound arrives on pallets in known quantities. Returns arrive per item, unannounced, in unknown condition.
• Returns compete with picking for the same machines. Every robot carrying a returned tote to inspection is a robot not serving the pick face.
• The constraint is usually allocation, not equipment. Most automated 3PLs have enough robots to absorb the returns wave. What they lack is a rule for how much of the fleet returns is entitled to.
• The hidden cost is stock that exists but cannot be sold. An ungraded return is counted by nobody and available to no one.
• Decide the rules in November. Priority between returns and picking is a commercial decision, and peak is the wrong time to make it.

Why is returns processing different from goods-in in an automated warehouse?

Returns processing is different from goods-in because returns are unplanned, arrive per item rather than per pallet, and need inspection and grading before the system knows what they are. Goods-in moves known stock to known locations. Returns have to establish what the stock is first, and that step needs people as well as robots.

Receiving and putaway of planned inbound is its own problem, covered in our piece on the goods-in bottleneck. Four things separate returns from it.

• Nobody knows when they arrive. A return merchandise authorisation (RMA) says a customer intends to send something back. It does not say which day the parcel lands.
• They arrive per item. A trailer of returns is hundreds of single parcels with different stock-keeping units (SKUs) inside, not forty pallets of one line.
• The condition is unknown. A supplier pallet is assumed good until proven otherwise. A return is unknown until someone opens it, inspects it and grades it: back to stock, repack, quarantine, or out of the building. That inspection is a human step, and robots cannot absorb it.
• The destination varies. Graded stock goes to a pick location, a repack bench, a quarantine area or a disposal lane.

A return is a different workflow: a people step in the middle, a transport leg on either side, and both legs want a robot.

Why do returns compete with picking for the same robots?

Returns compete with picking because on a shared, mixed fleet the same machines carry returned totes to inspection, carry graded stock back to storage and carry picked orders to packing. Every robot on a returns job is unavailable to the pick face, and once the wave arrives neither workflow can be scheduled around the other.

Three resources are shared.

• Machines. The transport legs either side of inspection use the same autonomous mobile robots, goods-to-person shuttles or autonomous forklifts that picking depends on.
• People. The inspection bench is usually staffed by people pulled off the pick line, because they know the stock. Each person on grading is one fewer on picking.
• Locations. A graded item going back to stock needs a slot. If the pick face is full, the robot carrying it waits, or the item goes to overflow and is lost until someone counts it.

In January all three peak together, because returns arrive at their highest rate of the year while sale orders are still being picked at close to peak rates. On most floors the contest is settled by default. Outbound is loud, because a missed cut-off is a client phone call. Returns are quiet, because an ungraded parcel breaks nothing today. So picking wins every argument, and by the third week of January a client is asking why stock they know came back is not showing as sellable.

Do you need more robots to handle the January returns wave?

Usually not. The January returns wave lasts a few weeks, so equipment bought for it sits idle for the other eleven months. The better question is whether the robots already on the floor are allocated deliberately between returns and picking, because on most sites that allocation is settled by whoever shouts loudest.

A coordination layer directing a mixed fleet changes three things.

It allocates by rule rather than by request. Returns work has an entitlement to the fleet, set in advance, instead of taking whatever picking leaves over. That entitlement can be raised for January and lowered again in February without anyone reconfiguring a robot.

It chains tasks. A robot delivering a returned tote to the inspection bench is given graded stock to carry back towards storage, rather than being sent back across the building empty. On a floor running 5 to 500+ robots, that saved empty travel is capacity already paid for.

It resequences live. When a cut-off approaches, picking takes precedence. When it passes, returns capacity recovers automatically. Decision-making runs around 3x faster when allocation happens continuously rather than in batches set at the start of a shift.

One boundary worth stating plainly. FloxMind is not a returns-management product. It does not issue RMAs, grade items, decide disposition or process refunds. Those jobs belong to your returns software and warehouse management system (WMS). FloxMind decides which machine does which job next, across robots from different suppliers, and that is the decision the returns wave strains. Our guide to what a warehouse orchestration layer is covers where that layer sits.

How should you set priority between returns and picking?

Set priority by the cost of delay. A missed outbound cut-off costs a client service level today. A returned item left ungraded costs sellable stock, a waiting customer and a refund that cannot be confirmed. Write both costs down, agree with each client which wins when they collide, and encode the result as an allocation rule, not a shift-by-shift judgement.

Four rules cover most floors:

1. Agree a returns service level per client. Time from arrival at the dock to graded and available to sell. A fashion client will want hours. An industrial client may be content with days. On a shared floor those are different allocation rules for different clients, the same discipline described in our piece on multi-client warehouse automation.
2. Give returns a floor, not the leftovers. A minimum share of fleet capacity through the day, raised during the returns window. Without a floor, returns get capacity only when picking is quiet, and in January picking is never quiet.
3. Sequence restocking by sell-through. A returned fast mover going back to the pick face is replenishment, and it should go first, because the pick face is about to run short of that exact item. A returned slow mover can wait in staging without costing a sale.
4. Define the exception path before the wave. Returns generate exceptions at a higher rate than any other workflow: parcels with no paperwork, items that do not match the RMA, locations that are full. Each needs a destination and a rule for releasing the robot. Our piece on real-time exception handling covers why a stalled task costs more than the task itself.

None of these rules is technical. They are commercial decisions about whose work waits, best made with clients in daylight rather than by a supervisor at six in the morning.

What should you measure during the returns wave?

Four numbers tell you whether returns are handled or merely absorbed: arrival-to-graded time, graded-to-available time, the share of fleet movement spent on returns work, and picking rate on the days returns are heaviest. If picking dips when grading time lengthens, the two workflows are fighting and nobody has refereed.

• Arrival to graded. The queue at the bench. The people constraint. Check it before blaming the robots.
• Graded to available. The transport and putaway leg. The fleet constraint, and the one a coordination layer directly moves.
• Returns share of fleet movement. The proportion of robot journeys that are returns work, by hour. If it is zero until the afternoon and then spikes, returns are getting leftovers.
• Picking rate on heavy returns days. The number that proves whether returns are costing you outbound performance.

Record all four on normal volumes now, so January is a comparison rather than a guess. Our guide to warehouse automation KPIs covers how to baseline them.

When should you sort this out?

Before the outbound peak, not after it. For a UK 3PL reading this in October, the January returns wave is six to ten weeks away, and the rules that govern it can be written and tested on normal volumes now. Peak readiness work usually covers outbound only. The returns half of peak needs the same preparation and usually gets none.

Three things are worth doing while there is still time. Baseline the four measures above on a normal week. Write the allocation rule and test it in a quiet week, because the wrong number is far cheaper to find in November than on the first Tuesday of January. And walk the exception path: take a parcel with no RMA and see where it actually goes. If the answer is "someone sorts it out", that someone will be busy in January.

Our peak readiness guide for automated warehouses covers the outbound side of the same preparation.

What this looks like in practice

Coordinating an existing mixed fleet across picking, replenishment and returns tends to produce throughput uplift of 20 to 40%, error reduction of up to 90% and return on investment in 4 to 12 months. These are ranges rather than promises, and how much you recover depends on how much of your returns cost is allocation rather than bench capacity.

A coordination layer sits between your warehouse management system and the robot controllers, works across 100+ robot models from different suppliers, needs no in-house robotics team, and onboards in less than one week, so there is time to have it running on normal volumes before the wave arrives. If returns are the part of January you are not looking forward to, book a technical demo and we will work through your returns and picking numbers with you.