Solutions
Meal delivery software for delivery managers
The delivery manager inherits every decision made upstream, usually without being told which ones changed. The job is to get today’s boxes to today’s addresses — and the hardest part is knowing what today actually is.
The information arrives last and matters most
By the time a manifest reaches dispatch, a customer has paused, another has changed address, and a third has skipped tomorrow. Whether any of that reached the list in your hand depends on whether somebody remembered to tell you.
That is the structural problem with a delivery list produced as an export. It is a photograph of a moment that has already passed, and its accuracy decays from the second it is printed.
A manifest derived from live subscription state has a different property: it cannot disagree with what customers have actually done, because it is not a copy of that information — it is that information, filtered to today.
What the role needs on the screen
Stops that already reflect pauses and skips
A paused customer should not appear on a route at all, rather than appear with a note asking the driver to check.
Routes grouped by the areas a driver covers
Grouping by area is what makes a route drivable. A list sorted by customer name is a list, not a route.
An exact map pin per stop
In much of the Gulf a written address is not sufficient to find a door. A pin removes the call to the kitchen for directions.
Item counts at the stop
How many boxes to hand over, so a short handover is caught at the door rather than at the next delivery.
Delivered and failed, closed by the driver
The status has to come from the person at the door, in the moment, not be reconstructed by the office afterwards.
Failures visible immediately
A failed stop at 09:40 is recoverable. The same failure discovered at 17:00 is a refund.
What the driver sees
Drivers get the same system, signed in with a driver role: only their own stops for the day, in route order, each with the customer, the address, the number of boxes and a Navigate action that opens the phone’s map.
They mark a stop Delivered or Failed, and the kitchen sees it as it happens. That is deliberately a small feature set. There is no proof-of-delivery photo and no turn-by-turn navigation inside the app, so neither is promised here.
The value is not sophistication, it is that the record of what happened is created by the person it happened to, at the time it happened.
Measuring the operation rather than the day
A delivery manager judged only on today will always be firefighting. The figures worth watching are weekly: failed-delivery rate, the proportion of stops with an exact pin, and the spread of stops per route.
Failed deliveries in particular are usually a data problem wearing an operations costume. A repeated failure at one address is nearly always an address that was captured badly at intake, and the fix belongs upstream rather than with the driver.
Those figures come from the same delivery records the routes are built from, so there is no separate reporting exercise and nothing to reconcile.
Common questions
- Do paused customers appear on the route?
- No. A pause removes the stop before the route is built, rather than leaving it in place with a warning note that a driver may or may not read.
- Can drivers close out their own stops?
- Yes. A driver signs in with a driver role, sees only their stops in route order, and marks each Delivered or Failed. The kitchen sees the result immediately.
- Is there turn-by-turn navigation or proof-of-delivery photos?
- Neither. Navigate hands off to the phone’s own map application, and there is no photo capture. If proof-of-delivery imagery is a requirement, it is not something we do today.
- Why do the same addresses keep failing?
- Usually because the address was captured poorly at intake rather than because of anything the driver did. Tracking the proportion of stops with an exact map pin tends to locate the problem faster than reviewing individual failures.
A manifest that cannot go stale
See routes, stops and the driver handover running against a demonstration kitchen’s delivery day.
Related reading
- SolutionsRoute planning and driver manifests for meal deliveryA meal-plan round is not a set of ad-hoc jobs appearing through the day. It is a known list, knowable the night before — which makes it a planning problem rather than a dispatch problem.
- SolutionsWhat a meal delivery driver needs on their phoneDriver tooling in this industry is usually either far too much — a full fleet platform sold to a kitchen running two vans — or far too little, which means a printed sheet. The useful middle is narrower than either.
- GuidesDelivery manifests and the driver handoverThe handover from kitchen to road is where a well-run morning gets undone. Almost every failure at this boundary is an information failure rather than a driving one.
- GuidesDispatch best practices for meal deliveryDispatch is the shortest phase of the day and the one with the highest error density, because it is where information stops flowing and vehicles start moving.
- GuidesPreventing meal delivery address errorsAddress problems look like small individual incidents and are actually one of the largest recurring costs in a delivery operation, because each one consumes two people at once.