Kybotech Route Planning

Reverse-requirements specification — what the new planning system does, and the rules it plans to.

Working document, drawn from the built prototype. Intended to replace the current planning software, and to add a load-auditing (backtest) facility. Figures shown are from synthetic demo data.

Executive summary

What it is — a bespoke route-planning and load-auditing system to replace today's Paragon + manual adjustment.
The alpha — it optimises driver & vehicle utilisation, not generic miles: it minimises true cost (van-days × day-fee + mileage, where the day-fee is ~77% of the bill). It exploits mid-day reloads, runs efficient overnight (two-day) runs instead of long return-to-depot detours, schedules across a rolling week, and targets 90–95% fill — modelled on how Kybotech actually runs, so there is nothing to frig afterwards.
The money — the load-audit measures the gap between today's plan and cost-true optimisation; the saving lands mostly in driver-days, the expensive lever. (Synthetic demo ~30–45%; the real figure comes from Kybotech's own runs and self-billed invoice.)
Two facilities — a live planner (plans next week, editable) and load auditing that also verifies the self-billed contractor invoice.
Where it stands — the engine, planner, rolling-week scheduling and auditing are built (prototype). Kybotech already has its driver app, ePOD and ETA notifications (and runs no telematics, by choice); the genuine gaps are exact road distances (OSRM), traffic-aware live ETAs, a live (ephemeral) dispatcher map, and a live order feed.

Detail and the constraint definitions follow below.

1. Purpose & scope 1.1 The alpha vs. Paragon 2. The two facilities 3. What it optimises for 4. The freight 5. Planning constraints 6. Run types 7. How it decides 8. Data inputs 9. Architecture & hosting 10. Built vs. outstanding 11. Vs. standard systems (gaps) 12. The production tool

1. Purpose & scope

Kybotech runs its own vans out of Worksop, delivering garden buildings (sheds, summerhouses, log cabins, playhouses) and small spare parts, and collecting returns — often on the same run. Planning is currently done by hand / existing software. This system replaces that with an optimising planner and adds a load-auditing facility to measure how much good planning saves.

The premise: the contractor is paid a fixed day-rate per van-day plus pence-per-mile (round-trip to depot). Because the day-rate dominates (~¾ of cost), the prize is using fewer, fuller van-days — not just fewer miles. The system optimises for total cost on that basis.

1.1 The alpha — what this gives over the current setup

Today Kybotech plans with Paragon (off-the-shelf) plus manual adjustment ("frigging") afterwards. Paragon optimises generically — broadly to miles/time — and the planner then hand-corrects it for what Paragon doesn't model. In practice that means mid-day reloads are barely (if ever) used, and two-day runs take long, cautious detours (effectively the return-to-depot dilemma rather than an efficient overnight).

What this bespoke system actually optimises is utilisation of the driver and the vehicle — because the cost is a fixed day-fee per van-day plus mileage, the expensive thing is a van going out at all, and going out under-used. The alpha:

Lever	Paragon + manual (today)	This bespoke system	The gain
Objective	minimise miles / time (generic)	minimise true cost = van-days × day-fee + miles	targets the ~77% that is the day-fee → fewer driver-days
Mid-day reloads	barely used	modelled — one van does a second load before 4pm	fewer vans out
Two-day runs	long, cautious detours	efficient overnight (B&B), distance-capped, by discretion	kills the doubled long drive
Rolling week	limited	each order on the cheapest day in its window	spreads work so vans fill
Fill rate	incidental	90–95% utilisation target	full vans by design
Hand-editing	required (the "frigging")	constraints built in → usable as-is	planner time saved, fewer errors
Auditing	none	verify the self-billed invoice + prove the saving	a facility Paragon doesn't have

The alpha in one line: an off-the-shelf optimiser plans routes; this plans the utilisation of the driver and the van the way Kybotech actually runs — reloads, weight, efficient overnights and self-billing built in, so there's nothing to frig afterwards. Monetary value: the load-audit measures the gap between what was actually run (Paragon + manual) and cost-true optimisation — that gap is the saving, landing mostly in driver-days, the expensive lever. (Synthetic demo: ~30–45%; the real figure comes from Kybotech's own data and invoice.)

2. The two facilities

Facility	What it does	Direction
Load auditing (backtest)	Re-solves a past period optimally under the same rules a planner worked to, and compares the cost against the self-billed contractor invoice (what was actually run and paid). The gap is the achievable saving — and the same figures verify the invoice itself (see §2.1).	Looks back. One-off / periodic.
Live planner	Takes the week's orders, produces optimised per-van run sheets (route, ETAs, load on board), shows them on a map, and lets a planner override (move a drop to another van).	Looks forward. Daily use.

Both use the same optimisation engine — the auditing facility points it at last month; the planner points it at next week.

Honesty rule for auditing: the baseline is what was actually run and paid — the self-billed invoice and the runs as made — never re-modelled. Kybotech does not use telematics (and doesn't want it): the driver app shows live position during the day but it is not stored beyond that day, for privacy. So the audit's "actual" is the self-billed figures (van-days, miles, overnights as paid), not a GPS trace. Both sides are then costed identically, so the gap is a true like-for-like saving.

2.1 Self-billing & the invoice audit

Kybotech runs self-billing: it raises the contractor's invoice itself — a fixed day-fee per van-day plus mileage (round trip to depot) — and the contractor pays that self-billed invoice. The formula is fixed, so the self-billed invoice is the audit baseline: measured, formulaic, and exactly what was paid. The auditing facility does two jobs with it:

Verify the invoice — re-apply the formula (van-days × day-fee + miles × rate + overnight contributions) to the figures the runs were billed on, and flag any arithmetic or rate error, miscounted van-days, or missing/incorrect overnight payments before payment goes out. (Mileage isn't cross-checked against GPS — there's no stored telematics; the audit works on the billed run figures.)

Benchmark the invoice — compare that self-billed total to what an optimised plan would have cost. The gap is the saving the new planner would have delivered.

Both reduce to the same formula on the same measured inputs, which is why the audit is clean: one number you paid, one number you could have paid, computed identically.

3. What it optimises for

One number, minimised across the whole horizon (a week solved as a single problem, not day-by-day):

Total cost = (van-days × day-rate) + (miles × cost-per-mile) + (overnight contributions)
The overnight contribution is what Kybotech pays toward the driver's B&B/Travelodge on a two-day run — a real billed line, paid per overnight. Demo values: day-rate £200, £0.45/mile, £40/overnight. Day-rate is ~77% of cost, so the optimiser's first priority is to need fewer van-days.

The levers it pulls to do that:

Consolidate — give one van a full day's work rather than two half-days.
Full legal days — pack each paid day to the hours limit before opening another.
Reload — return to depot for a second load rather than send a second van.
Cluster by area — minimise miles within each van-day.
Defer within the window — place a flexible order on the cheapest day a van already passes.

Fill-rate target. Beyond minimising cost, every dispatched van should be well loaded — target ≈90%, ideally 95% of capacity (by whichever of volume/weight binds). A van going out half-full is the thing to avoid. This is both an objective (the optimiser favours full loads) and a reporting KPI per van-day.

4. The freight

Every order is one stop. Two quantities matter for loading — volume (loadspace) and weight — because garden buildings are bulky and heavy; a van fills on whichever binds first.

Type	Loadspace	Weight	Handball	Notes
Shed	low–mid	150–450 kg	~20–30 min	the bread & butter
Summerhouse	mid–high	400–800 kg	~25–40 min
Log cabin	high	850–1400 kg	~35–55 min	~1 per van by weight; may split across 2 drops
Playhouse	low–mid	180–380 kg	~18–28 min
RDM (spare part)	tiny	5–40 kg	~8–12 min	takes a slot, ~no space; good defer candidate
Collection	varies	varies	~15–25 min	a return — adds to the load on the way back

All handball by the driver, one item at a time — no two-man drops.

5. Planning constraints

These are the hard rules the optimiser honours, and the same rules the auditing baseline is held to.

5.1 Capacity — volume and weight

A van carries up to its loadspace (≈100 units) and its payload (1.5 t). A load is full when either binds. Drops and collected returns are tracked as two commodities so a return can't "fund" a delivery — sheds on board + returns on board ≤ capacity at every stop.

5.2 Reloads (mid-day)

A van can return to Worksop to reload (≈45 min) and go out again — so capacity binds per trip, not per day. The depot closes mid-afternoon (≈16:00), so a second load only happens if the van gets back to reload before the cutoff. (Drivers most often reload in the morning.)

5.3 Driver hours / the paid day

A paid van-day is planned to GB domestic driver hours — roughly a 10-hour driving / 11-hour duty day, including handball. Vans are <3.5 t (GB domestic, not EU rules). This is treated as a prudent single-driver day; although the contractor could swap drivers/vehicles mid-run (only driver codes are tracked), we do not over-spec on that.

5.4 Billing & the round trip

The contractor is paid a fixed day-fee + mileage for the round trip back to depot. Drivers actually take the van home, but mileage is billed as if it returned to depot, for completeness — so the model costs the depot → drops → depot round trip. Where the driver lives is their own affair.

5.5 Two-day runs (= overnight / tramping runs)

Terminology. At Kybotech a "two-day run" means an overnight run — the van sleeps over at a B&B / Travelodge somewhere en route. "Two-day run", "overnight run" and "tramping" are the same thing; this document uses two-day run. (Earlier drafts wrongly treated them as separate — they are not.)

A reload does NOT make a run two-day. A reload is mid-day — drive back to the depot for a fresh load and out again — and the van is still home that night, so it's a single-day run. Volume and weight are handled by reloads within a day. A run is two-day for exactly one reason: distance — it is so far to the first drop that the van cannot deliver everything and get home inside one legal day, so it stays out overnight.

The hard limit — GB domestic driver hours (vans <3.5 t): max 10 hours driving and 11 hours duty (driving + handball) per working day, with ≥10 hours rest between days. Firm — the planner never schedules beyond them, so there is no incentive to do 15–16-hour days. (For a self-employed contractor driver, "duty" legally counts only driving + load work, not waiting — but we plan to the prudent 10h-drive / 11h-duty day regardless.)

Distance limits, from Worksop:

Single-day run: reaches roughly 200–250 miles one-way — the round trip plus the drops has to fit ~10h driving. (May include a mid-day reload; still one day.)
Two-day (overnight) run: reaches roughly 300–350 miles one-way — almost anywhere in GB (Cornwall ≈300 mi, Inverness ≈350 mi). Beyond ~350 mi one-way, even two days can't deliver and get the van home — an exceptional 3-day case, or not served from Worksop. This maximum two-day distance is a configurable cap.

How a two-day run works: Day 1 — drive out, deliver to the hours limit, then sleep at a B&B near wherever the day actually ends (dynamic — not a fixed hub). Day 2 — finish the deliveries and drive home. One drive out, one drive home, the overnight in between. Cost = two day-fees + the round-trip mileage + one overnight subsistence (~£40).

What we deliberately do NOT do: drive all the way back to the depot at the end of day 1 and out again on day 2 — that doubles the long drive and is needlessly expensive. The overnight B&B is the whole point. The model works this way: a run is single-day (reloading if useful) until the legal day genuinely can't hold it, at which point it becomes a two-day overnight run within the distance cap.

5.6 "Tramping" — same as a two-day run

"Tramping" is Kybotech's other word for the two-day overnight run in §5.5 — they are one and the same. There is no separate concept.

5.7 Time-of-day windows

Some orders are booked appointments (e.g. AM 08:00–12:00). The van must arrive within the window on whichever day the stop lands. Wide windows give the planner room; narrow ones fragment routes.

5.8 Delivery-date windows (the rolling horizon)

The planner works from a rolling pool — the week's orders, each of which must be delivered somewhere in the week. Every order carries an earliest and latest date; the optimiser places each on the cheapest day within that window — usually the day a van already passes nearby. This is the single biggest lever, and it is commercial as much as technical: the more orders you can leave flexible, the lower the cost.

Accepted dates are locked. The default is "deliver on the most optimal day". But once a customer has been offered and accepted a specific date, that order is pinned and must not move — except for a dire reason. From time to time a customer will demand a switch (move from one day to another); the planner makes that change, the affected orders are re-pinned, and the rest of the week is re-optimised around the fixed points (see the re-optimise point).

5.9 Mixed delivery & collection

Drops and collections share a run. The van leaves loaded with the trip's drops; drops reduce the load, collections add to it; the running total stays within capacity throughout, and collected goods return to depot.

5.10 Other

Every route starts and ends at the depot.
A log cabin split across two drops (same order_id) is kept on the same van, same day.
Each order is served exactly once across the horizon.

6. Run types

Only two kinds (see §5.5 for the terminology fix):

Single-day run — out from depot, deliver, home the same day. May include a mid-day reload (back before 16:00 for a second load) — still one day. The norm.

Two-day run = overnight run — too far to get home in a legal day, so the van delivers en route and sleeps at a B&B overnight, finishing and driving home on day 2. Distance-capped. (Kybotech also calls this "tramping".)

7. How it decides which orders go on which van & day

From the whole order pool, the optimiser assigns each van a geographically tight cluster that fills a load, on the cheapest day within each order's window, to minimise total van-days + miles — subject to every constraint above. A van's orders are therefore not arbitrary: they are near each other and together make an efficient load. The planner can override any assignment by moving a drop to another van (the route re-sequences live).

Order poolweek's drops & collections, with windows

→

Cluster & assigntight loads, cheapest day

→

Sequenceroute, reloads, hours

→

Run sheetsETAs, load, map

8. Data inputs (the order contract)

For the planner: orders come from Kybotech's own system, so the interface is a defined export (CSV/JSON now, live feed later). Minimum per stop: stop_id, type (drop/collect), location (lat-lon or postcode), volume, earliest_date, latest_date. Recommended: weight, service_min, tw_start/tw_end, product, order_id (for cabin grouping). Fleet (vans, capacity, depot, rates) is configured separately and changes rarely.

For the audit: the self-billed invoice / run records (per van-day: day-fee, miles, overnights, days taken, which van ran what). No telematics feed is needed or wanted — the audit verifies and benchmarks against these billed figures.

9. Architecture & hosting

One hard fact shapes everything: the optimiser (Google OR-Tools, a C++/Python library) cannot run on the web edge (Cloudflare Workers/Pages are a JavaScript sandbox with no native libraries). So the solve runs on a real computer; the screens are just viewers.

Solver boxOR-Tools + OSRM distances
(office PC, a small VM, or a container)

→

Results / run sheetsstatic JSON

→

Viewer (edge)dial · map · planner
+ live manual edits

Distances & roads: a self-hosted OSRM instance (off OpenStreetMap) gives exact road distances and road-shaped routes, unlimited and ~free — the right choice at hundreds of stops a week. (The demo currently approximates with great-circle × a road factor.)
Edge viewer: the dashboards and the planner's manual editing (move a drop, live re-route) are pure browser code, so they run on Cloudflare. Only solving a brand-new upload needs the solver box.

10. Built vs. outstanding

Area	Status
Optimisation engine (cost objective, all §5 constraints, verified)	Built
Load-auditing backtest (measured baseline vs optimised)	Built
Live planner — run sheets, ETAs, reloads, map, manual move, CSV export	Built (prototype)
Rolling-week scheduling within delivery windows	Built
Scale to the full fleet (regional decomposition)	Built (heuristic)
Exact road distances & geometry (OSRM)	Outstanding — demo approximates
Address → coordinates (geocoding) for postcode-only feeds	Outstanding
Live feed from the order system (vs file export)	Outstanding
Tramping: choose stopovers / optimise the overnight properly	Approximate
Hosting the solver for shared use (VM / Cloudflare Container)	Outstanding — runs locally now

11. Compared to standard route-planning & load-auditing systems

Mainstream route-optimisation platforms (e.g. Descartes, Paragon/Aptean, Verizon Connect, OptimoRoute, Routific, Onfleet, Track-POD) share a common feature set. Below is what they typically offer, and where this system stands — to make the gaps explicit.

Capability	Standard systems	This system
Multi-stop optimisation, time windows, capacity (weight/volume/pallets)	Yes	Yes — incl. volume + weight
Mixed delivery & collection (backhaul)	Usually	Yes
Multi-day / rolling-horizon scheduling within date windows	Sometimes	Yes (a strength here)
Driver-hours / WTD / break compliance	Yes (fleet-grade)	Out of scope — contractor's responsibility. Drivers are the contractor's (may swap drivers/vehicles en route); breaks are at driver discretion, and wide windows give the slack.
Manual edit / drag-drop reassignment, locked stops	Yes	Move a drop; locked dates (spec'd)
Dynamic re-optimisation (mid-day disruptions, add/remove live)	Yes	Re-optimise point spec'd; not yet live-tracked
Driver mobile app + navigation	Yes	Have — Kybotech's own driver app
Electronic proof of delivery (photo, signature, barcode)	Yes	Have
Customer ETA notifications (SMS/email)	Yes	Have
Live GPS tracking	Yes (often telematics)	Position comes from the driver app during the day (no telematics, by choice); not stored beyond the day for privacy. Could be surfaced as a live, ephemeral map.
Traffic-aware ETAs / live road speeds	Yes	Gap — see options below; OSRM (planning) + a traffic API (live ETAs)
Order-system / ERP integration (live feed)	Yes	File export now; live feed to build
KPI / utilisation dashboards, fill-rate reporting	Yes	Audit report yes; ongoing dashboard to build
Cost-model optimisation (day-rate + mileage, not just miles)	Rare	Yes — core to it
Load auditing (measured baseline vs optimised, £ saving)	Rare	Yes — a distinctive facility
Skills / vehicle-access / tail-lift constraints, SLA priority tiers	Yes	Not modelled yet

Where this is stronger than off-the-shelf: it optimises true cost (day-rate + mileage), it does genuine rolling-week date scheduling, it has a built-in load-auditing / saving-proof facility, and it models reloads, weight, and tramping the way Kybotech actually runs.

The real remaining gaps (Kybotech already has its own driver app, ePOD and customer ETA notifications; break compliance sits with the contractor): live GPS tracking, traffic-aware ETAs, a live order feed, and access/skill constraints.

11.1 Live GPS & traffic — options

Two separate things, with different answers:

Need	Best approach
Planning the week's routes	You don't need live traffic to plan ahead. Use OSRM with time-of-day speed profiles (rush-hour slower) baked from historical data — free, fast, accurate enough for next-week scheduling.
Live tracking on the day	The driver app already reports position during the day (it powers ePOD & ETAs). Surface that as a live map for the dispatcher — but keep it ephemeral (today only), not stored, per the privacy stance. No telematics needed.
Traffic-aware customer ETAs	Use a traffic-aware routing API only for the live ETA (not the bulk optimise): Google Routes API, Mapbox, HERE or TomTom. Called per active stop on the day, the cost is small. Keep OSRM for the heavy weekly optimisation (a traffic API on the full matrix would be expensive).

Rule of thumb: OSRM (free) for planning, a traffic API (paid, sparingly) for live ETAs. Live GPS comes from the kit you already run.

12. The production tool (vs. this demo)

The demo carries scaffolding to explain the concept — Today-vs-Optimised toggles, "no-reload" comparisons, worked scenarios. The production tool drops all of that. Installed into a real process, everything is already optimised, so those comparisons don't exist. It reduces to:

Settings — rates (day-rate, £/mile), capacity (volume, 1.5 t payload), hours (11h day), reload cutoff (16:00), fill-rate target (≈95%), fleet. Set once, change rarely.

Optimise — one button. Pulls the rolling-week order pool and produces the plan.

Manual levers (light) — move a drop to another van; toggle reload on/off per van (default on, turn off if marginal). That's it — no scenario switches.

Re-optimise point — see below.

The re-optimise point

Plans aren't static. A customer is offered and accepts a date → that order is locked. A customer later demands a switch → the planner moves it and locks the new date. Either way, the system then re-runs the optimiser holding all locked orders fixed and re-sorting the rest of the flexible pool around them — so the week stays optimal without disturbing committed promises. So there are really two states: flexible (the optimiser owns the day) and locked (the customer owns the day, the optimiser plans around it). The re-optimise button reconciles the two whenever something changes.

In short, the production screen is: Settings → Optimise → review the run sheets/map → adjust the odd order or reload toggle → Re-optimise when a customer commitment changes. Nothing more.

This document describes the prototype as built, plus the agreed production direction. Numbers and product details use synthetic demo data; the real saving and fleet figures come from Kybotech's own exports.