Here's the thing about WCS task arbitration: it's not about how fast your equipment is. It's about who gets the green light when three machines all want the same conveyor at the same time. Most warehouses hand-wave this problem. They default to first-in-first-out because it looks fair, and then peak season quietly eats 15 to 20 percent of their throughput. I've seen too many projects where the equipment list was all top-shelf gear, and the whole thing stumbled on this one little piece of logic.
This cuts two ways. Get arbitration wrong and you lose efficiency. Get it badly wrong and the whole line locks up. I've got two stories, both from real floors, both about "everyone wants the tote at once."
The first one is a fulfillment DC outside Columbus, Ohio, commissioned right before the 2023 peak. Three continuous vertical lifts feeding totes out of a three-level shuttle system, all merging into one main trunk conveyor, then into a loop sorter. Each lift rated at 450 totes per hour — 1,350 combined. The sorter could do 1,600 an hour. On paper, plenty of headroom.
First week of peak, it fell apart. Arbitration at the merge was plain FIFO: whoever arrived first got onto the trunk. The catch was that the three lifts didn't discharge evenly. Lift A served a high-density pick zone and fired totes in dense bursts; B and C were erratic. Under FIFO, A's totes jammed the merge solid. The trunk conveyor was nothing but Lift A totes. B and C's totes queued at the merge — some waited over 40 seconds — and the backup ran all the way up to the lift discharge, forcing lifts to stop. Meanwhile the sorter was starving: it kept waiting on B and C's totes, because those zones held most of the same-day-cutoff orders, SLA locked to a 4 PM ship time. Sorter utilization dropped into the low sixties.
The first instinct on site was "we need another lift." We stopped that order and spent an afternoon in the WCS logs instead. The conclusion stung: nothing wrong with the equipment — FIFO only understands arrival order. It doesn't know about order cutoffs, and it doesn't know the sorter is going hungry. The fix: switch arbitration from FIFO to cutoff-weighted. Every task carries the countdown to its wave's cutoff; the closer the cutoff, the higher the priority. Plus a minimum guaranteed quota per lift so no machine gets fully starved. That same night, with the same order volume, sorter utilization was back above 90 percent, and on-time rate for cutoff orders climbed from 91 percent back past 99.
The second story is a fashion returns warehouse in Indianapolis, 2021 — no lifts this time, two returns-inspection lines, each with its own conveyor, merging into one trunk into pack-out. The conflict window was the returns peak, 2 to 4 PM daily. Arbitration there was static priority: Line 1 always beat Line 2, because Line 1 handled high-value goods. Somebody in management decided that once, and it stayed forever.
Static priority is rational on the whiteboard and rigid on the floor. At peak, Line 1 ran almost nonstop, and Line 2's cartons waited minutes at the merge. Returns inspection is piece-rate work — Line 2's inspectors stood around with nothing to scan while Line 1's inspectors drowned and their error rate crept up. The irony: Line 2 handled lower-value goods, but its turnaround fed the resale platform directly, and that margin was actually higher. Within a month, Line 2's per-person throughput dropped about 30 percent, and the two shifts nearly came to blows.
The fix here wasn't a fancier algorithm — it was a starvation circuit breaker. Any task waiting at the merge longer than 90 seconds automatically jumps to top priority and cuts the line once. A few lines of PLC code. But Line 2 never starved for long again, and the load split between the two lines converged from roughly 3-to-1 to close to 1.2-to-1.

Now let me lay out the five arbitration strategies I've actually seen in the field, with what each one costs you:
| Strategy | Logic | Strength | Cost / risk | Fits |
|---|---|---|---|---|
| FIFO | Whoever arrives at the merge first goes first | Simple, easiest in PLC | At peak, one line monopolizes the trunk, others starve | Balanced flow, lines with similar rhythms |
| Static priority | Hard-coded: Line 1 always beats Line 2 | Deterministic, easy to troubleshoot | Low-priority lines starve at peak | Huge value gap between lines, stable flow |
| Cutoff-weighted | Dynamic ranking by order/SLA countdown | Protects urgent orders, saves peak season | WCS needs real-time order-level data | E-commerce fulfillment, multi-wave cutoffs |
| Starvation-aware round robin | Rotate admission, auto-escalate long waiters | Fair, starvation-proof | Slightly lower peak throughput than throughput-max | Parallel lines feeding manual workstations |
| Throughput-maximized | Always pick the lowest switchover-cost task | Highest cartons per hour | Systematically punishes slow lines, worst fairness | Pure pass-through hubs with no SLA pressure |
The trade-off is right there in the table: no strategy is free. FIFO is cheap to build and expensive in peak capacity. Cutoff-weighted saves your SLA but costs you the data integration between WCS and the order system. Throughput-maximized gives you the prettiest numbers and the angriest operators on the slow line. My rule: figure out what your real constraint is first. Afraid of missing cutoffs? Go cutoff-weighted. Afraid of starving a line? Add the starvation breaker. Afraid of both? Combine them. Never start with the most complex algorithm — complexity is itself a failure mode.
One more thing people get wrong: where should arbitration live? I've seen it written into the PLC "for speed." The PLC is fine for millisecond interlocks, but arbitration is a strategy problem — it needs order cutoffs, wave status, equipment health, none of which the PLC can see. The right layering: the WCS owns the strategy, recalculating dynamic priorities every one to two seconds and handing them down; the PLC only executes, admitting totes at the merge per the priority it received, and handling millisecond-level safety events like photo-eye faults on its own. Layered this way, you can also tune parameters online — one set for peak, one for off-season — without stopping the line to reprogram the PLC. Mixing strategy and execution together is why a lot of arbitration logic gets messier every time someone "tunes" it.
And here's the counterintuitive one, the judgment that gets me argued with every time: sometimes, deliberately starving your fastest machine for a few seconds raises total throughput. The bottleneck at a merge isn't any single machine's speed — it's the continuity of flow on the trunk. A lift doing 450 totes an hour, left alone at the merge, chops the trunk into stop-and-start segments. Hold it for ten seconds, let the other two lifts' totes interleave, and the flow smooths out — the sorter's induct utilization goes up. Local optimum plus local optimum often equals global worst. Arbitration is fundamentally the art of choosing between the two.
Last piece of advice: finishing the arbitration logic is the starting line, not the finish. Replay it against real peak-season WCS logs — look at the wait-time distribution per machine at every merge, look for long-tail waits, look at the actual release order of SLA orders. The prettiest logic on paper won't survive one real peak replay. Every symptom of bad arbitration is already written in your logs. The question is whether you're willing to read them.
By Lao Mi, Supply Chain Veteran (20 yrs)






