The Last 200 Metres: What Actually Goes Wrong Between the Van Door and the Customer's Hand

Why the last 200 metres, not the last mile, is where local food delivery breaks

The last mile is a driving problem and routing software solves it well. The last 200 metres is a handover problem: parking, stairs, doorbell codes, absent customers, closing pickup points and empty crates. That stretch takes no fuel and generates almost every delivery dispute a co-op has to settle.

The difference matters because the two stretches fail differently. A bad route costs you time and diesel, and you can see it in the numbers at the end of the week. A bad handover costs you a €38 box of perishables, a producer who does not get paid for goods that were physically delivered, a customer who wants a refund, and a crate that never comes back. None of that shows up on a route map.

It also compounds. In a supermarket chain the driver drops a pallet at a loading bay and leaves. In a short food supply chain the driver is delivering twenty to sixty individual chilled boxes into residential buildings, on a fixed afternoon window, with items that were harvested that morning. Every failed handover is a perishable item with a clock running on it and a producer's name attached to it.

The six failure modes, and what the driver actually sees on screen

Six failures cover almost every failed drop in a short chain: the customer is not home, the building is not enterable, the pickup point closes before the van arrives, the goods are left with a neighbour, the box is refused on the doorstep, and the empty crate is not returned. Each one needs a different screen and a different resolution.

The useful design question is not "how do we stop this" but "what does the driver tap in the thirty seconds they are standing at the door with a chilled box in their hands". If the app only offers Delivered and Failed, the driver will pick Delivered for the neighbour drop, pick Failed for the wrong doorbell code, and the back office learns nothing it can act on. Reason codes have to be specific enough that the administrator can route the consequence to the right person the next morning.

The list below is the working taxonomy. It maps roughly to what a delivery app should offer as outcome buttons, and each item carries a different downstream cost.

Customer absent: doorbell rung, no answer, chilled box in hand and a clock on it. Needs a decision rule, not a driver's judgement call.
No building access: intercom broken, code changed, gate locked, courier code shared in a message the driver cannot see. The customer is often home and unaware.
Pickup point closed: the shop, café or locker that hosts the drop shut at 17:00 while the van was two stops away. Nobody is at fault and the goods still need somewhere to go.
Neighbour or concierge drop: the goods are handed to a person who did not order them. Delivery succeeded, chain of custody did not.
Doorstep refusal or damage: leaking bag, crushed berries, wrong item, or a customer who simply says no. Needs a photo and a return-to-depot flag before the van pulls away.
Crate not returned: the delivery worked perfectly and a deposit-bearing crate is still in the customer's kitchen. This is the most under-recorded failure in the whole chain.

What the administrator sees, and why the back office view is a different job

The administrator does not need six outcome codes. They need three queues: goods that came back on the van and need a decision today, money that is now in dispute, and packaging that is missing. A good back office collapses forty individual driver taps into those three action lists before anyone reads a single delivery note.

The critical detail is that a failed drop is not one event, it is three unresolved threads. There is a physical thread (where is the box right now, is it still cold, can it be resold or must it be written off), a financial thread (does the customer get refunded, does the producer still get paid, who absorbs the loss), and a relational thread (does the customer get a message tonight or find out on Thursday). Software can close the first one automatically. The second two need a policy behind them.

This is also where the returned-crate problem gets visible. If the driver logs crates collected per stop and the system holds a running deposit balance per customer, the administrator sees a list of households at three crates and rising. If crates are not logged at the door, the loss is invisible until someone counts the depot stack at the end of the season and finds a third of the fleet gone.

Which failures software can genuinely prevent

Software prevents the failures that come from missing information at the door: unknown access codes, unreachable customers, pickup points that will be closed on arrival, and untracked packaging. It cannot prevent a customer choosing to be out. The honest split is that roughly half the taxonomy is a data problem and half is a behaviour problem.

The preventable set is worth building properly because each item removes a whole category of dispute rather than making it easier to argue about. Access instructions and a doorbell code belong on the address record, not in a chat message from three months ago, and the app should require them before an apartment address goes live for delivery. A pickup point should carry opening hours as structured data, and the route planner should refuse to sequence a stop that lands after closing time, or flag it loudly to the dispatcher. A customer should get an ETA message with a live window and a working reply channel, so absence turns into a reschedule at 14:00 rather than a failed drop at 16:40.

What software cannot do is decide whether a chilled box may sit in an unheated stairwell for two hours in March, or whether the co-op eats the cost of a spoiled box when the customer forgot they had a dentist appointment. Those are policies. The most it can do is enforce them consistently once someone has written them down.

Prevented by data: missing entry codes, unknown floor or buzzer name, unreachable phone number, closed pickup point, unlogged crates, undocumented damage.
Prevented by process design: neighbour drops without consent, silent failures nobody tells the customer about, boxes that ride around in the van for the rest of the route.
Not preventable, only governed: customer absence, refusal at the door, weather, a building's caretaker refusing entry, a pickup host who closes early without warning.

The five policies every co-op has to write before the software can help

Before configuring any delivery app, a co-op needs written answers to five questions: how long may a chilled item be left unattended, who may accept on the customer's behalf, what happens to goods that come back on the van, who pays for a spoiled box, and how many crates a customer may hold before ordering stops. Software enforces these; it cannot invent them.

Write them as thresholds, not principles. "We care about the cold chain" configures nothing. "Chilled items may be left in a shaded, sheltered location only between November and March, only with prior written consent on the address record, and never for meat, dairy or fish" is a rule a driver can follow and an app can enforce with a conditional button. The same applies to money: decide in advance whether the first failed delivery in a season is free and the second carries a re-delivery fee, and whether a producer is paid for goods that were picked, packed and loaded but never handed over. Producers usually should be paid in that case, because the failure happened after their obligation ended, and the co-op needs to price that risk into its margin rather than discover it at settlement.

The crate policy is the one most operations skip. Deposits only work if the return is logged at the door and the balance is visible to the customer at checkout. A cap, say four outstanding crates before the next order is held, turns a slow leak of packaging into a two-line conversation.

Unattended-drop rule: which product categories, which months, which locations, and what consent is required on the address record.
Delegation rule: who may sign for a box (named neighbour, concierge, nobody) and whether the cold-chain guarantee survives the handover.
Return-to-depot rule: what happens to perishables that come back, what may be re-delivered tomorrow, what goes to staff or a food bank, what is written off.
Cost rule: who absorbs a spoiled box on a first failure versus a repeat, and whether a re-delivery fee applies.
Packaging rule: deposit value, maximum outstanding crates, and what happens at the cap.

Turning failed drops into a weekly number worth looking at

A short chain should review failed drops weekly by reason code, address and pickup point, not as a single percentage. One number tells you nothing. The same failure rate can mean one problematic apartment block, one pickup host with unreliable hours, or a delivery window that no longer matches when your customers get home.

The patterns that surface are usually specific and fixable. Three failures at the same address in a month means the access instructions are wrong, not that the customer is difficult. A cluster of late-window failures across a whole neighbourhood means the route is sequenced backwards for that district's working hours. Repeated closures at one pickup point means the host relationship needs a conversation or the point needs replacing. Rising crate balances in one delivery zone usually means the driver on that run is not being prompted to ask.

Photos and timestamps matter here for a reason that goes beyond dispute resolution. A proof-of-delivery record with a time, a location and an image is what lets a co-op say with confidence that a box left the depot cold at 13:10 and was in the customer's hands at 15:40. That is the same evidence trail that makes a refund decision fast and fair, and it is the difference between a member who trusts the service and one who quietly stops ordering after the second silent failure.

Key Takeaways

Almost all delivery disputes in a short food chain happen after the van has parked, in the handover, not on the route.
Six failure modes cover most of it: absent customer, no building access, closed pickup point, neighbour drop, doorstep refusal, and unreturned crate.
Software reliably prevents the information failures (access codes, opening hours, ETA messages, crate logging); it cannot prevent absence or refusal.
Unattended drops, delegation, return-to-depot handling, who eats a spoiled box and crate caps are policies the co-op must write before any app can enforce them.
Review failed drops weekly by reason code, address and pickup point rather than as a single failure percentage.

The same proof-of-delivery record that settles a dispute is the last hop in the chain of custody we describe in batch-level traceability, which follows a crate from grower to doorstep.

Frequently Asked Questions

Should a food co-op charge a re-delivery fee for a failed delivery?

Most co-ops that charge one make the first failed delivery of a season free and apply a fee from the second onwards, because the first failure is usually a genuine mix-up and the second is a pattern. The fee should at least cover the driver time and the written-off perishables, and it must be published in the terms before the season starts. The alternative, absorbing every failure into commission, quietly transfers the cost to producers.

Can a driver leave a chilled food box on the doorstep if nobody is home?

Only under a written rule the customer has agreed to in advance, and normally never for meat, dairy, fish or prepared foods. A workable policy limits unattended drops to a sheltered location, to cooler months, to lower-risk product categories, and requires consent recorded on the address record rather than a verbal arrangement with one driver. Without that, the co-op carries the full liability for anything that spoils.

Do producers get paid when a customer never receives their delivery?

Usually yes. The producer harvested, packed and handed over the goods, so their obligation ended before the failure occurred. The co-op or the delivery operation absorbs the loss and should price that risk into its margin. Deciding this in advance matters, because at settlement time an unallocated loss will otherwise be split arbitrarily and someone will feel cheated.

How do you stop customers keeping the reusable crates?

Log crate returns at the door as part of proof of delivery, hold a running deposit balance per household, and show that balance to the customer at checkout. Set a cap, for example four outstanding crates, after which the next order is held until crates come back. Deposits alone do not work if nobody records the return.

What is the difference between last mile delivery and the last 200 metres?

Last mile refers to the drive from the depot or hub to the customer's neighbourhood, and it is a routing and vehicle problem. The last 200 metres is everything after the van parks: parking, building access, stairs, the handover itself and collecting empty packaging. Routing software optimises the first; only proof-of-delivery workflows and clear policy handle the second.