Here is my verdict up front: in pick-to-light, the lights themselves account for maybe 30% of accuracy. Location binding accounts for the other 70%. I have seen too many warehouses where the lights point at the wrong slot — good lights, good racking, and the problem was never the light. It was the binding between the light and the goods.
There are two sides to this. A pick-to-light system is an information system, not a lighting project. A perfectly bright light pointing at the wrong location has an accuracy of zero. Replenishment moves the goods to a new home, the light still shines on the old one, the picker follows the light — the mispick is guaranteed. So the real work of a PTL project does not happen on the day you buy the lights. It happens after every replenishment move: how do the lights follow the goods?
A Pit I Walked Into Myself: Light on Slot A, Goods on Slot B
In 2023, an auto parts warehouse in Ohio had more than two hundred light modules on its flow racks. Peak season hit, and the replenishment crew moved a batch of slow movers to the end-cap rack — easier to restock. Nobody updated the location binding table. The lights still lit up on the old slot A. The goods were sitting on slot B.
Mispicks multiplied several times over that peak season. Returns, customer service, re-picks — the extra cost could have bought another full set of lights. IT spent a week investigating: lights fine, WMS fine, network fine. The root cause was in the process: nobody had ever defined who updates the light-location binding after a replenishment move.
Put plainly, this was not a technical failure. It was an accountability vacuum. The replenishment crew figured "I just put the goods where they belong." IT figured "the binding table is operations' business." Operations figured "the lights are IT's equipment." Three departments, zero owners, and the lights pointed wrong.
How did they clean it up? Three things. First, the replenishment form got a new checkbox — "light binding synced" — and nobody clocked out without ticking it. Second, IT wrote a small script that reconciles the WMS location master data against the binding table every night, flagging mismatches in red. Third, they re-verified all two hundred-plus light modules before peak season. Two weeks, and the error rate was back to baseline. It did not cost much. The hard part was someone treating it as a real job.
Three Ways to Bind, Each With Its Price
I sort the binding logic on the market into three kinds. The trade-offs, all at once:
| Method | Logic | Price | Fits |
|---|---|---|---|
| Light-to-location | Light fixed to the slot; update the binding table when goods change | Simple logic; wrong the moment replenishment skips the update | Warehouses with fixed slots and stable SKUs |
| Light-to-SKU | Light follows the SKU via a unique identifier | Flexible; higher hardware and system cost | Warehouses with fast SKU rotation and frequent moves |
| Hybrid | Light-to-location in the main zone, light-to-SKU for promo and temporary slots | Two rule sets to maintain | E-commerce warehouses with wild peak-season swings |
There is no silver bullet. The choice depends on your replenishment frequency and SKU churn. If SKUs barely move all year, light-to-location is the easy answer. If promo SKUs rotate every few days, light-to-SKU is actually cheaper — because the labor cost of manually syncing binding tables long ago exceeded the hardware price difference.
What the Binding Table Looks Like: Three Fields
Light binding is, at bottom, one table. Many warehouses fail at PTL because this table was never built right. It needs at least three fields: light module ID, location ID, and SKU (nullable). In light-to-location mode, the SKU field follows replenishment; in light-to-SKU mode, the SKU field is the primary key and the location is just its current position.
Beyond the fields, two rules: first, the only write path into the binding table is the replenishment confirmation — manual edits require approval. Second, reconcile the binding table against the WMS location master data daily; a location that does not exist in the WMS may not exist in the binding table. Get the table right and everything else — spot checks, numbering ranges — has a foundation to stand on.
When Light-to-SKU Pays: A Simple Rule
Where does light-to-SKU cost more? Every module needs a unique identifier, and the system must maintain the SKU-to-light mapping. Hardware runs 30% to 50% higher than light-to-location. Whether it is worth it comes down to one number: how many times your SKUs move per month on average.
If a SKU moves less than once a month, light-to-location wins — manually syncing the binding table costs a few days a year. If SKUs move more than three times a month, the labor cost of manual syncing plus the mispick cost has long since exceeded the hardware difference — go light-to-SKU. The middle ground gets the hybrid: light-to-location in the stable zone, light-to-SKU where things churn. The math is simple enough that even a cost analyst would nod along: count the money first, pick the method second.
Making the Lights Follow the Goods: Three Things That Work
First, add one step to the replenishment process: move confirmation equals binding update trigger. Whoever moves the goods scans to confirm, and the system switches the light binding to the new location automatically. Five extra seconds of motion saves the entire mis-shipped order.
Second, run a "light-to-goods consistency" spot check before each shift. Sample 20 light modules, light them up, verify the goods match. Five minutes of work catches most binding drift. Plenty of warehouses discover their lights have been wrong for a month — because nobody ever checked.
Third, give peak-season temporary lights their own numbering range. In 2024 I saw a beauty e-commerce warehouse add 80 temporary light modules for a big promotion, using ad-hoc "light follows goods" binding with no unique keys. Two SKUs ended up sharing one light module — the light came on and two pickers both reached in. Errors doubled in three days. Temporary lights must live in an independent numbering range and be decommissioned the moment the event ends. Never mix them with the permanent binding.
The Daily Binding Checklist
One last thing: a checklist from a warehouse I worked with, now taped to the wall in their PTL zone. One: every replenishment move gets a scan confirmation, and the system switches the binding automatically. Two: each shift starts with a 20-module light-to-goods spot check. Three: temporary lights get an independent numbering range and are decommissioned the day the event ends. Four: audit the binding table monthly, and hand over binding permissions on every staff changeover.
The list is short. The hard part is doing it every day. Pick-to-light is 70% process, 30% lights. With the process standing, the lights can hardly go wrong; with a sloppy process, the brighter the lights, the more neatly they point wrong.
Here is the counter-intuitive judgment: when a PTL project fails, nine times out of ten it is not the lights' fault — it is the replenishment process that was never designed. Before buying lights, draw the replenishment-move flowchart. Light binding is just one node on that chart. If you cannot draw the chart, the most expensive lights are still decoration.
Next time a vendor talks to you about light brightness and response speed, interrupt with one question: after replenishment moves the goods, how does this light know it is pointing wrong? If they cannot answer, brighter lights will not save you.
By Lao Mi, Supply Chain Veteran (20 yrs)
