Short answer
Automate only when it is clear which flow must be standard and which exceptions intentionally remain. Otherwise, historical complexity is locked into WMS rules, WCS logic, and physical automation.
The exception has to go somewhere
In a manual operation, someone solves a lot with experience and a forklift. In an automated operation, a pallet must fit physically and digitally: readable label, known SSCC, correct dimensions, and a known process rule.
If it does not, it goes to reject handling, needs manual intervention, or blocks the flow. That is not a reason to avoid automation. It does make clear that process choices must be explicit before the design is locked.
Automation does not make a bad exception disappear. It only gives it its own error message.
Not every customer variation is garbage
Some customer or product variation is real: a different label rule, FEFO logic, or a specific load sequence. Other variation exists because the process grew that way and no one has questioned it for years.
That distinction must be clear before the design is fixed. Otherwise, you build customization for a problem that could have been removed.
Draw the line between process and system first
Operations and customer commitments define what the warehouse must do. The WMS holds the inventory, order, and process rules. The WCS releases, sequences, and routes work through automation. The PLC/control layer executes safe machine movement.
With those boundaries clear, you can see whether the problem sits in the process, master data, a WMS rule, WCS flow, or the physical automation. That stops a technology project from solving the wrong problem.
Is the operation behaving differently from the plan?
I look at the actual flow: process, system, decision-making, and people. That is usually where the next move is.