Guides
Delivery manifests and the driver handover
The 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.
The exported list is the problem
Most kitchens generate a delivery list at some point in the morning and hand it over as a document. From that moment it is a copy, and it stops being true the instant anything changes — an address correction, a late pause, a re-assigned driver.
The alternative is that the driver reads the live record, scoped to their own stops. Nothing is exported, so nothing can be stale, and a change made in the office at ten o’clock is visible on the road at ten past.
What each stop has to carry
Sequence
A stable position in the round, so the driver has an order rather than improvising one.
Customer and count
How many boxes to hand over, so a short load is caught at the door and not at the end of the day.
A navigable location
A pin that opens in a map application, plus any access note — gate codes, reception instructions, which tower.
An outcome control
Delivered or failed, recorded at the stop rather than reconstructed later from memory.
Closing the loop matters more than tracking
Live tracking is attractive and rarely the highest-value feature at this scale. What changes the day materially is that stops are closed out at the point of delivery, so the kitchen can see the state of the round without phoning anyone.
A failed delivery in particular needs to be recorded honestly and immediately. Left open, it becomes an argument a week later that nobody has the evidence to settle.
Common questions
- Do drivers need their own application?
- They need their own view, not necessarily their own product. The same system scoped to one driver’s stops for the day avoids creating a second copy of the data that can drift from the kitchen’s.
- How should proof of delivery be captured?
- At minimum an outcome and a timestamp recorded at the stop, which is enough to settle most disputes. Photographs are useful but secondary to simply having an honest, immediate record that the stop was closed.
- What should happen when the customer is not home?
- The driver marks it failed with a short note, the kitchen sees it immediately, and the customer history records it. Anything left implicit becomes a billing disagreement neither side can evidence.
See how this works in practice
The home page walks through the same mechanics against a real admin loaded with a demonstration kitchen: production, packing, routes and the customer side.
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.
- SolutionsMeal delivery management software for the daily operating rhythmEvery meal-plan business runs the same loop every single day — cook, pack, drive, confirm. Management software earns its place by making the current position of that loop visible without anyone compiling it.
- GuidesSetting a meal delivery cut-off that actually holdsThe cut-off is the single most consequential number in a meal-plan operation. It is the line between a change that costs nothing and a change that costs food.
- GuidesThe driver handover checklistAlmost every delivery failure in a meal-plan business is an information failure rather than a driving one, and nearly all of them are created in the ten minutes before the van leaves.
- 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.
- GuidesManaging drivers in a meal-plan businessA driver who has run the same round for a year is materially faster than a new one, because they know which towers are confusing and where parking works. That knowledge is an asset, and turnover destroys it.