From an unrouted pile to a driver's run.
Deliveries start as orders in the same system, so planning a round is a step in your day rather than a separate tool to keep in step.
- A day board with an unrouted pool — everything still waiting for a van, filtered by delivery zone, with triage badges for priority, doorstep cash, ADR or hazardous, and refrigerated loads (Growth plan and above).
- A preview before you commit — building a route shows eligible, ineligible and unresolved stops, plus capacity, zones, conflicts and the driver's week hours, on a map with numbered pins (Growth plan and above).
- Fleet master data set up once — carriers and carrier selection, shipping conditions, vehicle types, vehicles, drivers, delivery zones, and route templates with recurrence for the rounds you run every week (Growth plan and above).
- Proof of delivery on every drop — photograph, signature, GPS and per-line outcomes, so a part-delivery is recorded line by line. Backdatable to when it actually happened, never future-dated (Growth plan and above).
- A run for each driver — start run, arrive at stop, then deliver, fail or collect, with load-scan and unload-scan manifests in reverse-drop yard order and a run-sheet PDF for the cab (Scale plan).
- Delivery performance you can act on — on-time and OTIF, first-attempt rate, a failure Pareto, plan variance, drops per hour, CO2e and rate-based cost to serve, with unknowns surfaced as unknown instead of quietly counted as zero (Growth plan and above).
Plan it properly, then prove it happened.
Most delivery days go wrong in one of two places: a round that was never going to fit, or a drop nobody can account for afterwards.
A prospective route tells you what fits and what doesn't before you save it — capacity, zones, conflicts and the driver's hours for the week.
The driver page keeps working offline. Actions queue on the device and sync when the van comes back into coverage — no evening re-keying.
Photograph, signature, GPS and a per-line outcome on every stop, so a delivery dispute has an answer instead of a memory.
The driver page works in a dead-zone.
This is the part most delivery software quietly gets wrong, and it's the part we built hardest.
A driver leaves the yard at seven with twelve drops, four of them down lanes where the signal gives up entirely. At the fourth stop there are no bars at all — and it makes no difference. A service worker has already cached the booting shell plus the last-known session and run data, namespaced per tenant and per user, so an offline reload still comes back with the run on it. The driver marks arrival, records two lines delivered and one short, photographs the pallet and takes a signature at the door. Every one of those actions lands in a driver outbox held in localStorage and IndexedDB. When the van reaches a main road at half eleven, the outbox drains in order, with retry for anything that failed, discard for anything that shouldn't go, re-attach for evidence that didn't upload, manifest-drift detection if the load changed underneath, quarantine with export for legacy entries, orphan-blob cleanup, and a forget this device wipe for when a phone leaves the business. Nothing gets re-keyed in the evening, because nothing was lost.
On the Scale plan there's a control layer around all of this. A readiness checklist returns PASS, WARNING or BLOCK per finding, with a supervisor override when the business decides the risk is acceptable. You publish a route to the driver and unpublish it, amend a published route with a preview and an address-drift diff, replan the remaining stops mid-run, or abort a run against a reason code. The fleet optimiser returns a read-only proposal — solver status, utilisation, overtime, unassigned stops with reasons and remedies, and warnings you have to acknowledge — which a human then explicitly applies to a draft or planned run. It never changes a route on its own, and it never re-optimises behind a driver's back once a run is under way. Doorstep cash comes back as a per-currency, per-method debrief with custody references, maker-checker and a mark-as-banked step.
Because it's one system, a round is built from real demand: sales orders feed the unrouted pool, stock is what actually goes on the van, and the whole buy-stock-sell-deliver picture is in the wholesale ERP overview.
Frequently asked questions.
What does delivery route planning software actually do?
It turns a pile of deliveries into planned multi-drop rounds, then records what happened on the road. In Cobalt that means a day board of unrouted deliveries filtered by zone, a route you build with a preview of capacity, zones, conflicts and driver hours, a map with numbered pins, and proof of delivery coming back from each stop. It plans and evidences your own deliveries — it does not notify your customers, and there is no buyer-facing tracking link or appointment booking.
Does it work without a mobile signal?
Yes. The driver page works offline. A service worker keeps a booting shell plus the last-known session and run data on the device, and every action a driver takes queues in an outbox with retry, so a drop made in a dead-zone is recorded at the door and syncs once the van is back in coverage.
Do drivers have to install an app?
No. The driver page is a web page in the phone's browser, so there is nothing to download, approve or update from an app store. A driver signs in once and it keeps working, offline included. If a phone leaves the business, a "forget this device" wipe clears the cached run and any queued actions from it.
How does proof of delivery work?
Each stop captures a photograph, a signature, GPS and a per-line outcome, so a part-delivery is recorded line by line rather than as one yes or no. Proof of delivery is on the Growth plan and above. A drop completed offline can be backdated to the time it actually happened, but it can never be future-dated.
Can drivers collect cash on delivery?
Yes, on the Scale plan. Deliveries that need doorstep cash are badged on the day board, drivers record what they collected against each stop, and the end-of-day debrief is per currency and per method, with custody references, maker-checker and a mark-as-banked step so cash is reconciled rather than trusted.
Which plan do I need for delivery routing?
Route planning with the day board and preview, fleet master data, route templates, proof of delivery and delivery performance reporting are on the Growth plan and above. Per-driver runs, publish and unpublish, amend and replan, load and unload scan manifests, the readiness checklist, the cash debrief and the fleet optimiser are on the Scale plan — and the optimiser returns a proposal you review and apply to a draft or planned run, not an automatic change.
Related pages.
Give your drivers a plan they can trust.
Route your own vehicles, publish the round, and get proof back from every drop — signal or no signal.
Join waitlist