OMS for Click-and-Collect Locker Networks

Parcel locker networks add a fulfillment endpoint that behaves like neither a home delivery address nor a staffed store pickup counter: an unattended, automated location with its own capacity limits, access codes, and dwell-time rules that the OMS has to actively manage rather than treat as a generic address.

Unlike a home address, a specific locker location has finite compartment capacity and finite compartment sizes. The OMS needs to check real-time locker availability (right-sized compartment open) before confirming an order for that pickup point, and ideally reserve the compartment slot at the moment of dispatch rather than discovering a full locker bank when the courier arrives.

• Compartment size must match parcel dimensions before a locker is offered as a valid fulfillment option
• Reservation of a specific compartment happens at dispatch, not just at order placement, since availability can change between order time and ship time
• Access code generation and delivery to the customer must be tightly coupled to the courier's actual drop-off confirmation, not sent prematurely

Lockers enforce a maximum dwell time (commonly a matter of days) before an uncollected parcel must be removed to free the compartment for other deliveries. The OMS needs to track this countdown per order and trigger escalating customer reminders as the deadline approaches, then automatically handle the return-to-sender or re-delivery workflow if the customer never collects — treating this as a defined exception path, not an open-ended stall in the order lifecycle.

If the assigned locker is unexpectedly full, offline, or physically inaccessible when the courier arrives, the OMS needs a fallback: automatic reassignment to a nearby locker with customer notification, or fallback to a different fulfillment method entirely. Without this, a single point of failure at one locker bank turns into a delivery failure the customer experiences as unexplained silence.

Many markets have several competing, non-interoperable locker networks, meaning the OMS needs to support a customer's chosen network as a valid delivery method distinctly from others, with separate API integrations, separate compartment-reservation logic, and separate SLAs per network. Treating "locker delivery" as one generic option rather than several distinct integrations tends to produce confusing failures when a specific network has an outage or capacity issue.