POD for Parcel Lockers and PUDO Points

Parcel lockers and pickup/drop-off (PUDO) points shift proof of delivery away from the traditional courier-to-customer handoff into a two-stage model: the carrier's proof of placing a package into the locker or handing it to a PUDO agent, and a separate proof that the end customer actually retrieved it.

Two Distinct POD Events

The first event, deposit confirmation, happens when the driver places the parcel into an assigned locker compartment or hands it to a shop counter acting as a PUDO point. This is typically confirmed by a barcode scan and, for lockers, a system-generated confirmation that the compartment door has closed and locked. The second event, collection confirmation, happens independently — sometimes hours or days later — when the actual recipient retrieves the parcel using a PIN code, QR code, or app-based unlock.

Driver Deposit Scan + locked Locker / PUDO Holding parcel Customer Pickup PIN / QR unlock
Who Is Responsible for What Failure

Splitting POD into two events matters for accountability. If a parcel is deposited correctly but the customer never collects it, that is not a carrier delivery failure — it is a customer pickup failure, and the two need different handling, including different return-to-sender timelines and different reporting to the shipper. A system that only records a single "delivered" event when the driver drops the parcel into the locker overstates delivery success, since the parcel has not actually reached the customer's hands yet.

Evidence for the PUDO Agent Handoff

When the point is a staffed PUDO location rather than an automated locker, the deposit confirmation should capture which staff member accepted the parcel, since that person is now responsible for it until the customer arrives. A barcode scan alone does not establish accountability the way a linked staff identifier does, which matters if a parcel goes missing from the PUDO counter before the customer collects it.

Expiry and Return-to-Sender Handling

Lockers and PUDO points hold parcels for a limited window. The POD system needs to track the deposit timestamp against that expiry window and generate reminder notifications to the customer as the deadline approaches, then trigger a distinct "returned uncollected" event — separate from both delivery success and delivery failure — if the window lapses.

Practical Recommendations
  • Record deposit and collection as two separate, independently timestamped POD events
  • Never report a locker deposit to the shipper as equivalent to a completed customer delivery
  • Capture staff identity for manned PUDO handoffs, not just a barcode scan
  • Track holding-window expiry and automate reminder notifications before it lapses
  • Model "returned uncollected" as its own outcome, distinct from refusal or failed delivery