Should humans get completely out of the way once the WES goes live? I've watched two warehouses answer that question wrong in opposite directions. In one, supervisors manually tweaked waves every single day until the system was an expensive paperweight. In the other, a conveyor jammed and sat there for half an hour because nobody dared take over, while orders rotted in the queue. Both paid tuition.
Let's get the geography right first. A WES sits between the WMS and the automation layer — the WCS, conveyors, AMRs. The WMS tells it what needs to ship today and on which loads; the WES breaks those orders into tasks and releases them on rhythm to the sorters, bots, and pick stations. It's the traffic cop of execution and release. It handles 95% of the routine beautifully. But the remaining 5% is the exception pile, and even traffic cops have to admit when they need a human.
The question was never "should humans intervene." It's "does the intervention have a process." Who has the authority, in which scenarios, and did it leave a trace in the system — if those three aren't written down, an intervention is just sabotage with good intentions. Here are the five boundaries where I believe human hands still belong.
Wave release: the 30 minutes before cut-off belong to the supervisor
WES wave-release logic is usually fixed: work backward from carrier cut-off times, release a wave when there's an economical batch. Fine on a normal day. The trouble lives in the half hour before cut-off.
I watched this play out on a real dock: carrier cut-off at 8 PM, and at 7:30 a key account dropped an emergency order — three hundred plus units. The system had already released everything scheduled before eight, the conveyor fully loaded. By the rules, that order waits for the next wave and ships tomorrow. The supervisor went into the WES console, manually delayed the regular waves by fifteen minutes, slotted the big order into the next release — and everything made the eight o'clock trailer.
Why can't the system handle it? Because it can't see "we lose this account if we miss the truck." It only knows rules and capacity. The manual handoff works like this: the supervisor has a "release wave now / delay wave" permission, and every use requires picking a reason in the system — "rush customer order," "carrier arrived early" — with the wave log recording it automatically. Handing back is clean: the next wave returns to automatic release, the system re-sequences on its own. The intervention is a single action, not a master switch someone forgets to flip back.
Priority overrides: if everything is urgent, nothing is
Rush replenishment for a stockout, a VIP order — jumping the queue is legitimate. But I once worked with a building where three supervisors each held override rights, and every morning the WES task queue carried two hundred "top priority" orders. The system couldn't tell who was actually first. Whoever shouted loudest shipped first. That's priority inflation — same economics as printing money. Print enough and it's worthless.
Where the system falls short: it doesn't know which VIP is a real VIP this week. Customer tiers in the WES are static configuration; reality is dynamic. The account you must protect this month may not be last month's.
The fix is a quota. Give each shift's supervisor, say, twenty override slots. Use one, lose one, with the remaining balance visible in the WES. Every overridden order gets tagged, and the monthly report shows how many overrides happened and who approved them. Quota exhausted and you still want to bump an order? Get the ops manager's sign-off. The moment overrides cost something, the casual ones disappear.
Equipment degradation: write the takeover script before the conveyor stops
This is the most dangerous of the five. A WES earns its keep coordinating equipment — which becomes exactly the problem when the equipment goes down. A jammed conveyor, AMRs dead in an aisle, a print-and-apply unit eating labels. The WES will alarm. It will not decide on its own to reroute Zone B's work through Zone C.
Why not? Because a degradation plan is a business decision, not an algorithmic one. Cutting over zones means pick paths change completely, labor gets reshuffled, waves need recalculation. The system either can't compute those trade-offs or computes an answer you wouldn't dare let it execute unsupervised.
So the degradation playbook gets written in advance — and rehearsed. It states what severity triggers human takeover (say, a single conveyor down more than ten minutes), the first three actions after takeover (manually cut affected waves to the backup zone), which WES screens to hit, what to announce to each station. Two rehearsals and supervisors stop freezing when it happens for real. I've seen the alternative: a jammed line, five supervisors shouting different instructions over the radio, tasks piling up in the WES until someone killed the whole line to clear it by hand. A twenty-minute recovery turned into two hours.
Handing back: once equipment is restored, the supervisor hits "resume auto-dispatch" in the WES, the system re-scans task state across zones and re-sequences the diverted waves automatically. The non-negotiable part: every manual action during the takeover lives in the system log. The post-mortem reads the log, not people's memories.
Labor moves: the system advises, the supervisor decides
Modern WES platforms carry some labor-management muscle: which zone is backing up, which zone has slack, and a suggestion like "move three people from A to B." Listen to the suggestion. But the call belongs to the supervisor.
Because the system doesn't know it's someone's first solo day on the job, or that a veteran's back can't take two straight hours standing at a station. Cross-zone moves need a human skill check — sending someone who's never run put-to-light into a light-directed zone doesn't raise throughput, it raises errors.
The workflow is simple: the system proposes, the supervisor confirms or adjusts in the interface, and the system updates task allocation across zones. My standing habit: supervisors review the labor suggestion at shift start and midday, and any change happens in the system — not shouted across a group chat. The moment "hey, go help in Zone B" lives only in a chat message, the WES still shows the old labor picture, tasks keep routing to Zone A, and the system and reality start drifting apart.
Cycle counts and locked locations: unfreezing needs a human signature
When the WES locks a location — book versus physical mismatch, a sensor anomaly, three consecutive pick errors — related tasks pause automatically. The auto-lock is right. The problem is the unlock.
My rule: a system-locked location gets unfrozen only by human confirmation. Never automatic release. I saw a building enable "auto-unlock after 30 minutes with no human action" to save effort. One sensor-false-positive location unlocked itself three times — and mis-shipped three times. Auto-unlock welds the safety valve shut.
The confirmation is low-friction: the location auditor eyeballs it on the floor, and if the physical stock checks out, taps unfreeze in the WES with a reason — "physical matches," "replenished," "sensor false positive." The system logs it. Before end of shift, the supervisor scans the day's unfreeze list; any location unfrozen three-plus times gets flagged for a deep check tomorrow. Keep that habit and inventory accuracy genuinely climbs.
Five boundaries, one thesis: manual intervention itself has to be proceduralized. Who can intervene, in which scenarios, with what trace left in the system — written into the SOP, backed by WES permissions and logs. Not a shout in a group chat.
A WES runs the 95% that's routine; humans run the 5% that's exceptional. That division of labor is correct. The most dangerous thing was never human intervention — it's intervention without a process. One patches the system; the other digs holes under it. Which one you are comes down to whether there's a log entry when you're done.
