Routes

Today, this driver, these stops, in this order

A route is a day’s execution plan. It is not a promise, it is not a territory and it is not a recurring agreement — it is the order somebody is actually going to drive in, this morning, with these fourteen stops on it.

It serves a courier run and a technician stacking three preventive maintenance visits in one afternoon equally well, because those are the same problem: work that already exists, in an area, that has to be put in a sensible order and handed to a driver.

Two different things get called the route

In a courier office the word “route” means two things in the same sentence, and software that conflates them ends up unable to answer either question.

The commitmentThe plan
“Twice a week to this bank, forever.” “Today, Marcus, these fourteen stops, in this order.”
A promise. It generates work, on a cadence, inside a window. A sequence. It orders work that already exists.
Lives for years. Breaching it is a conversation with a customer. Lives for a day. Changing it is a phone call to a driver.
Holds only the stops it promised. Holds whatever fell in the area — including the emergency that came in at nine.

A quarterly rooftop inspection and a twice-weekly bank bag run are the same commitment object, authored the same way — that is covered on the office page. This page is the other half: what happens on the morning somebody has to go and do it.

A courier run held as a recurring commitment: two hundred stops, twice a week, authored as one agreement.

The commitment side: a two-hundred-stop run, twice a week, as one object. The plan is what a day of it turns into.

What a plan actually holds

  • A driver and a day. One plan, one person, one date. A second van is a second plan, which is what makes both of them readable.
  • Stops, in a real order. Each stop is a visit that already exists on the board, so a route never becomes a second copy of the work with its own version of the truth.
  • Anchored stops. A bank cutoff, a promised window, a first-thing or last-thing commitment — pinned so nothing rearranges it. That is the flag that stops a cash drop being “optimised” to 4:55pm.
  • The drive between stops, as a forecast. Held per leg and kept separate from what the drive actually took, because a plan and a fact are different numbers and mixing them makes both useless.
  • A status with meaning. Planned, released, in progress, completed, cancelled — and code reads what a status means rather than what it is called, so a shop that adds its own still gets correct behaviour and correct reporting.
Released is the moment that matters Before the manifest is on the driver’s handset, re-ordering is just planning. After it, a re-order is a change somebody has to be told about. The plan records that moment, so the difference is a fact rather than a judgement call.

Re-order it — and the record says who did

Moving a stop is a drag, and the stops around it do not have to be rewritten for it to land — the order has room built into it, so re-ordering a long run is cheap even at two hundred stops.

The part worth knowing is smaller and more important: the plan records whether a human or a machine put the stops in that order. When a dispatcher moves one, the plan stops claiming a solver produced it.

An audit line that says “the order changed” is worth very little. One that can say “the optimiser put the bank last, and then Dana moved it to first at 7:12” is worth the whole argument.
  • A visit belongs to at most one plan, so two dispatchers cannot both own the same stop.
  • A finished route is frozen. Yesterday’s plan is evidence, not a scratchpad.
  • Every change is audited, with the person and the time, like everything else in the platform.

What the driver gets

The same field app a technician uses. A courier run is a service call with a shorter clock — so it is the same day, the same clock, the same capture, just more stops and less time at each.

It starts with the vehicle, not the paperwork

The driver scans the van — or the bag — they are taking out today. Nobody is permanently assigned to a vehicle, because in real life the truck breaks and they take another one and carry on billing off it.

  • Directions from every stop, straight into the phone’s own maps app, built from the address and sharpened to the exact coordinate wherever one is known.
  • The access notes for that site — the gate code, which door, who to ask for — which is the difference between a four-minute stop and a fifteen-minute one.
  • The workflow for that stop: the photograph, the barcode scan, the signature. Chain of custody is a checklist, not a separate product.

What a checklist captures →

Choosing the truck being taken out for the day on the phone, before any work starts.

Pick the vehicle you actually took.

The truck screen: scan the van or bag being taken out today, because a truck is modelled as a warehouse.

A truck is a warehouse, and so is a bag. Scan it at the start of the day and what gets picked up lands in it — which is what makes a deposit run traceable without inventing a custody subsystem.

A site record with its access notes, gate code, the equipment on site and the site's own service history.

What every stop carries with it. The gate code belongs to the site, so the third driver to cover that run knows it too.

A route is an API object, not just a screen

Every capability in the platform exists on every door at once — the screen, a documented REST route and an agent tool — and routes are no exception. Nine of them: create or change a plan, find the plans, read one with its stops, add or move a stop, reclaim room in the ordering, change the status, list the statuses this shop uses, remove a stop, delete the plan.

Which means a broker’s system, a spreadsheet somebody already maintains, or an agent can build tomorrow’s run without anybody opening a browser — and it goes through exactly the same permissions, locks and audit trail as a dispatcher dragging a stop.

The capability list in the portal, each capability shown with the agent tool name that reaches it.

Every capability, with the tool name that reaches it from an agent. Nothing on this list is screen-only.

How the doors work, and why your data stays yours →

Where it is today

We demo this in person to people who ask to see things, so here is the line drawn where it actually falls rather than where it would be convenient.

Running todayNot built yet
The plan, its stops, the order, the anchors and the statuses — on the API and on the map board. Automatic sequencing. The travelling-salesman pass that proposes an order does not exist. Ordering is a human’s today — and the plan already records which, so the day a solver lands nothing has to be retrofitted to tell the two apart.
Stops on a map, in sequence, as one of the map board’s layers. Map boards → The office’s own route screen. A day is planned through the API and read on the map; a dedicated planning board is next.
Directions from every stop on the driver’s phone, built from the address and sharpened to the coordinate where one is known. Drive-time forecasting. The plan holds an estimate per leg and keeps it apart from what the drive actually took. Nothing fills it in automatically yet.