Electronic Shelf Labels and Odoo: The Coordination Is the Project

A label that lights up above a shelf looks like a small convenience. In practice it changes who owns the decision about what to pick next, and that decision is where the return actually comes from.

What an ESL picks for and what it does not

The label identifies a place, not an item.

• It tells the operator where to go; it does not know what was taken.
• It removes searching time and leaves walking time untouched.
• Confirmation needs a scan, a sensor or a button, and the choice shapes the accuracy.
• The gain is largest where pick faces are spread out and SKUs are slow-moving.
• In dense, fast-moving zones, a good paper list is often competitive.

Order batching in Odoo before a label lights

The batching logic decides the value of the hardware.

• Group by zone and pick density, or the operator walks the warehouse in a random pattern.
• Respect order priority; an urgent line should not wait behind a full batch of routine lines.
• Cap the batch by trolley capacity rather than by the software default.
• Release a batch to the shelf system only after stock reservation is committed.
• Keep the batch key stable so a resequenced batch does not confuse the label controller.

Mapping pick faces to labels

The mapping decays faster than the hardware does.

• One label per pick face and one pick face per location, or the map drifts within weeks.
• Store the label identifier against the location in Odoo, never against the product.
• Handle locations holding several products with a multi-line label or by splitting the face.
• Re-map as a planned task when slotting changes, and record who changed it.
• Keep a printable label-to-location map for the technician who maintains the shelving.

Put-to-light and pick-to-light are different problems

They look similar on a brochure and behave nothing alike.

• Pick-to-light guides the operator to a source location; the logic is item-centric.
• Put-to-light guides distribution into order containers; the logic is order-centric.
• Consolidation and sorting hold most of the labour in e-commerce, which is where put-to-light pays.
• The two modes fail differently and need different confirmation devices.
• Do not buy one architecture expecting to run both without redesigning the process.

The confirm step: who says the item was taken

The confirmation is the only real data the system produces.

• Scan the item after the light, or the event is a claim rather than a fact.
• Confirm at the shelf, not at the packing bench, or errors surface too late to fix cheaply.
• Record who confirmed and when, because disputes need both.
• Show the required quantity on the label and confirm line completion explicitly.
• Allow a reject action at the shelf; forcing operators to confirm wrongly is how accuracy dies.

Exceptions: short picks, substitutions, split lines

Exceptions are normal, and the process must absorb them in one action.

• A short pick should be resolvable at the shelf without a supervisor call.
• Offer substitution candidates from Odoo ranked by attribute match, not by whoever shouts loudest.
• Split lines must not leave a label lit forever, waiting for a quantity that will never arrive.
• Record a reason code on the line so the analytics are usable a quarter later.
• Escalate repeatedly short locations to slotting and replenishment, not to the picker.

Replenishment and the empty pick face

The most common exception is simply that the shelf is empty.

• An empty pick face is usually discovered by the picker, minutes before the order is due.
• If the shelf system knows the face is short, it can call replenishment before the picker arrives.
• Trigger replenishment from stock thresholds in Odoo, never from the label itself.
• Replenishment and picking must not collide in the same narrow aisle at the same moment.
• Track the share of short picks caused by an empty face; that is a slotting metric, not a picking metric.

Sync model: tasks, labels, acknowledgements

Model the work, not the commands.

• Treat the pick task as an ERP record with a state machine, and the label as an actuator.
• Give every label command an identifier so acknowledgements can be matched reliably.
• Make the interface idempotent; a retried command must never double-confirm a line.
• Buffer commands at the edge so a short network drop does not stop the aisle.
• Reconcile label states against ERP tasks at the end of every shift, and alert on drift.

Throughput maths: what ESL actually improves

Separate the three time components before you buy anything.

• Measure search time, walk time and confirm time independently, per zone, on the current process.
• Labels cut search time sharply and walk time only if the batch sequence is sensible.
• Confirm time often rises at first, then falls as operators learn the routine.
• Compute the break-even in lines per hour, not in percentage improvement.
• Model the case where the label network is down and picking continues on paper.

Failure modes and fallback picking

Assume the network will fail, and design the aisle to survive it.

• Labels lose sync, batteries die and controllers reboot; all three are routine events.
• Keep a printed pick list per batch, regenerated at release time, as the fallback.
• Mark stale labels visibly so an operator never trusts an old light.
• Monitor battery and radio health as scheduled maintenance, not as an incident response.
• Train the shift lead to switch an aisle to paper without waiting for IT.

Pilot design and metrics

Run the pilot through a full demand cycle, including a peak.

• Choose one zone with stable slotting and a moderate order profile.
• Measure lines per hour, pick accuracy, search time and exception rate against the same zone on paper.
• Include the maintenance hours for labels in the comparison, because they are real labour.
• Decide in advance what result would justify the full estate, since the hardware is a multi-year commitment.
• If the pilot wins only in search time, fix the slotting before buying more labels.