LogisticsAI Implementation & Best Practices

Maximising warehouse throughput with AI: the logistics operator's guide to the moving bottleneck

Warehouse throughput is the number of order lines a distribution centre can complete per unit of time, and it is always limited by one binding constraint at a time. AI raises it by finding that constraint continuously — across slotting, pick paths, wave release, labour and robotics — and rebalancing before it moves.

Logistics · AI Implementation & Best Practices

Atomic Loops EngineeringIndustrial AI practiceReviewed by Atomic Loops Solutions ArchitecturePublished 14 August 202658 min read

Key takeaways

A distribution centre has exactly one binding constraint at a time, and it moves. Throughput is therefore not a sum of station improvements — it is whatever the current constraint permits, which is why a genuinely faster pick face can show up at the door as no change at all.
The seven decisions that move DC throughput are slotting and re-slotting, pick-path optimisation, wave versus waveless release, labour allocation and flex staffing, dock and staging assignment, robot fleet orchestration, and packing-station balancing. They have wildly different time constants, from seconds to weeks.
Measure the line, not the door. Units per labour hour by station and interval, queue and buffer depth, travel distance per line, dock-to-stock and order cycle time together tell you where the constraint is; shipped-orders-per-shift tells you only that it existed.
Single-point optimisation is the commonest and most expensive mistake in warehouse AI. Relieve travel in the pick face and the constraint moves to replenishment; add goods-to-person stations and it moves to decanting; smooth release and it moves to packing and the sorter.
Models trained on normal weeks mislead during peak. Rate curves flatten under congestion, agency labour has a different learning curve, and the constraint moves faster than the retraining cadence — so peak needs its own training window, wider bounds and a human escalation path.

Abbreviations used on this page

DC: Distribution centre
WMS: Warehouse management system — inventory, tasks and orders
WES: Warehouse execution system — release, sequencing and balancing
WCS: Warehouse control system — the equipment layer under the WES
LMS: Labour management system (engineered standards, clock data)
AMR: Autonomous mobile robot
AGV: Automated guided vehicle
AS/RS: Automated storage and retrieval system
GTP: Goods-to-person picking
UPLH: Units per labour hour
SKU: Stock-keeping unit
TOC: Theory of Constraints

What warehouse throughput is, and why a DC has one binding constraint at a time

A definition, the control loop that raises it, and the single structural fact that governs every decision on this page.

Warehouse throughput is the rate at which a distribution centre converts inbound receipts and open orders into completed, loaded shipments — normally counted in order lines or units per hour, per shift, or per labour hour. It is a property of the whole line, not of any station in it: the DC as a system can only run as fast as its slowest currently-binding step, and every other station is either waiting, buffering, or building work-in-progress that will wait later.

That framing is the Theory of Constraints (opens in a new tab), and it is the most useful lens available for warehouse AI because it explains the result that confuses most first projects: a station got measurably faster and the door saw nothing. In a constrained line that outcome is not a failure of the model — it is the expected result of improving a station that was not binding. The constraint is also not fixed. It moves between receiving, replenishment, picking, packing, sortation and loading across a shift, across a week, and dramatically across a peak season.

Binding constraints a DC has at any given moment

Theory of Constraints

Decisions inside the four walls that move it

Stages on the throughput ladder below

AI raises throughput by closing a control loop that most DCs run open. The loop has three parts: sense what every station and buffer is doing on a common clock, decide which station is binding now and which will bind next, and act on the levers that can be moved inside a shift — release rate, labour, pick paths, fleet allocation, dock and staging assignment. The diagram below is that loop, drawn against the systems that actually own each part of it.

The throughput control loop, and where it usually breaks

Sense, decide, act — with the systems that own each step. The stage is determined by where the loop closes: reactive sites terminate at a supervisor's judgement in a huddle, balanced sites write a release and labour decision back into the WES, and self-balancing sites let bounded moves execute and escalate the rest. Most DCs never close the loop at all.

Data & feeds
AI / model
Human in the loop
Where value leaks
System-of-record action

The process, in words

Sensing is the cheap half and most DCs already own the data. WMS task confirmations give you completed work by station, WCS and fleet telemetry give you equipment state and congestion, and LMS clock data plus periodic buffer sampling give you the labour and queue picture. The work is joining all three onto one clock at interval resolution, not collecting anything new.
Deciding is where the stage is set. A line model — station rates, buffer capacities, which station feeds which — turns the sensed state into a single binding-constraint call for the interval, and, crucially, a prediction of which station becomes binding once the current one is relieved. Without that second output, every relief action is a coin toss about where the throughput actually lands.
Acting is where value leaks. If the constraint call has no path into the WES or WCS, it terminates at a shift huddle: a verbal instruction, issued after the queue formed, recorded nowhere. That path still moves the floor, but it produces no data, cannot be evaluated, and disappears with the supervisor who gave it. Closing the loop means the decision is written back as release rate, a labour prompt or a fleet target, and the resulting floor events feed the next interval's sense step.

Step-by-step insights

WMS task events — the free telemetry nobody joins: Almost every DC already writes a timestamped confirmation for every pick, putaway and replenishment task, tagged with an operator, a location and a task type — and usually uses it only for productivity reporting against engineered standards. Joined to station geography and rolled to 15-minute intervals, that same log yields per-station output rates without a single new sensor. Start here: it is the highest-yield instrumentation available and the integration risk is nil, because you are reading rather than writing.
WCS and fleet telemetry — where congestion actually shows up: Station rates alone will mislead you, because a conveyor at 90% occupancy or an AMR zone in gridlock does not report as a slow station — it reports as a fast station that is waiting. Sorter recirculation, accumulation depth, robot queue length at pick positions and effective fleet size after charging are what separate 'this station is slow' from 'this station is blocked'. In robotised DCs congestion is frequently the true constraint, and it is invisible in WMS data.
Labour and queue depth — the two inputs usually missing: The labour join matters because units per labour hour is meaningless without knowing who was actually on the station in that interval, including partial hours, breaks and training. Queue depth matters because it is the only direct observation of where work is piling up. Buffer sampling can be crude — a periodic count of totes in an accumulation lane, cartons at pack, pallets in staging — and still be the most informative series on the floor.
The line model — small, explainable, not a neural network: The model that names the binding station does not need to be sophisticated, and there are good reasons for it not to be. Station rates from recent history, buffer capacities from the layout and feed relationships from the process map are enough for a queueing or simple discrete-event representation. Supervisors can argue with a model like that, which is the point: it must be defensible on the floor at 14:00, not accurate in a backtest. Reserve heavier machinery for the point decisions underneath it.
The successor prediction — the output most models never produce: Naming the current constraint is table stakes. The output that changes behaviour is the successor: if we relieve pack by opening two stations, where does the constraint go, how fast, and what does that station need in order not to become the new limit? This turns rebalancing from a reaction into a plan, and it is what lets a site pre-staff replenishment before the re-slot lands rather than three weeks after. It is also what makes the migration ledger below computable rather than anecdotal.

One clarification before the ladder, because it decides how the rest of this page reads. Throughput is not the same as speed for an individual order. A DC can raise lines-per-hour while making order cycle time worse, by batching harder and letting work-in-progress accumulate between stations. Both numbers therefore have to be reported together, using the standard definitions in the SCOR reference model (opens in a new tab) so the site is not quietly redefining its own success. Every measurement recommendation on this page assumes that pairing.

The five stages of throughput maturity, in detail

For each stage: what it looks like on a real DC floor, the diagnostic signals a reviewer can check in a shift, the anti-pattern that traps sites there, and what leaving costs.

Each stage below is written for a practitioner rather than a buyer. The hallmarks describe conditions you can observe on a walk of the floor, the diagnostic signals are checks you can run against your own WMS and WCS data this week, and the anti-pattern is the specific mistake most often made trying to leave that stage. The plateau on this ladder is stage 3 — local optimisation — which is why so many warehouse AI projects report an excellent local metric and an unchanged shipped volume.

Select a stage

Every stage's full detail is in the page source — the selector only changes which panel is visible, so nothing here depends on JavaScript to exist.

Stage 1

Reactive

12% of operators sit here

Throughput is managed by shift-level firefighting: the constraint is discovered when orders start missing the cut-off.

Stage 1 is not incompetence — it is a measurement gap that makes competence invisible. Supervisors at reactive sites are frequently right about where the problem is; they simply learn it from the shape of a queue at eye level, which means they learn it after the queue has formed. By then the constraint has consumed an hour of line time the site will never recover.

The tell is the reporting cadence. The authoritative record of yesterday is a shift summary: orders shipped, units picked, hours worked, and a comment field. Nothing in it can say whether pack was starved at 11:00 and drowning at 15:00, or whether the pick line lost forty minutes waiting for replenishment. Both facts existed; neither survived the shift.

Reactive sites pay for the constraint twice — once in lost line time, and again in the overtime, expedited freight and weekend recovery used to make the cut-off anyway. Those recovery costs are usually booked somewhere that makes them look like a labour problem rather than a balancing problem.

In practice

The 15:00 scramble

An ambient e-commerce DC runs a 17:00 carrier cut-off. Pack sits idle through the late morning because picking is waiting on replenishment into the forward face; by mid-afternoon the pick backlog clears at once and pack becomes the constraint. Supervisors pull people off receiving, the cut-off is made, and dock-to-stock on the inbound trailers quietly slips into the next day. None of it is recorded anywhere a system could read, so next Tuesday it happens again.

What it looks like

Throughput is reported as orders or units shipped per shift, after the fact
The bottleneck is identified by whoever is shouting loudest at the huddle
Wave plans are built the night before and rarely change during the shift
Flex labour moves happen when a station has already visibly backed up

Diagnostic signals you can check this week

Ask what the pack line ran at between 14:00 and 15:00 last Tuesday. If the answer is a shift total, you are here
Count how many people were moved between functions yesterday, and whether anyone wrote down why
Check whether the wave plan that ran is the wave plan that was built the night before
Ask where inbound receiving hours went on the site's three worst cut-off days last quarter

Anti-pattern · Buying automation to fix a measurement problem

The instinctive fix for a site that misses cut-off is capital: more pack stations, a sorter upgrade, a goods-to-person cell. Bought before the line is instrumented, that capital is aimed by anecdote — and the anecdote is the last painful shift, not the modal one. Sites regularly automate the station that hurt most recently and find the constraint was two steps upstream. Instrument for one quarter first; the equipment decision gets cheaper and better aimed, and some of it stops being necessary.

What holds you here

There is no interval-level record of the line, so the constraint can only be identified after it has already cost cut-off.

Highest-leverage next move

Capture station-level task events and queue depths at 15-minute resolution for one outbound shift, and publish the constraint record daily. No modelling yet.

Cost of leaving

Effort: 2–4 months
Team: One data engineer, one industrial engineer or site analyst, part-time
Risk: Low — the work is additive telemetry and changes nothing on the floor
To next stage: 2–4 months

If this is you, the next step is

A 3-week engagement: event capture, station rates, a constraint record you can read.

Instrument one shift end to end

Stage 2

Measured

31% of operators sit here

Throughput and its components are instrumented at interval level, but nothing acts on the measurement automatically.

Stage 2 is where the site stops arguing about what happened. Once station rates and buffer depths sit on a common clock, the reconciliation meetings end: pack really was starved until 11:40, replenishment really did fall behind on the fast movers, and the numbers say so without anyone having to win a debate. That is genuine progress and worth the quarter it takes.

The trap is that measurement feels like control. A daily constraint report changes nothing unless someone reads it before the shift it describes — and that shift has already happened. Stage 2 sites build very good boards that supervisors glance at during handover and then ignore, because their own eyes are faster and the board has nothing to say about the next four hours.

There is a subtler risk too. Interval measurement makes local inefficiency highly visible, and the reflex is to attack the worst-looking number. But a station at 60% utilisation is not necessarily a problem: in a balanced line most stations must run below capacity, or the constraint would be everywhere at once. Chasing utilisation at non-constraint stations builds inventory between stations, lengthens order cycle time, and feels busier while shipping the same volume.

In practice

The dashboard that agreed with the supervisor

A cold-chain DC instrumented every station and stood up an hourly throughput board. Within a month the board and the supervisors agreed almost perfectly about where each day's constraint had been, which the site read as validation. It was — and it was also the whole problem. The board described a shift that had finished, and the supervisor had already worked around it. Nothing about release, labour or replenishment changed for two more quarters, because agreeing on the past is not acting on the present.

What it looks like

Units per labour hour is read by function and by interval, not just per shift
Queue and buffer depth are sampled at each station on a schedule
A daily report ranks stations by utilisation and backlog
The site can say where the constraint was yesterday, but not where it will be at 14:00

Diagnostic signals you can check this week

Ask whether the throughput board is opened during the shift or at handover
Check whether utilisation targets exist for non-constraint stations — and whether anyone is chasing them
Look for work-in-progress piling up between stations on the days the board looks best
Ask a supervisor to name a decision they made differently last week because of the measurement

Anti-pattern · Optimising the station with the worst-looking number

The board makes the lowest-utilisation station obvious, and the reflex is to fix it. In a line that is precisely backwards: raising output at a non-constraint station adds inventory in front of the constraint and nothing at the door, while consuming the improvement budget and the site's patience. Before any optimisation, name the binding station for the interval in question and check whether the proposed change touches it. If it does not, it will not move throughput however good the local metric looks.

What holds you here

Measurement is retrospective, so the constraint is named after the shift rather than during it, and no decision changes.

Highest-leverage next move

Build a simple line model — station rates, buffer capacities, feed relationships — and publish a predicted binding station for the next four hours, scored against what actually happened.

Cost of leaving

Effort: 4–8 months
Team: Data engineer, industrial engineer, a named site owner for throughput
Risk: Low to medium — the analytics are safe; the risk is chasing local utilisation
To next stage: 4–8 months

If this is you, the next step is

We build the line model from your existing WMS and WCS events. Typically 6 weeks.

Turn measurement into a constraint call

Stage 3

Optimised locally

36% of operators sit here

One function is optimised by a model — usually slotting or pick paths — and the gain is real, but the constraint moves to an unoptimised neighbour.

Stage 3 is the plateau on this ladder, and it is dangerous precisely because the local result is genuine. Travel distance per line really did fall. Pick rate at the goods-to-person cell really did rise. The model is not overfitted and the measurement is not wrong. What happened is that the constraint moved, and nobody was watching where it moved to.

The mechanics are unglamorous and entirely predictable once you look. Faster picking drains forward pick locations faster, so replenishment becomes binding. More goods-to-person throughput pulls harder on decanting, so the stations starve. Smoother release floods packing. Each time the site has converted one constraint into another — real progress, since the line is now capable of more, but only if the successor is relieved too.

The reason sites stall here is organisational rather than technical. The slotting project has a slotting owner, the robotics project has an automation owner, and nobody owns the line. Each function optimises to its own metric and each is individually correct. What is missing is one shared view of where the binding station is right now, which is why the move to stage 4 is a modelling and ownership change rather than a new algorithm.

In practice

The re-slot that made replenishment the problem

A retail DC re-slotted its forward pick face by velocity and affinity, and travel per line fell by a clear margin on the site's own measurement. Pick UPLH rose. Shipped lines per shift barely moved. The reason appeared three weeks later in the replenishment backlog: the fast movers now closer to packing were also depleting faster, and the replen task list — sized against the old pick rate — could no longer keep the face full. The site had bought a faster pick line and a new constraint in the same change.

What it looks like

A model runs one decision well: slotting, pick paths or GTP station assignment
The optimised function's own metric improves clearly and repeatably
Shipped volume at the door moves far less than the local metric did
The next constraint was not predicted and was not pre-staffed

Diagnostic signals you can check this week

Compare the improvement in the optimised function's metric against the change in lines shipped per shift. A large gap is the signature
Ask which station became binding after the change, and whether anyone predicted it beforehand
Check whether work-in-progress grew between the optimised station and its downstream neighbour
Look at whether the optimisation model has any input describing the rest of the line. Usually it has none

Anti-pattern · Buying a second point optimiser

When the first optimisation does not show at the door, the reflex is to optimise the next station too — a second model, a second vendor, a second project. That works exactly once more, and then the constraint moves again. The cost is not just the second project: two independently optimised stations pull against each other, and the site now has two models that each believe they set the pace of the line. What is needed is not a third optimiser but a model of the line, with the point optimisers taking targets from it.

What holds you here

Each function is optimised against its own metric, so relieving one constraint simply promotes the next and the door sees little of it.

Highest-leverage next move

Make one model of the whole line the source of targets for every point optimiser, and relieve the successor constraint in the same change as the first.

Cost of leaving

Effort: 6–12 months
Team: ML engineer, integration engineer, an industrial engineer who owns the line model
Risk: Medium — the first write into the WES needs bounds and a drilled fallback
To next stage: 6–12 months

If this is you, the next step is

We build the migration ledger for your line and pre-stage the successor constraint.

Map where your constraint moves next

Stage 4

Balanced end to end

17% of operators sit here

The DC is modelled as a connected line, and release, labour and automation decisions are all made against the current binding constraint.

At stage 4 the question changes from 'which station should we improve' to 'what is the line permitted to do today, and what is stopping it'. That produces different behaviour: sites stop chasing utilisation at non-constraint stations, stop measuring success in local metrics, and start protecting the constraint — feeding it first, staffing it first, never starving it.

The engineering is less exotic than it sounds. A line model needs station rates, buffer capacities, feed relationships and a current state, and most of that already exists in the WMS task log and WCS telemetry; the work is joining them onto a common clock. The genuinely hard part is write-back: release rate adjustable inside the shift, labour recommendations reaching a supervisor in the tool they already use, and fleet targets reaching the fleet manager as configuration rather than as a phone call.

The remaining constraint is human throughput. Every rebalance still passes a supervisor, so the line rebalances only as often as a person can be asked to approve it — in practice a few times a shift. For most DCs that is sufficient, and stopping here is a defensible permanent choice. Going further is a risk-appetite decision about which moves may happen unattended, not a technical one.

In practice

The line that stopped chasing utilisation

A multi-client contract logistics site put every decision behind one constraint call. The first visible change was that three stations were deliberately allowed to run well below capacity, because pulling them up only built work-in-progress in front of the binding station. The internal utilisation report looked worse for two months while lines shipped per shift and order cycle time both improved. Getting the operations director comfortable with the worse-looking number took longer than building the model.

What it looks like

One line model produces the binding-station call that every decision references
Release rate, labour moves and fleet targets all cite the same constraint
The successor constraint is predicted and pre-staffed before a change lands
Throughput is reported alongside order cycle time, so speed is not bought with work-in-progress

Diagnostic signals you can check this week

Ask three different teams where today's constraint is. At stage 4 they give the same answer and cite the same system
Check whether release rate changed during the last shift, and what triggered the change
Look for a written prediction of the successor constraint attached to the last improvement project
Verify that order cycle time is reported next to throughput — speed bought with work-in-progress shows up here

Anti-pattern · Automating the rebalance because the model is good

Stage 4 makes unattended rebalancing technically easy, which is exactly when it gets extended past the evidence. Bounds derived from a quarter of approved release changes on the ambient line get applied to the cold chain, or to peak, where the rate curves and the labour mix are different. The first bad automated release — a flood into a pack line that cannot absorb it — typically ends with all automation switched off, and the site loses more ground than autonomy ever gained. Earn bounds separately per area and per season.

What holds you here

Every rebalancing decision waits for a supervisor, so the line can only rebalance as often as a person is available to approve it.

Highest-leverage next move

Define the bounds inside which release, labour and fleet changes may execute without approval, per area and per season, with an escalation path and a logged audit trail.

Cost of leaving

Effort: 12–18 months
Team: Platform engineer, ML engineer, industrial engineer, an operations owner with a throughput target
Risk: Medium to high — write-back into release and labour touches how the floor is run
To next stage: 12–18 months

If this is you, the next step is

Which moves may execute unattended, in which areas, and the evidence that makes it safe.

Design your rebalancing bounds

Stage 5

Continuously self-balancing

4% of operators sit here

The binding constraint is re-identified within the shift and release, labour and fleet policy adapt inside agreed bounds, with humans setting policy and handling exceptions.

Stage 5 is narrower than the phrase suggests. It is not an autonomous warehouse; it is an enumerated set of moves — release rate inside a band, flex labour between two named functions, fleet zone weighting, charge scheduling — that may execute without approval inside stated limits, with everything else escalating. Slotting changes, headcount decisions and anything touching a customer commitment stay with people, correctly and permanently.

The engineering is largely solved by the time a site arrives here. The hard part is the policy artefact: a versioned, reviewable statement of which moves may execute unattended, in which areas, under what conditions, and what happens when those conditions stop holding. It is what a customer, an auditor or a safety review will ask to see, and what makes an automated decision from eight months ago reconstructable.

Sustaining stage 5 is a governance discipline, and it is the stage most likely to regress. A new client's order profile changes the rate curves. A mezzanine goes in. Peak arrives and March's bounds are not November's. The most useful signal is the escalation rate — the share of intervals where the policy declined to act — because a rise means the world has moved outside the policy's validity, and noticing that is far cheaper than being told by an incident.

In practice

The bounded move set

A high-volume fulfilment site runs continuous release against downstream buffer depth inside an explicit band, plus automated flex-labour prompts between two named functions and constraint-weighted fleet zoning. Roughly one interval in eight escalates to a supervisor — a client ramp, an equipment fault, a shift where agency labour changes the rate curve. The escalation rate is itself monitored on a control chart: when it drifts up, the policy is reviewed before peak rather than after an incident.

What it looks like

Release rate tracks downstream buffer depth continuously, within stated bounds
Fleet zoning, traffic policy and charge windows follow the current constraint
Humans manage the policy and the exceptions, not the individual rebalances
Every automated move is logged with the constraint call that justified it

Diagnostic signals you can check this week

Whether the bounds document is versioned and reviewed like code, with named approvers
Whether the fallback to fixed waves and fixed zones has been exercised in the last six months
Whether escalation rate is tracked as a leading indicator rather than as noise
Whether a reviewer could reconstruct why the system changed release rate at 14:15 on a given day

Anti-pattern · Treating the bounds as a settings screen

Thresholds get nudged in a configuration page during a difficult week, with no review, no version history and no note of who changed what. The site works right up until someone has to explain why the line flooded packing on a Saturday, at which point neither the policy that produced it nor the constraint call behind it can be reconstructed. Version the bounds, review changes on a cadence, keep the trail — and make peak a policy change with an approval, not a quiet edit.

What holds you here

Sustaining self-balancing is a governance problem — the constraint becomes policy currency and change control, not engineering.

Highest-leverage next move

Treat the bounds document as a versioned, reviewable artefact with the same rigour as the model, and re-approve it before every peak.

Cost of leaving

Effort: Continuous
Team: Platform team plus a standing throughput governance forum with operations and safety
Risk: Concentrated — low frequency, high consequence, and safety-adjacent where robots are involved

If this is you, the next step is

We run your bounds, your audit trail and your fallback against a real peak scenario.

Stress-test an automated rebalance

Where distribution centres actually sit on the throughput ladder

The distribution across the ladder, and why the stage 3 → 4 step is the largest transition loss on this curve.

Most distribution centres sit at stage 3 — locally optimised. The distribution is weighted toward sites that have measured their line properly and then optimised exactly one function within it: a slotting engine, a pick-path optimiser, a goods-to-person cell, an AMR deployment. Each of those is a real capability. What is rare is the site that models the whole line and makes every decision against the same constraint call, and rarer still the site that lets bounded moves execute unattended.

Throughput released against time on the ladder

The curve is not linear, and the flat section is the point. Stage 3 sites release real value inside one function and very little of it at the door, because the constraint simply migrates. The inflection happens at stage 4, when release, labour and fleet decisions start referencing one constraint call instead of four local metrics.

Throughput released from the same footprint by stage

Stage 1 · Reactive — 12% of operators. Throughput is managed by shift-level firefighting: the constraint is discovered when orders start missing the cut-off.
Stage 2 · Measured — 31% of operators. Throughput and its components are instrumented at interval level, but nothing acts on the measurement automatically.
Stage 3 · Optimised locally — 36% of operators. One function is optimised by a model — usually slotting or pick paths — and the gain is real, but the constraint moves to an unoptimised neighbour.
Stage 4 · Balanced end to end — 17% of operators. The DC is modelled as a connected line, and release, labour and automation decisions are all made against the current binding constraint.
Stage 5 · Continuously self-balancing — 4% of operators. The binding constraint is re-identified within the shift and release, labour and fleet policy adapt inside agreed bounds, with humans setting policy and handling exceptions.

Curve shape: logistic, plotted from the stage data above. Distribution: Consistent with MHI's Annual Industry Report on automation adoption.

Distribution of distribution centres across the five stages

Stage 3 is the mode and the plateau. The drop from stage 3 to stage 4 is the largest single transition loss on this ladder, because the move requires a model of the line and a write-back path rather than a better point optimiser.

Share of distribution centres

12% — 1 · Reactive
31% — 2 · Measured
36% — 3 · Optimised locally (the plateau)
17% — 4 · Balanced end to end
4% — 5 · Self-balancing

Source: Illustrative distribution, synthesised from MHI adoption research and operators' own published material

Treat those proportions as illustrative rather than surveyed — they synthesise the adoption picture published in MHI's Annual Industry Report (opens in a new tab), which tracks how far robotics, automation and AI have actually been deployed across material handling and warehousing, together with what large operators have published about their own sites. The shape is what matters, not the decimal places: a wide, well-instrumented middle, a thin top, and a plateau exactly where local optimisation stops paying.

The adoption-versus-impact gap is not specific to warehousing. Cross-industry operations research has consistently found a wide distance between organisations running AI and organisations reporting operational impact — see McKinsey's operations insights (opens in a new tab). What is specific to the DC is the shape of the blocker. It is almost never model quality. It is that the model optimises a station while the line is governed by a constraint that has already moved, and that nothing in the execution stack is listening for the difference. WERC's warehousing research community (opens in a new tab), now part of MHI, has been documenting the same balancing problem in benchmarking terms since long before any of it was called AI.

Why fixing one station moves the bottleneck instead of removing it

The migration ledger: relieve a constraint here, and it reappears there. This is the centre of the page and the reason most warehouse AI projects under-deliver.

Fixing one station moves the bottleneck because a distribution centre is a connected line, not a collection of independent workstations. When the binding station stops binding, the constraint does not disappear — it transfers to whichever step is next-slowest under the new conditions, and the door sees only the difference between the old constraint's rate and the new one's. If those two rates are close, a large local improvement produces a small system improvement, which is exactly the pattern that gets warehouse AI programmes defunded at their second budget review.

An hour lost at a bottleneck is an hour lost for the entire system. An hour saved at a non-bottleneck is a mirage.
Eliyahu M. Goldratt and Jeff Cox, The Goal

The useful consequence is that constraint migration is predictable. Every relief action has a characteristic successor, because the physics of the building does not change: faster picking depletes the forward face faster, higher goods-to-person rates pull harder on induction, smoother release delivers more work to packing per hour. The ledger below is the migration map for a typical multi-zone DC. Read it before the project, not after — the column that matters is the fourth one.

Relieve this constraint	With this decision	System that owns it	The constraint usually moves to	The signal it has moved
Travel distance in the pick face	Re-slot by velocity, affinity and cube; re-slot on a cadence, not annually	WMS slotting module	Replenishment — the same fast movers now deplete faster than the replen task list can refill them	Replenishment backlog rising; pick-face stockouts per shift; pickers waiting at face
Pick rate at goods-to-person stations	Add GTP stations, add AMRs, raise presentation rate	WCS and fleet manager	Decanting and induction — the stations starve because upstream cannot feed them	Station idle time waiting for totes; induction queue empty while operators wait
Order release backlog and wave lumpiness	Waveless or continuous release against downstream buffer depth	WES	Packing and sortation — smoothing upstream simply delivers the work downstream sooner	Pack queue depth climbing; sorter recirculation rate rising; chute full conditions
Labour on the pick line	Flex staff in from other functions mid-shift	LMS and WMS	Receiving and putaway — the people came from somewhere, and that somewhere stopped	Dock-to-stock creeping up on the same shift; inbound trailers waiting at the door
Sorter or conveyor capacity	Re-balance induction, re-assign chutes, stagger merge priority	WCS	Loading and trailer availability — cartons reach the door faster than doors turn	Staged pallets waiting for a door; staging lanes at occupancy; trailer dwell rising
Dock and staging congestion	Predictive door and staging assignment against expected outbound profile	WMS and yard systems	Packing rate — the outbound plan is now waiting on pack output rather than on space	Staging lanes half empty while pack queue is deep; doors idle mid-shift
AMR or AGV fleet congestion	Zone weighting, traffic policy, opportunity-charge scheduling	Fleet manager and WCS	Effective fleet size late in the shift — congestion relief is often paid for in charge time	Robots queuing at chargers; available fleet by hour falling toward end of shift

The bottleneck migration ledger. Each row is a relief action, the successor constraint it typically creates, and the signal that tells you the transfer has happened. Pre-staging the successor in the same change is what turns a local gain into a throughput gain.

Two rows on that ledger deserve emphasis because they are the ones sites most often walk into. The first is the re-slot that starves replenishment: it is the single most common warehouse AI disappointment, and it is entirely avoidable by re-sizing the replenishment task list in the same change as the slotting move. The second is the fleet row, because it is counter-intuitive. Congestion relief in a robotised zone is frequently paid for in charge time — more movement per robot per hour means more energy per hour — so the constraint migrates from floor space to available fleet in the last two hours of the shift, where it is easy to misread as a demand spike.

Which throughput problem do you actually have?

Plot how stable your constraint is against how variable your demand is. The quadrant determines whether the answer is optimisation, capacity, rebalancing or a peak-specific policy — and only one of the four is solved by a better point model.

Optimisation problem

One station binds consistently; demand is predictable
Point optimisation genuinely pays here — and only here
Fix: optimise the binding station, then re-run the ledger

Capacity problem

Stable constraint, spiky demand
Smarter release will not create capacity you do not have
Fix: labour and shift plans, or capital, sized against the peak profile

Rebalancing problem

The constraint moves; volume does not
The commonest profile in multi-zone DCs
Fix: line model, interval constraint call, release and labour write-back

The peak trap

Moving constraint and spiky demand together
Where models trained on normal weeks do the most damage
Fix: peak-specific training window, wider bounds, human escalation

Constraint stability — top: The same station binds for weeks, bottom: The binding station moves within the shift

Demand variability — left: Steady week to week, right: Peak, promotions, client ramps

A last structural point that keeps the ledger honest. Some constraints are not permitted to be relieved by pushing harder. Pick rates, lift frequencies and carry distances sit inside ergonomic limits and safety rules, and a model that finds throughput by quietly raising the physical demand on people has found a liability, not a gain. Anything that changes what an operator does per hour should be checked against OSHA's warehousing guidance (opens in a new tab) and its ergonomics material (opens in a new tab), and anything that changes how robots and people share floor space against the mobile-robot safety standards maintained through A3 (opens in a new tab) and ISO 3691-4 for driverless industrial trucks. Treat those as constraints in the model, not as a compliance review afterwards.

The seven decisions that move throughput inside the four walls

Slotting, pick paths, release, labour, dock and staging, fleet orchestration and pack balancing — what each one owns, how fast it can move, and what AI actually adds.

Seven decisions move throughput inside a distribution centre, and their time constants differ by four orders of magnitude — from fleet routing that re-decides every few seconds to a slotting cycle that a site may run quarterly. That spread is the single most useful thing to know when sequencing a programme, because a decision can only relieve a constraint that persists at least as long as the decision takes to make and act on. Applying a weekly decision to a constraint that moves hourly is a common and expensive category error.

Decision	Time constant	System that owns it	What AI adds	Primary metric moved
Slotting and re-slotting	Weeks to quarters; continuous re-slot in advanced sites	WMS slotting module	Velocity, affinity and cube optimisation against forecast demand rather than last year's ABC classes, with a replenishment-load constraint built in	Travel distance per line; pick UPLH
Pick-path optimisation	Per task, seconds	WMS task engine, WES	Sequencing and batching that account for congestion and current zone load, not just shortest distance on an empty map	Travel distance per line; pick UPLH
Wave versus waveless release	Minutes to hours	WES	Release rate set against downstream buffer depth and predicted constraint, replacing a fixed wave plan built the night before	Order cycle time; pack idle minutes
Labour allocation and flex staffing	Within the shift, 15–60 minutes	LMS with WMS task data	A recommended move against the predicted binding station, with the outcome logged so the next recommendation is better	UPLH across the line; overtime hours
Dock and staging assignment	Hours	WMS and yard systems	Door and staging allocation against predicted outbound profile and pack completion, rather than first-come assignment	Dock-to-stock; trailer dwell; staging occupancy
Robot and AMR fleet orchestration	Seconds to minutes	Fleet manager, WCS	Zone weighting, traffic and congestion policy, and charge scheduling driven by where the constraint is now	Effective fleet size by hour; presentation rate at GTP
Packing-station balancing	Minutes	WES, pack automation	Station opening and carton-type routing matched to the arriving order mix rather than a fixed roster	Pack queue depth; order cycle time

The DC decision set. 'Time constant' is how often the decision can realistically be re-made and acted on; it determines which constraints the decision can relieve at all. Systems named are the usual owners, not the only possible ones.

Read that table with the ledger from the previous section beside it and a sequencing rule falls out. Start with the decisions whose time constant matches the constraint you actually have. A site whose constraint moves within the shift gets nothing from a better quarterly slotting run, no matter how good the optimiser; it needs release and labour. A site whose constraint has been the pick face for eight months straight should slot before it buys anything.

Slotting and re-slotting — the decision most often optimised in isolation
Slotting is where warehouse AI usually starts: clean data, a well-understood model, a dramatic local result. It also has the sharpest successor effect, because a re-slot that concentrates fast movers changes the replenishment load profile the day it lands. A slotting model with no replenishment constraint in it will happily propose a layout the replen team cannot sustain. The fix is one term in the objective, not a new project — but it has to be there before go-live, because the backlog builds within a fortnight and gets blamed on the replenishment team.
Wave versus waveless release — the cheapest lever, most often frozen
Release is the only decision here that costs nothing to change, needs no capital and reverts instantly, which makes it the natural first write-back. Waveless — releasing work continuously against downstream buffer depth rather than in planned batches — is usually sold as an efficiency change. It is better understood as a control change: it converts release from a plan into a feedback loop, so the line stops flooding and starving itself. The catch is that it removes the natural break points a site uses for reporting and labour scheduling, so the reporting must be rebuilt at the same time.
Labour allocation and flex staffing — the fastest relief available
Moving four people is faster than any other intervention in the building, and it is the lever supervisors already use. What AI adds is not the decision but the record: which move was made, against which constraint, and what happened afterwards. Sites that log flex moves against constraint calls for a single quarter routinely find a large share were made against a station that was not binding — good instincts applied to the wrong step. That log is also the dataset from which safe automated prompts are later derived; without it, bounds are guesswork.
Robot and AMR fleet orchestration — capacity is only useful where the constraint is
A mobile fleet is a pool of capacity that can be pointed anywhere, and most deployments point it at fixed zones set during commissioning. Constraint-aware zoning re-weights the fleet toward the binding area while it binds, which is where the throughput is. Three cautions: congestion is non-linear, so more robots in a zone can lower zone throughput; charging is a real constraint that shows up late in the shift; and any change to traffic policy in shared human-robot space is a safety change first and a throughput change second — the standards maintained through A3 (opens in a new tab) and the measurement work published by NIST's robotics programme (opens in a new tab) are the right reference points.
Packing-station balancing — the constraint everyone smooths into
Packing is the most frequent successor constraint in the ledger, because almost every upstream improvement delivers work to it faster. It is also where the mismatch between average and instantaneous capacity is largest: a pack line sized for the daily average will be underwater for two hours and idle for two others under a lumpy release. Balancing means opening and closing stations against the arriving order mix and routing carton types to the stations equipped for them — a scheduling problem with a short time constant and an immediate effect on order cycle time.

Peak season: when models trained on normal weeks tell you the wrong thing

Rate curves flatten, labour mix changes, the constraint moves faster than the retraining cadence — and the model is most confident exactly when it is most wrong.

Models trained on normal weeks mislead during peak because almost every relationship they encode changes shape at high utilisation. A station's throughput is roughly linear in labour up to a point and then flattens as congestion, aisle contention and queueing take over; a model fitted on the linear region will confidently extrapolate a rate the floor cannot achieve. The same applies to travel time, which rises non-linearly with picker density, and to robot fleet throughput, which peaks and then falls as a zone saturates.

The labour mix is different, and so is the rate curve
Peak labour is heavily weighted toward agency and seasonal staff working their first weeks, with a learning curve measured in shifts. A model that estimates station rates from a normal-week workforce will over-predict output per person for six to eight weeks, and the error is systematically largest at the busiest stations because that is where the new people are placed. The correction is not a fudge factor: it is a tenure or cohort feature in the rate estimation, and a separate rate curve for training weeks.
The constraint moves faster than the retraining cadence
In a normal week a DC's binding station may be stable for days. In peak it can move several times in a shift as promotions land, carrier cut-offs stack up and a single-item order profile displaces the usual basket. A weekly retrain cannot follow that. The workable pattern is to keep the line model's structure fixed and let the rate estimates update on a rolling window measured in hours, while any model that requires a full retrain is frozen and its output treated as a prior rather than an instruction.
Order profile shift breaks the slotting assumptions
Peak profiles are not the annual profile scaled up. Single-line orders spike, gift SKUs appear with no history, and affinity relationships that held all year are replaced by promotional bundles, so a slotting plan optimised on twelve months of data can be actively wrong in November. Sites that handle this well slot the peak zones separately, using last peak's profile plus this year's promotional plan, and accept a deliberately sub-optimal layout there for the rest of the year.
Bounds that were safe in March are not safe in November
Every automated move was bounded using evidence from normal conditions. At peak the consequence of an error is larger, recovery time is shorter and the escalation path is busier. The correct response is not to widen the bounds because the site is under pressure; it is to re-approve them explicitly before the ramp — narrower for anything safety-adjacent, wider only where the fallback is instant and cheap.

Likelihood: highImpact: medium

Peak weeks left in the training window unweighted

Six weeks of peak data inside a twelve-month training set pulls every rate estimate upward and teaches the model that high-density picking is fast. The result is a model that under-predicts congestion for the other forty-six weeks and over-predicts capacity during peak itself.

PreventionFlag peak intervals explicitly and either exclude them or model them as a separate regime. Never leave them in unlabelled.

Likelihood: mediumImpact: high

Automated release left running into a saturating pack line

A continuous release policy tuned against normal-week pack capacity keeps feeding a line whose effective rate has fallen because of new staff and carton-mix changes. Work-in-progress builds in front of pack, order cycle time collapses and the cut-off is missed with a full building.

PreventionBound release on observed downstream completion rate, not on a modelled capacity, and make the bound tighter during peak.

Likelihood: highImpact: medium

The escalation path is the same one used in a normal week

The system escalates correctly, to a supervisor who is already running two extra zones and a training group. The escalation is acknowledged and not acted on, so the policy appears to be working while the constraint persists for hours.

PreventionName a peak-specific escalation owner with no line responsibility, and track time-to-action on escalations as a metric in its own right.

There is a cultural version of this failure too, and it is worth naming because it is the one that ends programmes. Peak is when the site is least willing to trust a new decision source and most likely to switch it off — and switching it off during the six weeks that generate the most informative data is how a site arrives in January with a model that has never seen its own hardest conditions. The way through is to keep the system running in advisory mode through peak even where automation is paused: the recommendation is still generated, still logged, still compared against what the supervisor did. That log is the training set for next peak, and it costs nothing but discipline.

What balanced throughput looks like in public

Three publicly reported programmes, read against the ladder. None is an Atomic Loops engagement — each links to the operator's own published material.

The clearest public evidence for the balancing thesis is in what the largest operators chose to build, and in what they chose to change at the same time. In each case below the differentiator is not a single clever optimiser: it is that storage, retrieval, pick and release were changed together, so the relieved constraint had somewhere to go. Outcomes are as reported by the operators themselves and have not been independently audited here.

Three programmes read against the throughput ladder

Images are scene illustrations from our existing library, not photographs supplied or endorsed by these operators. Outcomes are as published by each operator; verify figures against the linked source before reusing them.

Scene illustration: automated fulfilment centre with robotic storage and retrieval

AmazonGlobal fulfilment network · hundreds of sites35

Challenge: In a very large fulfilment network, storage and retrieval, item handling and robot traffic each become the binding constraint at different times, and a point improvement in any one is absorbed by the next.
Approach: Amazon has published a sequence of changes that address the line rather than a station: containerised storage and retrieval (Sequoia), robotic item handling (Sparrow) and fleet-level coordination that routes mobile robots as a system rather than as independent agents.
Reported outcome: Amazon reports operating more than 750,000 mobile robots across its operations, and states that Sequoia identifies and stores inventory substantially faster while reducing the time to process an order at a fulfilment centre by up to 25%.; What it shows about the curveThe gain came from changing storage geometry and retrieval policy together. A faster picking robot alone would have moved the constraint to storage presentation; changing both is what let the improvement reach the order.

Amazon — robotics and operations news (opens in a new tab)

Scene illustration: dense automated grid storage in a grocery fulfilment centre

Ocado GroupOnline grocery technology · automated CFC operator and licensor35

Challenge: Grocery is the hardest order profile in warehousing: large multi-line baskets, three temperature regimes, short cut-offs and heavy substitution. Under those conditions pick rate, storage access and travel are not separable problems.
Approach: Ocado built the storage grid, the bot fleet and the pick decision as one system, with central control planning bot routes and cell access together rather than optimising picking against a fixed layout. The platform is licensed to grocers internationally, so it has to work as a repeatable configuration rather than a one-site build.
Reported outcome: Ocado reports that its automated grid picks a typical 50-item grocery order in a matter of minutes, and publishes ongoing platform and operating detail in its investor material.; What it shows about the curveWhen storage, travel and pick are optimised as one objective there is no successor constraint to migrate to inside that loop. That is the stage 5 signature, and it is a design decision made years before the software.

Ocado Group (opens in a new tab)

Scene illustration: contract logistics warehouse with mixed automation and manual stations

GXO LogisticsContract logistics · warehousing across hundreds of sites24

Challenge: A contract logistics operator runs many buildings for many clients with different order profiles, systems and contract lengths. A bespoke balancing programme per site would never amortise, and per-client optimisation cannot be reused.
Approach: GXO has publicly described deploying automation and robotics as a repeatable, portable capability across its warehouse estate — standard technology packages moved between sites and clients — rather than as bespoke per-contract engineering.
Reported outcome: GXO reports continuing expansion of robotics and automation across its sites, with deployment and performance updates published in its news and investor material.; What it shows about the curveThe stage 4 signature for a multi-site operator is that the marginal cost of balancing the next building falls. Where each site is a fresh project, the programme plateaus however good any single deployment is.

GXO Logistics — news (opens in a new tab)

Read together, the three make a single point about sequence. Amazon and Ocado both changed the physical relationship between storage and picking before they optimised picking, which is why their improvements had nowhere to leak. GXO's constraint is different in kind — it is the cost of repeating the work across an estate — and the answer is portability rather than depth. Most operators reading this page are closer to GXO's problem than to Ocado's, and should ask what part of their balancing work is reusable in the next building before they perfect it in this one.

The reference architecture: WMS, WES, WCS and the constraint model

What has to exist at each stage, where the constraint model sits in the existing stack, and which layer you can defer.

A balanced line needs five layers, and the crucial architectural decision is that the constraint model sits beside the execution stack rather than inside it. WMS, WES and WCS already exist in most buildings and already own the decisions; what is missing is a layer that observes all three on one clock, decides where the constraint is, and writes a target back into whichever of them owns the relevant lever. Building the constraint model inside a WMS customisation is the single most common way to make it un-upgradable.

Layers required by stage

Each layer is annotated with the stage that first requires it. A site trying to reach stage 4 without the telemetry and write-back layers is running a stage-3 point optimiser with a nicer report.

Floor and automation
Stage 1+
- WCS and equipment controllersConveyor, sorter, AS/RS — the layer that actually moves things
- Fleet managerAMR and AGV allocation, traffic and charging
- Scanning and identificationBarcode, RFID and vision events at every handoff
→
Execution and orchestration
Stage 1+
- WMSInventory, orders, task generation, slotting master data
- WESRelease, sequencing and balancing across manual and automated work
- LMSEngineered standards, clock data, flex assignments
→
Throughput telemetry
Stage 2+
- Event capture on one clockWMS tasks, WCS state and labour joined at interval resolution
- Buffer and queue samplingDepth at every accumulation point, at least every 15 minutes
- Shared event vocabularyConsistent what/when/where/why semantics across systems
→
Constraint model
Stage 3+
- Line representationStation rates, buffer capacities, feed relationships
- Binding-station callPer interval, with a confidence and a successor prediction
- Point optimisers underneathSlotting, pick paths, fleet routing — all taking targets from the line model
→
Write-back and policy
Stage 4+
- Release service into the WESRate or wave shape, with an instant revert to the fixed plan
- Labour and fleet targetsPrompts into the LMS and zone weights into the fleet manager
- Bounds, escalation and audit logVersioned policy; every automated move reconstructable

Pipeline described

Floor and automation (stage 1+) — WCS and equipment controllers: Conveyor, sorter, AS/RS — the layer that actually moves things; Fleet manager: AMR and AGV allocation, traffic and charging; Scanning and identification: Barcode, RFID and vision events at every handoff
Execution and orchestration (stage 1+) — WMS: Inventory, orders, task generation, slotting master data; WES: Release, sequencing and balancing across manual and automated work; LMS: Engineered standards, clock data, flex assignments
Throughput telemetry (stage 2+) — Event capture on one clock: WMS tasks, WCS state and labour joined at interval resolution; Buffer and queue sampling: Depth at every accumulation point, at least every 15 minutes; Shared event vocabulary: Consistent what/when/where/why semantics across systems
Constraint model (stage 3+) — Line representation: Station rates, buffer capacities, feed relationships; Binding-station call: Per interval, with a confidence and a successor prediction; Point optimisers underneath: Slotting, pick paths, fleet routing — all taking targets from the line model
Write-back and policy (stage 4+) — Release service into the WES: Rate or wave shape, with an instant revert to the fixed plan; Labour and fleet targets: Prompts into the LMS and zone weights into the fleet manager; Bounds, escalation and audit log: Versioned policy; every automated move reconstructable

Step-by-step insights

Floor and automation — the layer you do not rebuild: The WCS and fleet manager are usually vendor systems with defined interfaces and a support contract, so the correct posture is to read heavily and write narrowly. Read everything: equipment state, occupancy, fault codes, robot positions, charge levels. Write only the small set of targets the vendor supports as configuration — zone weights, chute assignments, induction rates. A programme that needs to modify controller behaviour has picked the wrong lever and will spend its schedule in a vendor change queue.
Execution and orchestration — the WES is where throughput decisions belong: The commonest architectural confusion here is between the WMS and the WES. The WMS is the system of record for inventory, orders and tasks; the WES releases, sequences and balances work across manual and automated resources in real time. Throughput decisions belong in the WES, and sites without a distinct WES layer usually have that logic buried in WMS customisations or in the sorter controller, where it cannot see the whole line. Finding out where release logic actually lives today is the first architectural question worth asking.
Throughput telemetry — one clock, or none of this works: Every downstream layer depends on WMS task events, WCS state and labour data agreeing about time. In practice they rarely do: different systems, different clocks, and three different definitions of when a task 'completed'. Getting to one clock at interval resolution is unglamorous integration work and the highest-value engineering on this list, because every layer above inherits whatever ambiguity is left here. A shared event vocabulary — one consistent way of recording what happened, when, where and why — is what stops the joins becoming a bespoke reconciliation script per system.
Constraint model — keep it explainable and keep it separate: The constraint model is a small service that consumes telemetry and emits a binding-station call plus a successor prediction. Two design rules matter more than the algorithm. It must be explainable on the floor: a supervisor who disagrees should see the station rates and buffer depths that drove the call and be able to argue with them, because that argument is how the model gets fixed. And it must live outside the WMS and WES as its own deployable, so it updates weekly without an upgrade window and the point optimisers subscribe to it rather than duplicating it.
Write-back and policy — the revert is what unlocks the approval: The component most often skipped is the instant revert to the fixed wave plan and commissioned fleet zoning. It looks like engineering pessimism; it is the political key that unlocks the write-back, because a site GM will accept a new decision source they can switch off in one action during a bad shift. A release write-back without a drilled revert sits in a change queue for two quarters. One with it, demonstrated on a quiet shift in front of the operations team, ships.

One integration note that saves months. The telemetry layer benefits enormously from a shared event vocabulary — a consistent way of saying what happened, when, where and why across systems that were never designed to agree. GS1's EPCIS standard (opens in a new tab) is the established option and it is worth adopting even if only internally, because it forces the what/when/where/why structure onto every feed and makes the joins deterministic. Sites that skip this end up with a bespoke reconciliation script per system, which is exactly the artefact that stops the second building from being cheap.

A 90-day plan: follow the moving constraint on one outbound shift

The stage 3 → 4 transition made concrete on one DC, one outbound cut-off, one shift. Contains no new optimisation model.

Moving one stage takes about 90 days when it is scoped to a single shift in a single building, and several years when it is scoped to a network. To make that concrete, the plan below runs the transition on a specific and very common problem: an outbound cut-off that is missed intermittently because the constraint moves between picking, packing and loading during the afternoon, and every function is optimising its own metric. Most stage-3 sites already own the point optimisers, so this quarter contains no new model development at all — the work is telemetry, a line model and one write-back.

Stage 3 → stage 4 on one outbound cut-off, in one quarter

One DC, one shift, one cut-off, one named owner. If a phase needs longer than its window, narrow the scope — one zone rather than the building — rather than extending the plan.

Days 1–20
Instrument the line and build the constraint record
Pick one building and the shift that owns the problem cut-off. Join WMS task confirmations, WCS and fleet telemetry and LMS clock data onto one clock at 15-minute resolution, and sample buffer depth at every accumulation point. Publish a daily constraint record: which station was binding, for how long, and what the site did about it. Name the site's operations manager as owner — the cut-off is their number.
A per-interval record of where the constraint was, for 20 shifts
Days 21–45
Model the line and score the constraint call
Build a simple line representation — station rates from recent history, buffer capacities from the layout, feed relationships from the process map — that emits a binding-station call each interval plus a successor prediction. Score it against the record from phase one and against the supervisors' own judgement. Do not write anything to any system yet; the only deliverable is a call operations agrees with.
A constraint call operations accepts roughly four shifts in five
Days 46–70
Write one decision back into the WES
Take the cheapest lever first: release rate against downstream buffer depth, written into the WES as a proposed rate the supervisor approves, plus a flex-labour prompt on the board they already use. The fixed wave plan stays one switch away as the fallback, and the revert is drilled deliberately on a quiet shift before it is ever needed in anger. Log every recommendation, every approval and every override.
Release and labour recommendations live, with a drilled revert
Days 71–90
Attribute in lines per hour and cut-off misses
Hold out a comparable shift or a comparable zone on the fixed plan. Report the difference in units per labour hour across the line, cut-off misses, pack idle minutes and order cycle time — not model accuracy, and not the improvement in any single station's local metric. This is the number that funds the next building.
A throughput and cut-off delta the site GM and the CFO both accept

The order matters, and these three are the reason

Measure the whole line before optimising any station
A point optimiser deployed before the constraint record exists is aimed by anecdote. Twenty shifts of interval-level data usually reveal that the station everyone complains about is binding far less often than the one nobody mentions, and that changes which optimiser is worth buying.
Release before slotting, always
Release costs nothing to change, needs no capital, reverts instantly and has a time constant that matches a constraint moving within the shift. Slotting is slower, more disruptive and has a successor effect on replenishment that needs its own preparation. Prove the loop on release, then use the credibility to fund the slower decisions.
Approval before autonomy
Keep the supervisor's approval through the whole quarter even where automated release is technically possible. The approval log — which recommendations were accepted, which overridden, and what happened afterwards — is the dataset that sets safe bounds later. Sites that skip straight to automation have no such log and end up bounding by guesswork, usually just before peak.

Two scoping rules keep this plan honest. The holdout is not optional: without a comparable shift or zone left on the fixed plan, seasonality, order-mix drift and a new client ramp will all claim credit or take blame, and the day-90 number will not survive its first challenge. And the owner must be the person whose targets contain the cut-off. A programme owned by an analytics team produces a report at day 90; a programme owned by the operations manager produces a changed shift.

The measurement stack: what to instrument, from what system, how often

Every throughput metric reduces to timestamps and counts your systems already record. The build sheet, the cadence, and the readiness checklist.

The measurement stack for warehouse throughput is four layers deep, and every metric in it reduces to timestamps and counts the WMS, WCS or LMS already writes. Layer one is output — units and lines completed per station per interval. Layer two is efficiency — the same output divided by labour hours actually on the station. Layer three is flow — queue depth, travel distance and congestion, which tell you where the work is waiting. Layer four is the customer-facing result — order cycle time, dock-to-stock and cut-off performance, which is the only layer anyone outside the building cares about. Report all four or you will optimise one at the expense of another.

Metric	Definition / read	Source system	Cadence	Reads the constraint
Units per labour hour (UPLH)	Units or lines completed ÷ labour hours actually on the station in the interval	WMS task log joined to LMS clock	15 minutes	Falls at the binding station only if it is starved; stays high if it is genuinely saturated
Station output rate	Completed tasks per station per interval, independent of labour	WMS task log, WCS counters	15 minutes	The direct input to the binding-station call
Queue and buffer depth	Units waiting at each accumulation point	WCS occupancy, periodic counts, vision	5–15 minutes	The single most direct observation — depth grows in front of the constraint
Travel distance per line	Distance travelled ÷ lines picked, by zone	WMS task locations, AMR telemetry	Per shift	High travel means the constraint is slotting or path, not labour
Congestion index	Observed rate ÷ modelled uncongested rate for the same density	WCS, fleet manager, line model	15 minutes	Separates 'slow station' from 'blocked station' — the distinction that decides the fix
Replenishment backlog	Open replen tasks vs the rate needed to keep the face full	WMS	Hourly	The classic successor constraint after a re-slot
Effective fleet size by hour	Robots available and productive ÷ fleet size	Fleet manager	Hourly	Reveals charge-time constraint hiding as an end-of-shift demand spike
Dock-to-stock	Trailer arrival to inventory available in the WMS	Yard system and WMS	Per receipt	Rises when inbound labour has been flexed out to relieve outbound
Order cycle time	Order release to load complete, by profile	WMS and WES	Per order	The check that throughput was not bought with work-in-progress
Cut-off performance	Orders completed before carrier cut-off ÷ orders due	WMS and WES	Per cut-off	The only number the customer experiences; everything above explains it

Instrumentation build sheet for DC throughput. 'Reads the constraint' says what the metric actually tells you about where the line is binding. Definitions follow the SCOR reference model where one exists.

Three disciplines make the stack trustworthy. First, always report UPLH beside station output rate — a station can look efficient because it is understaffed and waiting. Second, always report order cycle time beside throughput, because batching harder raises one and damages the other, and a site optimising throughput alone will not notice until a customer does. Third, use the standard definitions where they exist: the SCOR reference model (opens in a new tab) defines dock-to-stock and order cycle time in a way that survives comparison with other buildings, and WERC's benchmarking work (opens in a new tab) is the closest thing warehousing has to a shared metric dictionary. A metric you have defined yourself cannot be benchmarked and will be redefined the moment it becomes inconvenient.

Balanced-line readiness checklist

Eight conditions separate a locally optimised DC from a balanced one. If you cannot tick them all, you are at stage 3 however good any individual optimiser is. Tick as you go — this list works without JavaScript.

Every station's output rate is measured, not assumedFrom task confirmations and WCS counters, at interval resolution.
Queue and buffer depth is sampled at least every 15 minutesAt every accumulation point, including staging lanes.
The binding constraint is named per interval, in writingBy a model or a person — but written down and scored afterwards.
The successor constraint is predicted before a relief action lands
Release rate can be changed inside the shift without rebuilding the waveIf this needs IT help, release is not a usable lever yet.
Labour moves are logged against the constraint they were meant to relieve
Robot or AMR zone weighting follows demand, not commissioningIncluding charge windows, which are a constraint in their own right.
A holdout shift or zone stays on the fixed planOtherwise no improvement can be attributed and none will survive review.

0 of 8 ticked

Tick honestly — the empty list is data too

Most stage-2 sites can genuinely tick one or two of these, not zero. If none apply, do not start with tooling: run the 90-day plan above on one shift and one cut-off. Six of these eight fall out of doing that once; the other two are policy decisions rather than engineering.

Scope the 90 days with us

Failure modes that quietly give the throughput back

Throughput gains are not permanent. Five regressions account for almost all of the erosion, and every one of them is silent.

Throughput gains erode silently, which is what makes them hard to defend at the next budget review. Nothing breaks; the line simply drifts back toward the rate it had before, one small unmaintained assumption at a time. Five regressions account for almost all of it, and each has a cheap preventive measure that costs less than the quarterly review meeting spent arguing about why the numbers moved.

Likelihood: highImpact: medium

The slotting plan ages and nobody re-runs it

SKU velocity drifts continuously — new lines, seasonal ranges, promotions, discontinuations. A slotting plan optimised once and left alone degrades from the day it lands, and because the degradation is gradual it never triggers an alarm. Within a year travel per line can be back where it started while the site still describes itself as 'slotted'.

PreventionRe-run slotting on a cadence tied to velocity drift, not to the calendar, and alert when the drift metric crosses a threshold.

Likelihood: highImpact: high

The line model is not updated after a physical change

A mezzanine goes in, a pack station is added, a conveyor spur is re-routed. The physical line has changed and the model has not, so its binding-station call is now systematically wrong in exactly the area that changed. Supervisors notice within a fortnight, stop trusting it, and go back to judgement — quietly, without anyone recording that the system was abandoned.

PreventionPut the line model on the engineering change checklist alongside the layout drawing and the fire plan. No physical change closes until the model is updated.

Likelihood: mediumImpact: high

The constraint owner leaves and the record stops

The daily constraint record depends on one person publishing it. They move to another site, the record stops appearing, and within two months nobody can say where the constraint has been. The models keep running and the decisions keep being made, but the evidence that they are correct has quietly disappeared.

PreventionAutomate publication of the constraint record and put its ownership in the leaver checklist alongside system credentials.

Likelihood: mediumImpact: high

Throughput is bought with work-in-progress and nobody is watching cycle time

Batching harder raises lines per hour and lengthens order cycle time. Reported on throughput alone, this reads as an unambiguous win for months — until late orders, expedited freight and a customer complaint arrive together and the improvement is reversed wholesale.

PreventionNever report throughput without order cycle time beside it, on the same board, for the same period.

The common thread is that every one of these is a maintenance failure rather than a design failure. The system was built correctly and then the building changed around it. Sites that hold their gains treat the line model and the constraint record as operational assets with owners, review cadences and change control — the same way they treat the layout drawing, the fire plan and the maintenance schedule. Sites that treat them as project deliverables get eighteen good months and a difficult conversation.

Glossary

Hover a term for its definition — or expand the map full screen. The full definitions are written out below.

Throughput: The rate at which a distribution centre converts open orders and inbound receipts into completed, loaded shipments — counted in order lines or units per hour, per shift or per labour hour. A property of the whole line, never of a single station.
Binding constraint: The station or resource currently limiting the line's output. A DC has exactly one at a time, it moves across a shift, and every hour lost at it is an hour lost at the door.
Constraint migration: The predictable transfer of the binding constraint to a downstream or upstream neighbour once the original constraint is relieved. The reason a large local improvement often produces a small system improvement.
Units per labour hour (UPLH): Units or lines completed divided by labour hours actually worked on that station in the interval, including partial hours and training time. Meaningless without the labour join, and misleading without station output rate beside it.
Dock-to-stock: Elapsed time from trailer arrival at the receiving door to inventory being available for picking in the WMS. The headline inbound metric, and the first place flexing labour out of receiving shows up.
Order cycle time: Elapsed time from order release to load complete, by order profile. Reported next to throughput so that speed bought by batching harder and accumulating work-in-progress is visible rather than hidden.
Slotting: Assigning SKUs to storage locations by velocity, affinity, cube and handling characteristics. Re-slotting is doing it again as demand drifts; both change the replenishment load profile as a direct consequence.
Wave and waveless release: Wave release issues work to the floor in planned batches; waveless release issues it continuously against downstream buffer depth. The move from one to the other converts release from a plan into a feedback loop.
Warehouse execution system (WES): The layer that releases, sequences and balances work across manual and automated resources in real time. Distinct from the WMS, which is the system of record for inventory, orders and tasks. Throughput decisions belong in the WES.
Warehouse control system (WCS): The equipment layer beneath the WES — conveyor, sortation, AS/RS and controller interfaces. The source of the congestion and occupancy telemetry that distinguishes a slow station from a blocked one.
Congestion index: Observed station or zone rate divided by the modelled uncongested rate at the same density. Separates 'this station is slow' from 'this station is blocked', which call for entirely different fixes.
Effective fleet size: The share of a mobile robot fleet available and productive in a given hour, after charging, faults and queueing. Frequently the real constraint late in a shift, and easily misread as a demand spike.

Frequently asked questions

The questions operations and engineering leads ask most often when they start treating throughput as a constraint problem rather than a station problem.

How do you actually maximise warehouse throughput with AI?

By closing a control loop rather than optimising a station. Sense every station and buffer on one clock at interval resolution, decide which station is binding now and which becomes binding once it is relieved, and act through the levers that can move inside a shift — release rate, flex labour, pick paths, fleet zoning, dock and staging assignment. Point optimisers such as slotting or pick-path models sit underneath that loop and take their targets from it. Deployed without it, they improve a local metric and the door frequently sees nothing.

Why did our slotting project improve pick rate but not shipped volume?

Because the constraint moved. Concentrating fast-moving SKUs shortens travel and raises pick rate, and the same SKUs are then depleted faster than the replenishment task list — sized against the old pick rate — can refill the face. Replenishment becomes the binding constraint, usually within a fortnight, and it is normally attributed to the replenishment team rather than to the slotting change. The fix is to re-size the replenishment load in the same change as the slotting move, and to put a replenishment constraint into the slotting objective before go-live.

What is the difference between a WMS, a WES and a WCS for throughput work?

The WMS is the system of record for inventory, orders and task generation. The WES releases, sequences and balances work across manual and automated resources in real time. The WCS drives the equipment — conveyor, sortation, AS/RS. Throughput decisions belong in the WES, which is why the first architectural question worth asking is where your release logic actually lives today. In many sites without a distinct WES it is buried in WMS customisations or in the sorter controller, where it cannot see the whole line.

Should we move from wave release to waveless?

Usually yes, and it is the cheapest first write-back available: no capital, instant revert, and a time constant that matches a constraint moving inside the shift. Waveless releases work continuously against downstream buffer depth instead of in planned batches, which stops the line flooding and starving itself. The one real catch is reporting: waves provide natural break points that supervisors use for pace and for labour scheduling, so the reporting and the shift rhythm have to be rebuilt at the same time or the floor loses its sense of progress.

Which throughput metrics should a DC actually track?

Ten cover most buildings, in four layers. Output: station rate and units per labour hour by interval. Efficiency and flow: queue and buffer depth, travel distance per line, congestion index, replenishment backlog and effective fleet size by hour. Customer-facing: dock-to-stock, order cycle time and cut-off performance. Report UPLH beside station rate so an understaffed station does not look efficient, and always report order cycle time beside throughput so that speed bought with work-in-progress is visible.

How do we know which station is the bottleneck right now?

Queue depth is the most direct observation: work piles up in front of the constraint and thins out behind it. Station output rate and the congestion index refine that call by separating a genuinely saturated station from one that is merely blocked or starved. A simple line model — station rates, buffer capacities, feed relationships — turns those observations into a named binding station per interval plus a prediction of its successor. The model does not need to be sophisticated; it needs to be explainable enough that a supervisor can argue with it at 14:00.

Do we need robots to raise throughput?

No, and buying them before the line is instrumented is a common way to spend capital on the wrong station. Release, labour allocation and slotting are software and policy changes with immediate effect, and they routinely release capacity that was already in the building. Automation makes sense when the constraint has been stably at one physical step for a sustained period and the ledger says relieving it will not simply promote a neighbour. Instrument first; the equipment decision becomes cheaper and better aimed, and some of it stops being necessary.

Why do our models get worse during peak?

Because peak breaks the relationships they encode. Station throughput is roughly linear in labour until congestion takes over, and a model fitted on normal weeks extrapolates a rate the floor cannot reach. The labour mix shifts toward new starters with a learning curve measured in shifts, the order profile changes shape rather than just growing, and the constraint can move several times in a single shift. Handle it by flagging peak intervals as a separate regime, updating rate estimates on a rolling window measured in hours, and re-approving bounds explicitly before the ramp.

How long does it take to go from locally optimised to balanced end to end?

About 90 days when scoped to one building, one shift and one cut-off, with a named operations owner. The work is telemetry, a line model and one write-back — not new model development, because most stage-3 sites already own capable point optimisers. Scoping the transition to a whole network instead of a single shift is what turns 90 days into two years. If a phase runs long, narrow the scope to one zone rather than extending the calendar.

How do we prove the throughput improvement was real?

Hold out a comparable shift or zone on the fixed plan and compare. Without a holdout, seasonality, order-mix drift, a new client ramp and a change in labour mix will all claim credit or take blame, and the number will not survive its first serious challenge in a capital review. Report the difference in units per labour hour across the whole line, cut-off misses, pack idle minutes and order cycle time — deliberately not the improvement in any single station's local metric, which is the number that misled the project in the first place.

Does raising throughput conflict with safety and ergonomics?

It can, and a model that finds throughput by quietly raising the physical demand on people has found a liability rather than a gain. Pick rates, lift frequencies and carry distances sit inside ergonomic limits, and any change to how robots and people share floor space is a safety change first. Treat those limits as hard constraints inside the optimisation rather than as a review afterwards, check changes against OSHA's warehousing and ergonomics guidance, and hold shared-space traffic policy to the mobile robot safety standards maintained through A3 and ISO 3691-4 for driverless industrial trucks.

How is this different from optimising freight and carrier decisions?

Everything on this page stops at the loading dock. Throughput inside the four walls is a constraint-balancing problem across receiving, replenishment, picking, packing, sortation and loading, decided in the WMS, WES and WCS on time constants from seconds to weeks. Carrier selection, load matching and freight pricing are network decisions made in a TMS against a market, with different data, different economics and a different failure mode. The two programmes share a data foundation and almost nothing else, and conflating them is how sites end up with a transport model that cannot see the dock.

About the author

Atomic Loops Engineering

Industrial AI practice

Atomic Loops builds production AI systems for logistics, manufacturing and energy operators — forecasting, optimisation, vision and decision support running against live operational data and written back into the WMS, WES and WCS layer rather than delivered as dashboards.

· Throughput and balancing work across ambient, cold-chain and e-commerce DCs
· Integration-first delivery: WES write-back, monitoring, drilled rollback
· Measurement built from WMS, WCS and labour telemetry, not self-report
· 15 cited sources on this page

Sources

AI adoption and the maturity curve in logisticsWhich adoption and value KPIs are honest at each stage — the measurement discipline that keeps a throughput programme funded.AI readiness and transformation roadmap for logisticsSequencing decisions across a network of buildings, and what makes the second site cheaper than the first.Logistics industry practiceProduction AI systems Atomic Loops has built for warehousing, freight and last-mile operators.

Find the constraint that is actually capping your line

We rebuild your constraint record from WMS, WES and WCS telemetry, build the migration ledger for your building, and leave you with a costed 90-day plan for the first relief action that will reach the door. You keep the ledger and the plan whether or not we build it.

Book a throughput review See our logistics work

Published 14 August 2026 · Last updated 14 August 2026

Key takeaways

Abbreviations used on this page

Score your DC on the throughput ladder

What warehouse throughput is, and why a DC has one binding constraint at a time

The five stages of throughput maturity, in detail

Reactive

Measured

Optimised locally

Balanced end to end

Continuously self-balancing

Where distribution centres actually sit on the throughput ladder

Why fixing one station moves the bottleneck instead of removing it

The seven decisions that move throughput inside the four walls

Peak season: when models trained on normal weeks tell you the wrong thing

Peak weeks left in the training window unweighted

Automated release left running into a saturating pack line

The escalation path is the same one used in a normal week

What balanced throughput looks like in public

The reference architecture: WMS, WES, WCS and the constraint model

Floor and automation

Execution and orchestration

Throughput telemetry

Constraint model

Write-back and policy

A 90-day plan: follow the moving constraint on one outbound shift

The order matters, and these three are the reason

The measurement stack: what to instrument, from what system, how often

Failure modes that quietly give the throughput back

The slotting plan ages and nobody re-runs it

The line model is not updated after a physical change

The constraint owner leaves and the record stops

Throughput is bought with work-in-progress and nobody is watching cycle time

Glossary

Frequently asked questions

How do you actually maximise warehouse throughput with AI?

Why did our slotting project improve pick rate but not shipped volume?

What is the difference between a WMS, a WES and a WCS for throughput work?

Should we move from wave release to waveless?

Which throughput metrics should a DC actually track?

How do we know which station is the bottleneck right now?

Do we need robots to raise throughput?

Why do our models get worse during peak?

How long does it take to go from locally optimised to balanced end to end?

How do we prove the throughput improvement was real?

Does raising throughput conflict with safety and ergonomics?

How is this different from optimising freight and carrier decisions?

About the author

Sources

Related reading

Find the constraint that is actually capping your line