How do you offer a delivery slot at checkout that the network can honour?

The promise made at checkout is a capacity reservation

The tempting implementation is a table of slots with a maximum order count, decremented on booking. It survives contact with a real delivery network for about a week, because the thing being consumed is not a slot, it is a vehicle's time, and two orders consume wildly different amounts of it.

What a route has is a finite number of minutes: shift length, minus travel, minus service time at each stop, minus mandated breaks. A stop three streets from the last one costs a couple of minutes of travel; an isolated rural stop can consume more of the day than five urban drops; a bulky item carried upstairs has a service time unlike a letterbox parcel. So when a customer asks for tomorrow between four and six, the question is not whether slots remain but whether a vehicle already going near there can absorb the stop without breaking anyone else's window, which is a feasibility check rather than a counter.

A full insertion check at checkout is usually too slow and too volatile, so the practical shape is two layers. A cheap approximation answers within the page's latency budget, typically capacity per delivery area per slot expressed in minutes with an allowance for expected stop density. Behind it, the day's plan is re-optimised as bookings accumulate and the approximation is recalibrated against what the planner managed to fit. You are trading a small rate of promises you cannot keep against sales lost to over-caution, which makes both of those numbers metrics with targets rather than incidents.

Availability also has to be released. A slot held by an order that fails payment, is cancelled, or is never picked because the stock was not there is capacity you sold to nobody. That release path has the same shape as an expiring inventory reservation and is forgotten for the same reason: nothing visibly breaks, the day is simply emptier than it should be.

Narrow windows are sold to customers and paid for by routes

A one-hour window is a better proposition than a four-hour one and a much harder constraint. Narrow windows fragment the route: they dictate the visiting order rather than letting distance decide it, they force waiting when the van arrives early, and they reduce the stops that can be combined. That cost lands on the operation, not on the page that promised it.

Which is why slot presentation is a demand-shaping tool. Showing which slots are cheap or already served, through price, a marker, or simply by offering fewer options, moves demand towards routes that already exist, and that does more for last-mile cost than most solver improvements because it changes the instance rather than the search. The related decision is what the promise means: a slot offered as a commitment creates a liability, a slot offered as an estimate is cheaper to run and worth less commercially, and the confirmation email's wording had better match whichever the operations team thinks it gave.

The driver app is a writer that assumes no network

A driver spends parts of a shift with no connectivity: rural stretches, underground loading bays, thick-walled buildings, a dead battery on a spare handset. The work cannot pause, so the device is not a thin client with a cache, it is a first-class writer that produces facts the server has not seen yet.

Four consequences follow. Identifiers for delivery events are generated on the device, so a record exists and can be referenced before any upload. Every submission carries an idempotency key, because retries after a partial upload are certain. Device event time is captured but treated as evidence rather than truth, since clocks drift. And the manifest, addresses and sequence are downloaded at start of shift so the driver can work the whole day offline if it comes to that.

Conflict resolution is then a business rule, not a timestamp comparison. If the device says delivered and a depot scan says returned to depot, upload order tells you nothing about which is true. Operations has to decide, so the system detects the contradiction, holds the customer-facing status and raises it, rather than letting the last writer win.

Proof of delivery is evidence, and it should be sized to the exposure

Proof of delivery exists to settle a future dispute, so its strength should match what that dispute would cost. A photograph at the door is weak evidence of who received the parcel and strong evidence that it arrived somewhere, which for low-value goods is a reasonable trade against the seconds it costs. A screen signature says somebody accepted it. A one-time code the customer presents ties the handover to the person who ordered, which is what high-value or fraud-prone categories need. Identity or age verification is a legal requirement for some goods rather than a risk choice, and the flow must be able to refuse the delivery when the check fails.

Two implementation details cause most of the pain. Photographs are large and captured offline, so they upload separately and arrive after the delivery event, which must therefore be valid without its attachment and linkable to it later. And what you capture is personal data about a doorstep, sometimes including bystanders, so retention gets a defensible period tied to the dispute window rather than forever because storage is cheap.

An attempt that produced no proof is not a delivery you can defend, so the capture step belongs in the same transaction as the outcome, not in a queue that may or may not drain.

The failed attempt is a flow, not an error path

Something between a few and many percent of attempts do not complete, depending on the goods and the geography. Nobody home, access refused, the address wrong, the recipient unable to accept, a signature required and unavailable, the goods damaged in transit and refused. This is normal volume, and the tell of a system designed by someone who has not run one is that it treats the non-delivery as an exception to be handled by a human reading a report.

Modelled properly, a non-delivery is an outcome with a reason code, and the reason code selects the next step. Left in a safe place under a standing instruction closes the delivery. Left with a neighbour closes it with weaker proof. A second attempt tomorrow needs a slot booked and capacity consumed, which is the same reservation machinery as the original promise. Held at a collection point starts a clock after which the parcel returns. Return to sender starts a reverse flow with its own transport cost, its own goods-in process, and a refund or reshipment decision on the order.

Each branch has a cost, and the reason codes are how you learn where that cost comes from. Failures concentrated on wrong addresses are an address-capture problem at checkout. Failures because nobody was home are a slotting and communication problem. Failures at one apartment block are an access problem solved by an entry note, not by a third attempt. Without reason codes, all you know is that the rate is what it is.

Where the promise and the world part company

In last mile the familiar gap between record and reality shows up as the difference between the plan the depot printed and the shift the driver had. Traffic, a queue at one delivery, a mandated break taken later than modelled: by mid-afternoon the van is not where the plan says. So the promise sold in the morning has to be monitored against progress during the day, and the interesting engineering is what happens when it is clearly going to be missed. Detecting that while the van is still driving, telling the customer before they notice, and offering a choice is worth more than a tighter estimate ever was, because it converts a broken promise into a managed one. Silently rescheduling and letting someone wait out their window is the failure mode that produces the support contact, the refund and the lost repeat purchase.