RouteFlow

Cut dispatch planning from three hours to twenty minutes.

RouteFlow replaces a courier's manual morning route-planning spreadsheet with an automated dispatch engine: live order data streams in via webhook from the courier's existing order system, a constraint solver builds routes against driver shift windows and vehicle capacity, and the output pushes straight to drivers' handheld scanners. Dispatchers review a generated plan instead of building one from a blank sheet.

Webhook ingestionLive order syncConstraint-based routingAutomatic re-planning

Client: Regional courier
Industry: Logistics
Our role: Process mapping, solver design, integration, rollout
Status: In production

The short version

The dispatcher's job was never meant to be arithmetic. It was meant to be judgement — and the spreadsheet left no time for it.

The outcome

Measured after launch,not promised before it.

0188%

less planning timeMorning planning dropped from close to three hours to around twenty minutes of review.

021,400

hours a year savedTime handed back to dispatch every year — spent on exceptions and customers instead of spreadsheets.

03+12

points on-time rateVans leave earlier and routes respect real constraints, so more deliveries land inside their window.

On this page

The situation
Before & after
How it works
What we built
The key decision
How we delivered
What we learned

Services usedWorkflow Automation

The situation

The client is a regional courier running a mixed fleet of vans on same-day and next-day routes. Orders arrive continuously through their own order system, but routes were planned once, by hand, first thing every morning. The whole day's efficiency depended on one dispatcher's spreadsheet — and on that dispatcher being at their desk early enough for the first vans to leave on time.

Manual route planning doesn't scale

Each morning a single dispatcher opened a spreadsheet, cross-referenced driver locations, delivery windows and vehicle capacity by eye, and built that day's routes from scratch — a process that took close to three hours before the first van could leave. That's workable for a ten-stop day. It breaks down the moment order volume passes what one person can hold in their head, or a driver calls in sick and the whole plan needs redoing mid-morning.

Before and after

Before

Routes built from a blank spreadsheet every morning
Driver shifts and van capacity checked by eye
A sick call meant rebuilding the plan by hand mid-morning
Routes read out or re-typed onto drivers' scanners

After — RouteFlow

Orders stream in live and a full plan is generated automatically
Shift windows and capacity enforced as hard constraints
Changes trigger an automatic re-plan in the background
Finished routes push straight to the handheld scanners

How it works

Workflow orchestration handles the ingestion and re-planning triggers, a constraint-solving service builds the routes, and the courier's existing order system and handheld scanners stay as the source and endpoint — nothing for the driver-facing team to relearn.

01 · Ingest
Orders arrive by webhook
Every new or changed order in the courier's existing system fires a webhook — no exports, no copy-paste, no stale data.
02 · Solve
Constraint solver builds routes
Stops are assigned against each driver's shift window and each vehicle's capacity, so every route is one a driver can actually complete.
03 · Review
Dispatcher approves, not assembles
The dispatcher reviews a generated plan and adjusts edge cases — the part of the job that genuinely needs local knowledge.
04 · Deliver
Routes land on the scanners
Approved routes are pushed to drivers' handhelds, and any mid-morning change re-plans only what's affected.

Workflow orchestrationConstraint solverWebhooksREST integration

What we built

We replaced the spreadsheet with a live planning engine end to end:

01Webhook-based ingestion from the existing order system — no manual export step
02A constraint solver that builds routes against driver shifts and vehicle capacity automatically
03Automatic re-planning when an order or driver status changes mid-morning
04Route output pushed directly to drivers' existing handheld scanners

Why we didn't just add a "smart" route sort

The easy way

Sort the stops by distance and call it optimisation.

What we did instead

A real constraint solver that treats shifts and capacity as hard limits.

The easy version of this project sorts existing stops by distance and calls it optimisation — it's a half-day build, and it's what most off-the-shelf tools default to. It falls apart the moment two drivers have different shift end times or a van can't fit what's assigned to it, because a distance sort has no concept of those constraints and will happily build a route no driver can actually complete. We built a proper constraint solver instead — slower to ship, but it treats shift windows and vehicle capacity as hard limits rather than an afterthought, which is the difference between a route that looks efficient on paper and one a driver can actually run.

How we delivered

Working software early, then the full build — with the client using it at every step.

Week 1
Shadow the morning
We sat with the dispatcher through real mornings and wrote down every rule they applied without thinking about it.
Week 2
First generated plan
The solver produced its first real plan from live orders, run side by side with the manual one for comparison.
Build-out
Re-planning & scanners
Automatic re-planning on order and driver changes, plus the push to handheld scanners.
Handover
Runbook & ownership
Documentation, credentials and a walkthrough, so the courier's team can tune the rules themselves.

What we learned

Lesson 01

Write down the invisible rules first

Most of the value came from the week spent capturing what the dispatcher 'just knew'. The solver is only as good as the constraints you give it.

Lesson 02

Run it in parallel before you switch

Comparing generated plans against manual ones for a few days built the trust that made the switch uneventful.

What's next

With routing stable, the natural next step is feeding delivery outcomes back into the planner, so recurring late stops can be spotted and scheduled differently.

Run the numbers