Last Mile Delivery Software: The Constraint That Breaks Most Shortlists
Drafted with AI assistance, edited and fact-checked by Sean Flannery. See our editorial policy.
Last mile delivery software plans, dispatches, tracks and proves the final leg from depot to customer door. The capabilities are near-identical across platforms: dynamic routing, predictive ETAs, live tracking, electronic proof of delivery, exception handling and API integration. What separates them is which operational constraints the routing engine enforces as hard rules rather than suggestions.
That distinction is invisible on a feature matrix. It is the only thing that matters on a Tuesday.
The delivery day that breaks a feature-matrix shortlist
Picture a two-depot operator who did the evaluation properly. Eight boxes ticked: routing, tracking, proof of delivery, notifications, analytics, driver app, integrations, exception handling.
Then comes a route with three fixed commitments on it.
A wholesale bakery drop that has to clear before 8am or the café refuses it. A refrigerated consignment that can only sit in the van for so long before it falls outside temperature tolerance. And a building site with a booked crane slot, which means the truck is either there in that hour or it comes back tomorrow.
The software plans it beautifully. Every stop sequenced, ETA on every line, map looks clean.
By 9:40am the run has collapsed. The bakery stop ran 15 minutes late because the optimiser treated the 6 to 8am window as a preference and quietly shifted it to gain distance elsewhere. The crane slot is gone. The chilled load is now the dispatcher's problem.
Nothing in that failure shows up as a missing feature. Every capability on the checklist was present and working. The engine simply ranked total drive time above the constraints that actually governed the day.
What last mile delivery software actually does
Gartner describes last-mile delivery technology as the systems that plan, execute and provide visibility over the final leg from depot to customer. That is the useful boundary.
A warehouse management system decides what gets picked. A transport management system handles freight movement and carrier procurement. Last mile delivery software owns everything after the goods leave the dock and before the customer signs.
Six jobs, in order: plan the routes, dispatch them to drivers, track execution live, notify the customer, capture proof at the drop, and reconcile what happened against what was promised.
A platform that only does the first of those is a route planner. Useful, cheaper, and genuinely enough for some operations. But it leaves the other five jobs sitting in spreadsheets, group chats and phone calls.
The test is where your failures happen. If your worst day is caused by bad sequencing, a planner fixes it. If your worst day is caused by a driver not knowing a stop moved, a customer not knowing where the van is, or a dispute you cannot settle because nobody photographed the pallet, you need the execution loop.
Eight capabilities every platform must have, and how to stress-test each one
Every vendor page lists these. The list is not the hard part.
The hard part is that "supports time windows" can mean the engine refuses to schedule a stop outside its window, or it can mean the window prints on the driver's manifest and nothing enforces it. Same two words. Completely different software.
Use the third column below in the demo, not the second.
| Capability | What it should mean | The question that proves it |
|---|---|---|
| Route optimisation | Sequences stops across multiple vehicles, not one van at a time | Plan my real delivery day live. How long does it take with my full stop count? |
| Time windows | Enforced as a hard constraint, not printed as a note | Show me what happens when two overlapping windows cannot both be met. |
| Vehicle capacity | Weight, volume, pallet space and vehicle type all block assignment | Overload a run deliberately. Does the plan reject it or just widen the ETA? |
| Multi-depot planning | Different start points, shifts and finish locations in one plan | Can a driver start at one depot and finish at another in the same run? |
| Driver mobile app | Works with no signal and syncs when coverage returns | Put the phone in flight mode mid-demo. Complete a stop. What syncs back? |
| Electronic proof of delivery | Photo, e-signature, timestamp and GPS geotag against the order | Show me all four on one delivery record, then retrieve it 60 days later. |
| Tracking and notifications | Predictive ETA that updates, plus triggered customer messages | What event fires the notification, and does the ETA recalculate after a delay? |
| Integrations and API | Orders in, status out, via native connectors or documented API and webhooks | Send me the API docs before the next call. Who builds the connector, you or us? |
Five delivery constraints that decide which platform you need
Most shortlists are built around industry labels. Retail, food, pharma, construction. That is the wrong axis.
Two food businesses can need completely different software, and a bakery can have more in common with a pathology courier than with a meal-kit brand. What actually clusters operations together is the constraint that governs the drop.
Cold chain and temperature tolerance
Chilled and frozen goods put a clock on the vehicle, not just the stop. Every extra minute in the van is consumed tolerance.
Cold chain delivery software has to sequence around dwell time and load order, keep chain-of-custody evidence at each handover, and make the proof retrievable when a client queries condition on arrival.
Premium seafood is the clearest version of this problem, which is why operators like Madam Seafood's refrigerated delivery operation treat routing and delivery evidence as one workflow rather than two systems.
Early-morning freshness windows
Wholesale food delivery lives inside fixed bands. A café that opens at 7am wants product before it opens, not at 10:30am when the optimiser found a tidier loop.
Here you need window enforcement plus sequence locking, so a stop that has to be third stays third even when the engine replans around a late start or a breakdown.
Bakery operations such as Husk Bakery's wholesale delivery rounds run to those bands every single morning, which makes replanning speed as important as the original plan.
Pharmacy, compliance and identity-checked handover
Some deliveries cannot be left at the door under any circumstance.
Pharmacy delivery routing needs identity-checked handover, a secure electronic proof of delivery with e-signature, timestamp and geotag, and a defensible audit trail that holds up months later. Not a photo of a parcel on a porch.
Prescription delivery at volume, the kind SuperPharmacy runs for home delivery, adds a second demand: patients expect the same tracking experience they get from a retail parcel, without loosening the handover rules.
Heavy goods and restricted site access
Building sites do not accept deliveries. They accept deliveries at a time, at a gate, with the right vehicle and sometimes a second person to unload.
Construction site delivery scheduling therefore depends on vehicle-type constraints, booked access slots, and site contacts that reach the right foreman rather than the account holder in an office.
Heavy goods distributors like Franz Building Supplies are planning around access rules as much as distance, and any engine that only optimises kilometres will keep producing plans the site rejects.
Scheduled collections and reverse loops
Not every route ends at a customer's door. Plenty of operations run the other way: recurring collections, container swaps, empties back to a depot.
Reverse loops need recurring route templates, capacity that fills as the run progresses rather than empties, and exception rebooking when a site is not ready.
Collection networks such as Containers for Change depend on that recurring-schedule logic, and it is the single most common gap in platforms built purely for outbound parcel delivery.
Software archetypes: four ways last mile platforms are built
Underneath the marketing, there are four common architectures. Knowing which one you are looking at tells you where the gaps will be before you sign.
The routing module bolted onto an ERP or TMS. Strong master data and finance integration because it lives where your orders already are. Usually weaker on the driver experience, customer-facing tracking and proof of delivery, because those were added later.
The standalone route planner. Fast, focused, often excellent at sequencing. It ends at the plan, so dispatch changes and delivery evidence tend to live somewhere else.
The full last mile execution platform. Planning through to proof and reporting in one system, with the API surface to sit downstream of an OMS or online store. More to configure at setup, less to reconcile every afternoon.
The carrier portal aggregator. Excellent when third parties do your delivering. It gives you visibility across carriers rather than control over your own drivers, so it solves a different problem than an owned fleet has.
The 10-question demo script (bring your own delivery day)
Export one real day. Your worst one, ideally, with the awkward stops in it. Then work through these on the call.
- Plan this day live, now. How long does the optimisation take at my stop count?
- Two stops have overlapping time windows and only one vehicle can serve both. What does the system do?
- Is vehicle capacity a hard limit that blocks assignment, or a warning the planner can override?
- Can drivers start from different depots and finish at different locations in the same plan?
- How do I restrict a stop to drivers with a specific skill, licence or vehicle type?
- A driver breaks down at stop four. Show me reassigning their remaining stops to two other drivers mid-route.
- Show me one delivery record with a photo, e-signature, timestamp and geotag together, then find it again from a customer name.
- A delivery fails because nobody is on site. What does the driver do in the app, and what happens to that order tomorrow?
- Which event triggers the customer notification, and does the ETA recalculate after a 40-minute delay?
- Who builds the integration to my order system, how long does it take, and what is the ongoing support arrangement?
If a vendor wants to demo on their sample dataset instead of yours, that is your answer to question one.
What last mile delivery software really costs, and what the quote leaves out
Vendors price three ways: per driver or vehicle, per order or delivery, or a flat tier with usage bands. None is inherently better. They just make different operations expensive, so normalise every quote to your actual volume and driver count before comparing.
The licence fee is rarely where the surprises live. These are:
- Onboarding and configuration, especially building your constraint rules properly
- Historical data migration from spreadsheets or a previous system
- The integration build to your OMS, ERP or online store, and who pays for it
- Driver training and the change management that goes with it
- The support tier you actually need, which is often not the default one
- The routes a planner still fixes by hand every morning because the engine cannot hold your constraints
That last line is the one nobody quotes and everybody pays.
The metrics that tell you the software is working
McKinsey's research on parcel economics puts the last mile at the largest single share of total delivery cost. Which is why total fuel spend is a poor scoreboard and cost per drop is a good one.
Four numbers, watched together:
Timeliness is no longer a differentiator either. The World Bank's Logistics Performance Index scores economies on timeliness and tracking, and customers now arrive with that expectation already set by whoever delivered their last parcel.
If you want the full measurement set, our breakdown of the delivery metrics worth reporting weekly goes deeper on how to baseline before you switch systems.
Last mile delivery software FAQs
What is last mile delivery software?
Last mile delivery software plans, dispatches, tracks and proves deliveries on the final leg from depot or store to the customer's door. Core functions are route optimisation, dispatch, live tracking, customer notifications, electronic proof of delivery and exception handling, usually connected to an OMS, WMS or e-commerce platform by API.
What is the difference between route optimisation software and last mile delivery software?
Route optimisation software solves one problem: the most efficient sequence of stops for a set of vehicles. Last mile delivery software includes that engine and adds dispatch, a driver app, customer tracking and notifications, electronic proof of delivery, exception workflows and reporting.
Do I need last mile delivery software if I only run a few vehicles?
Often yes, because the trigger is complexity rather than fleet size, and three vehicles with narrow windows, refrigerated loads and signature requirements will gain more than ten vehicles on a fixed round. A practical test: if a planner spends over an hour a day sequencing stops or chasing status, manual planning already costs more than software.
What is ePOD in delivery software?
ePOD, or electronic proof of delivery, is the digital record a driver captures at the drop, and a complete one includes a photo, an e-signature, a timestamp and a GPS geotag stored against the order. Check all four are supported, because plenty of platforms describe photo capture alone as ePOD.
What should I ask a vendor during a last mile delivery software demo?
Make them plan one of your real delivery days live rather than a sample dataset. Then ask how the engine handles overlapping time windows, vehicle capacity limits, multi-depot starts, driver skills and licences, mid-route reassignment, failed deliveries, and who builds the integration to your order system.
What costs are not included in a last mile delivery software quote?
Typically onboarding and configuration, historical data migration, the integration build to your OMS or ERP, driver training and change management, and the support tier you actually need rather than the default. Ask for each line item in writing before you compare quotes.
Why growing fleets choose Locate2u
Locate2u was built around the constraints, not around the map.
Time windows, vehicle capacity, driver skills and licences, multi-depot starts and mid-route reassignment are enforced by the engine rather than printed on a run sheet. Proof of delivery captures photo, e-signature, timestamp and geotag on every drop, and it stays retrievable when a dispute lands weeks later.
The same platform runs a three-van operation and a fleet of over a thousand drivers across Australia, New Zealand, the UK, the US and Canada, with native connections to Shopify, WooCommerce, Xero, ServiceM8 and Zapier plus an open API for everything else.
Take the 10 questions above into a demo of Locate2u's last mile delivery platform and bring your hardest delivery day with you. That is the only test worth running.