Almost every warehouse automation project starts at the pick face. That is where the labour cost is most visible, it is where the business case is easiest to write, and it is what the robots in the vendor's video are doing.
Then the containers keep arriving at the dock.
In a lot of automated warehouses, goods-in is the part of the building that never got touched. Picking is fast, packing is fast, and stock still sits on the receiving floor for most of a day waiting to be put away. That is not a small inefficiency. It is a ceiling on everything downstream, because a robot cannot pick from a location that has not been replenished yet.
The short answer
- Putaway becomes the bottleneck whenever putaway capacity is lower than receiving volume. That gap is usually invisible, because the stock is in the building and the system says it arrived.
- Automating picking can make goods-in worse. A faster pick face drains locations faster, which raises the replenishment rate the inbound side has to sustain.
- Inbound and outbound compete for the same machines. On a shared fleet that competition is a scheduling decision, and on most floors nobody has made it deliberately.
- Most of the fix is coordination, not equipment. Sequencing putaway against the pick plan is usually worth more than adding another forklift.
- It matters most before peak. Inbound surges weeks ahead of outbound, so goods-in is the constraint that bites first and gets blamed last.
Why does putaway become the bottleneck in an automated warehouse?
Putaway becomes the bottleneck when the rate at which stock can be moved from the dock into pickable locations falls below the rate at which it arrives. The queue then forms on the receiving floor, where it looks like a housekeeping problem rather than a throughput problem.
Three things usually cause it, and they compound.
The equipment is shared and undirected. Forklifts and pallet movers are doing inbound, replenishment, returns and the odd ad-hoc job, assigned by whoever asks loudest. Operators spend a significant share of the shift travelling empty or waiting, which is capacity you have already paid for.
The slotting rules are stale. Putaway locations were set when the SKU mix looked different. Fast movers end up deep in the building, so every putaway and every replenishment carries a longer journey than it needs to.
Downstream got quicker. This is the one that catches people. Automating the pick face raises the drain rate on every location, so the replenishment cycle that used to be comfortable is now marginal. The picking automation worked exactly as promised, and it exposed a constraint one process upstream.
What does automated receiving and putaway actually involve?
Four distinct jobs, which is worth separating because they have different costs and different payoffs:
- Unloading. Getting goods off the vehicle. Heavily equipment-dependent and the hardest to change in an existing building.
- Verification. Confirming what actually arrived against what was expected. Increasingly vision-assisted, and the place where errors are cheapest to catch.
- Internal transport. Moving goods from the dock to staging or storage. This is where most of the dwell time sits, and it is the job autonomous mobile robots and autonomous forklifts do well.
- Directed putaway. Deciding which location each pallet or tote should go to, and in what order. This is a software decision, not a hardware one, and it is the cheapest lever in the list.
Most 3PL operators looking at goods-in assume they are buying the first one. In practice the third and fourth are where the recoverable time is, and the fourth needs no new equipment at all.
Can you fix goods-in without buying more equipment?
Usually you can recover a meaningful share of it, because the loss is mostly in sequencing rather than in machine capacity.
A coordination layer directing a mixed fleet changes three things about putaway.
It sequences putaway against the pick plan rather than against arrival order. Stock needed for this afternoon's orders goes away first, even if it came off the second trailer, because the layer can see the outbound demand and the inbound queue at the same time. Nobody on the floor has that view.
It chains tasks instead of stranding them. A machine finishing a putaway at the back of the building is given a job that starts near where it is, not one that sends it back empty. On a floor running 5 to 500+ robots that compounding of empty travel is one of the largest recoverable losses in the building.
It coordinates across suppliers. If your autonomous forklifts came from one vendor and your tote robots from another, each fleet manager can only see its own machines. Inbound work that could be handled by whichever unit is closest instead waits for the right brand to become free. In one anonymous deployment with an international retailer, coordinated autonomous forklifts moved 100+ pallets in four hours.
Our guide to what a warehouse orchestration layer is covers how that coordination works underneath.
How do inbound and outbound compete for the same robots?
Directly, and on most floors the competition is settled by accident.
Every machine assigned to a putaway is a machine not available for a pick, and both jobs have deadlines. Outbound deadlines are loud, because a missed cut-off is a client phone call. Inbound deadlines are quiet, because nothing breaks today when a pallet stays on the dock until tomorrow. So outbound wins every argument, inbound accumulates, and three weeks later the pick face is short of stock and the reason is invisible.
The fix is to make the trade-off explicit. A coordination layer that holds both queues can reserve capacity for replenishment ahead of a known cut-off, rather than letting inbound have whatever is left over. That is a decision about how much of the fleet inbound is entitled to at each point in the day, and it is the sort of rule that should be set once and reviewed, not improvised each shift.
The same argument runs through our piece on real-time exception handling: work that is not reassigned live ends up queueing behind whatever stalled first.
What changes before peak?
Inbound peaks before outbound does, which is why goods-in is the first constraint to bite in the run-up to Black Friday and the last one anyone blames.
Stock builds through October and November for a demand spike in late November and December. So the inbound side is running at its hardest at exactly the point when the operation still has time to fix things, and the outbound side has not yet started shouting. If receiving is already backing up in October, the pick face will be short in December, and by then the only available response is overtime.
Three things are worth doing while there is still time: measure dock-to-stock now rather than at peak, confirm putaway is sequenced against the outbound plan rather than arrival order, and check what happens to a stranded inbound task when the machine holding it stops. Our peak readiness guide for automated warehouses covers the wider sequence.
What should you measure?
Four numbers tell you whether goods-in is your constraint:
- Dock-to-stock time. How long from arrival to pickable. The headline measure, and the one most 3PLs report monthly when they should watch it daily.
- Putaway rate against receipt rate. If the second is consistently higher than the first, the queue is structural and not a bad week.
- Empty travel share. The proportion of machine movement carrying nothing. This is the recoverable capacity, and it is usually larger than people expect.
- Replenishment misses. Picks that could not happen because the location was empty. This is the number that proves goods-in is costing you outbound performance rather than merely looking untidy.
Our guide to warehouse automation KPIs sets out how to baseline these so a change is measurable rather than anecdotal.
What this looks like in practice
Coordinating an existing mixed fleet across inbound and outbound tends to produce throughput uplift of 20 to 40%, error reduction of up to 90% and return on investment in 4 to 12 months, with decision-making around 3x faster when allocation runs live rather than in batches. These are ranges, and how much you recover depends on how much of your inbound loss is sequencing rather than capacity.
A coordination layer sits between your warehouse management system and the robot controllers, works across 100+ robot models from different suppliers, and needs no in-house robotics team. If goods-in is where your floor slows down, book a technical demo and we will look at your dock-to-stock numbers with you.