Parcel-locker delivery UX: what locker-first markets teach your checkout

In much of Northern and Eastern Europe, the default way to receive a parcel is not a courier at your door — it is a self-service locker down the street that you choose yourself at checkout. If your marketplace treats lockers as an afterthought, shoppers in these markets treat your checkout as broken. This is what running a locker-first checkout taught us: why the shopper picks a locker per vendor parcel, how to design a picker people can actually use, and the failure modes that make an otherwise-finished checkout fall over.

Why locker-first markets change the checkout

In a locker-first market, parcel lockers are the primary delivery method, not a cheaper alternative buried under "other options". Shoppers expect to name a specific machine near home, work or the school run, and they expect it to be the default selection, not something they hunt for. A checkout that leads with courier-to-door and hides the locker picker is optimising for the wrong habit.

The pull is practical, not ideological. A locker is cheaper than a courier, open around the clock so nobody waits in for a delivery window, and usually a short walk from home or the office. For a marketplace that means a large share of orders will choose a locker when you let them, and the minority who need a courier are the exception to design around — not the other way round.

This changes the information you must collect. Instead of a postal address, the primary delivery input is a locker identity — a specific pickup point from a specific carrier's network. A marketplace that lives on a content site's domain (the model in our white-label marketplace guide) inherits the delivery habits of that audience, and in the Baltics that habit is the locker.

A locker per vendor parcel

Here is the wrinkle a single-vendor store never has to solve. In a multi-vendor order, each vendor ships its own parcel from its own carrier account — and different vendors use different carriers, whose locker networks are not the same. So the correct unit of choice is not "a locker for my order" but a locker per vendor parcel.

If vendor A ships on one network and vendor B on another, forcing a single global locker choice guarantees that one of the two parcels goes to a machine its carrier cannot serve. The order splits per vendor anyway — one payment fans out to per-vendor sub-orders, which we cover in multi-vendor checkout — so the locker choice has to split the same way. Show the shopper each vendor's parcel and let them pick the pickup point that parcel's carrier actually offers.

Designing the locker picker

A national locker network can have a couple of thousand machines. A raw dropdown of two thousand entries is not a picker; it is a punishment. What works:

• Search-first. A text box the shopper types a town or street into, with typeahead, beats scrolling every time. Most people already know which locker they want.
• Grouped and filtered. Group results by city or district, and show only the lockers the carrier for that parcel actually serves — never a merged list across carriers.
• Remember the last choice. Repeat shoppers use the same two or three lockers; pre-selecting the last one removes the interaction entirely.
• Text list over slow map. A map is a nice enhancement but a poor requirement; a fast, well-labelled text list outperforms a heavy map that blocks checkout on a mobile connection.

The picker's data comes from carrier APIs, and that has consequences covered below.

Address mode vs locker mode

Not every parcel can go to a locker. Oversized or heavy items — the equipment end of a catalogue — physically will not fit, and some carriers restrict certain goods. So the picker is not always the right control; the checkout needs two modes and a rule for switching between them.

Drive the mode from the parcel, not a global toggle: if a vendor's parcel is locker-eligible and you can reach that carrier's locker list, show the picker; otherwise fall back to an address form for that parcel and say why. A shopper should never be shown a locker picker for a parcel that cannot use one.

Failure modes that break locker checkout

Locker checkout has a specific catalogue of ways to fail, and every one of them is invisible until a real shopper hits it:

• The empty picker. If the carrier's locker API is down, rate-limited, or hasn't loaded during a deploy, the picker can render an empty dropdown. Never show an empty control with no explanation — fall back to address mode or a clear "pickup points are loading" state. An empty picker reads as a broken store.
• Stale or inactive lockers. Locker lists change and machines get decommissioned. Cache the list for speed but refresh it, or a shopper will pick a locker that no longer accepts parcels.
• No key, no picker. A locker picker needs the carrier's business API key. If you cannot obtain a key for a given carrier, you cannot offer its picker — the honest response is to not present that network rather than show it broken.
• Encoding and locale. Locker names carry local diacritics; mangle the encoding and the search box stops matching the names people actually type.

Once the parcel ships, the loop closes with a dispatch notification that names the chosen locker and carries a working tracking link — its own engineering problem, covered in shipment tracking automation. And the fee attached to locker delivery is, like every other delivery cost, computed per vendor, not flattened across the cart.

Frequently asked questions