Designing Delivery Logistics and Route Assignment for a Short Supply Chain Marketplace

Why short supply chain delivery is not a parcel routing problem

Short supply chain delivery differs from parcel logistics in three ways: goods are perishable and often assembled the morning of delivery, supply is uncertain until the producer confirms, and the delivery window is a promise to a household rather than a best-effort estimate. That combination makes the routing problem downstream of a fragile fulfilment problem.

In a parcel network, the item exists before the route is planned. In a short supply chain marketplace, an order line can evaporate. A producer harvests less than expected, a batch fails a quality check, or a retailer marks an item unavailable an hour before pickup. Any logistics design that assumes a frozen order manifest at plan time will spend its life fighting reality.

The practical consequence is that batching and route assignment must be recomputable. Instead of treating the plan as a one-time optimisation output, treat it as a derived view that can be regenerated from current order state whenever something material changes, with human override always available. The plan is a suggestion with strong defaults, not an immutable artefact.

Modelling delivery windows for perishable goods

Delivery windows for perishable goods need at least three separate time concepts in the data model: the cut-off after which an order can no longer join a given delivery cycle, the pickup or consolidation window at the producer or hub, and the customer-facing delivery slot. Collapsing these into one timestamp is the most common early modelling mistake.

Each of these has a different owner and a different failure mode. The order cut-off is a commercial decision that drives how much time operations has to consolidate. The pickup window is constrained by producers who are farming, not staffing a warehouse, so availability is narrow and often fixed to specific weekdays. The customer slot is the only one the shopper sees, and it is where trust is won or lost.

Modelling them separately lets you express real rules cleanly. A product with a cold chain requirement can enforce a maximum elapsed time between pickup and handover. A producer that only loads on Tuesday mornings can be represented as a recurring pickup capacity rather than as a hardcoded exception. And when a slot needs to shift, you can tell exactly which constraint forced the change, which is what a support agent needs to explain it to a customer.

• • Order cut-off: latest point an order can enter a delivery cycle, per zone and per producer
• • Consolidation window: when goods are collected or arrive at the hub, tied to producer availability
• • Handover slot: the window shown to the shopper, derived from the two above plus route capacity
• • Freshness ceiling: maximum elapsed time from pickup to handover for temperature-sensitive lines

How to batch orders before you try to optimise routes

Batch orders before routing by grouping them along the dimensions that make a shared stop physically possible: delivery zone, delivery cycle or date, temperature class, and vehicle constraints. Only once orders are in coherent batches does sequencing stops become a tractable problem worth optimising.

Batching is where most of the operational value sits, and it is far cheaper to get right than routing. A useful mental model is that batching decides what goes on a vehicle and routing decides in what order. Zone definitions do the heavy lifting here. Geographic zones that reflect actual driving realities, bridges, one-way systems, rural clusters that are only sensible to serve together, outperform clean geometric grids. In practice these zones are drawn by the people who have driven the routes, then encoded and refined.

Temperature class is the second dimension worth enforcing at batch level rather than at route level. If a vehicle has one cooled compartment, mixing chilled and ambient lines beyond its capacity is not a routing inefficiency, it is an invalid plan. Encoding that as a hard batch constraint prevents the optimiser from producing confident nonsense.

Driver assignment: rules first, optimisation second

Assign drivers with a deterministic rules layer before adding any optimisation: match on zone familiarity, vehicle capability, shift availability, and current load, then rank the remaining candidates. A transparent rule set that dispatchers can predict and override beats an opaque optimiser that produces marginally shorter routes.

The reason is operational, not technical. Dispatch teams need to trust the assignment to stop second-guessing it, and trust comes from predictability. If a driver is assigned a zone they have never driven, the dispatcher wants to know which rule caused it. That means assignments should record their reasoning: the constraints considered, the candidates rejected, and why. Storing that alongside the assignment turns support conversations from speculation into lookups.

Optimisation earns its place later, once the rules layer is stable and you have historical data on actual service times per stop. Real dwell times vary enormously in this domain. A stop at an apartment building with no lift is not the same as a house with a driveway, and modelled travel time alone will not capture that. Feeding observed service times back into estimates improves slot accuracy more than a better routing algorithm typically does.

• • Hard constraints: vehicle type, cooled capacity, licence and shift eligibility, maximum route duration
• • Soft preferences: zone familiarity, previous customer relationships, balanced workload across drivers
• • Tie-breakers: fewest reassignments, shortest deadhead to first stop
• • Always-on escape hatch: manual reassignment with a recorded reason, visible in the audit trail

Building the driver app for the field, not the demo

A delivery driver app has to work with intermittent connectivity, one-handed operation, and drivers wearing gloves in a cold van. That means offline-first data, large tap targets, a single obvious next action per screen, and queued state changes that sync when signal returns rather than blocking on a request.

Offline behaviour is the part most often underestimated. Rural delivery routes lose signal, and a driver cannot wait for a spinner to confirm a handover. The workable pattern is to treat every driver action as an event appended locally with a client-generated identifier, then synced. The server accepts events idempotently and resolves ordering. Conflicts are rare in practice because a stop has one driver, but the identifiers make retries safe.

Exceptions deserve as much design attention as the happy path. Customer not home, partial delivery because two crates were damaged, wrong address, refused item: each of these needs a first-class capture flow with structured reasons and optional photo evidence. Structured exception data is what later lets you spot that a specific producer's packaging fails in transit, or that a particular zone has a chronic access problem. Free-text notes cannot do that.

Closing the loop: dispatch visibility and post-delivery data

Logistics systems get better when every plan is compared against what actually happened. Capture planned versus actual arrival times, service duration per stop, exception reasons, and route completion, then feed those back into slot estimates, zone definitions, and producer cut-offs. Without that loop, planning quality plateaus immediately.

For the dispatch side, the useful view is not a map with moving pins, it is an exception queue. Dispatchers need to know which routes are running behind enough to threaten a slot, which stops have failed, and which orders still have unconfirmed lines from producers. Everything else is noise during a delivery cycle. A map is helpful for context, but the working surface should be a prioritised list of things that need a decision.

On the analytics side, the questions that change the business are operational rather than routing-theoretical: which zones consistently overrun their planned duration, which producers cause the most late consolidation, and how failed deliveries correlate with slot length. Those answers usually lead to changes in commercial rules and zone boundaries, which shift outcomes far more than an algorithm tweak. Building the logistics stack, retailer portal, and shopper app as one connected system is what makes the data available to ask them in the first place, which is the kind of end-to-end work we tend to get pulled into at Jaspero.

The patterns above come out of our Plodovi case study, a four-year engagement building six interconnected systems for Croatia's leading short supply chain platform, including the delivery logistics stack and driver mobile app.