Dispatch Board

Sidebar → Dispatch. Three columns, because that is the shape of the decision: what has to move, what is moving it, and who is free to drive it.

Column	What is in it
Connotes (left)	Freight that is booked and on nobody’s truck.
Manifests (middle)	The runs. This is the column where a run is actually built, which is why it is the widest.
Dispatch Units (right)	Trucks and crews, and whether each can take work.

The two outer columns are registers you scan to find a row; the middle one is the work. On a wide monitor the extra width goes to Manifests rather than being shared out evenly. Below about 992px wide the three stack into one column.

Putting freight on a run

1. Select connotes. Click one to select it, shift-click for a range, ctrl/⌘-click to add one to the selection.
2. Drag the selection onto a manifest card. The card you are over is highlighted with a dashed ring while it will accept the drop; the cards you are dragging are outlined and lifted.
3. Drop. Each dropped card dims and reads Attaching… until the server has taken it, and cannot be dragged again meanwhile — so a slow line never tempts you into a second drop. The connotes are then allocated to that manifest and leave the Connotes column. If one is refused, it comes back straight away with the reason; the rest of the drop carries on.

Two dangerous-goods classes may not share a run. Dropping a connote whose DG class differs from one already on the manifest is refused, and the message names the classes. Dangerous goods beside ordinary freight is allowed at this stage — the load plan keeps them on separate decks.

A connote can be on more than one run. Allocating a connote that is already on another manifest is no longer refused — it becomes the next leg of its journey, which is what changeovers need. That also means a mis-drop is not caught for you: if a card shows a leg badge you did not intend, take it off (see One connote across several runs below).

To take freight back off a run, hover the connote chip on the manifest card and click the ✕. The connote returns to the Connotes column.

Assigning a unit

Drag a card from Dispatch Units onto a manifest, or set it from the manifest’s Assigned unit panel in the detail pane. The board will tell you when the load is already over the unit’s recorded payload — and will say so in terms of the recorded figures, because that is all it has.

Build the stops, then dispatch

Allocating freight puts it on the run; it does not write the run’s stops. That is a separate, deliberate step so a reroute is never rebuilt underneath you.

When freight on a manifest has no stop yet, the detail pane shows Build stops (or Build N more when some stops exist). Press it to copy each connote’s pickup and delivery onto the run. Stops that exist but could not be placed on the map offer Locate N stops instead.

⛔ A run whose freight has no stop cannot be dispatched. Moving it to Dispatched is refused with “N connote(s) on this run have no stop — press Build stops before dispatching.” Without stops the driver’s app has nothing to arrive at and no way to finish the run.

Each stop carries the address’s own special instructions and the booking’s Special Instructions, shown once when they are the same, so the driver sees them in the app. Stops built before this change are not rewritten — rebuild them if a driver needs the booking’s note.

Creating a manifest

New manifest in the page header. It asks for a manifest number, service date, unit, origin, destination and notes — and none of them is required. The number is generated if you leave it blank, and a manifest can exist before anyone has decided who drives it: leave the unit empty and drag one onto the card later. Either way it is raised as a draft.

Creating a unit

+ Build Unit, at the top of the Dispatch Units column rather than in the page header — it is where you are already looking at the moment you discover the truck you want is not listed. See Units and rebuilds.

Filtering

Each column has its own search box:

• Connotes — connote number or customer
• Manifests — manifest number or lane, plus a status filter that defaults to All live. The Trucks button beside it shows or hides the truck drawing on each manifest card. It is off by default — the card’s load line and capacity bar carry the same figures — and your choice is remembered in this browser. The detail pane always draws the truck.
• Units — alias, driver or rego

Manifest statuses

Status	Meaning
Draft	Being assembled. Not committed to.
Planned	Built and intended to run.
Pending approval	Waiting on a human decision.
Dispatched	Released to the driver. Not moving yet.
Accepted	The driver has taken it in the app. Not moving yet.
In transit	Moving.
Completed	Finished.
Cancelled	Abandoned.

The card’s actions

A manifest card’s buttons are folded away so the card shows freight, not paperwork. They appear when you hover the card, tab into it, swipe it left on a touch screen, or press the ⋯ button. What you get depends on the status:

Status	Actions
Draft	Plan
Planned	For approval, Dispatch
Pending approval	Approve, Reject (back to planned)
Dispatched / Accepted	Start, Recall (back to planned)
In transit	Complete

Every status before in transit also offers Cancel. View details is on every card, for every role — it opens the detail pane, including on completed and cancelled runs. A driver can also accept, decline, start and finish a run from the app; a decline sends the run back to planned. Starting a run on a driver’s behalf (the phone is flat) is allowed and is recorded without an acceptance.

Dispatched, accepted and in transit are the three that make a unit live, and a live unit is treated differently — see the mid-run rule in Units and rebuilds.

The detail pane

Selecting a manifest card opens a pane across the bottom of the screen. The columns keep working above it. The expand button in the pane’s header gives it more height on a laptop or tablet, and gives it back with the same click.

Panel	What it shows
Stop timeline	Planned against actual on a time axis, with the stops along it.
Assigned unit	The unit, its crew, its availability, its capacity.
Vehicle	Registration, type, depot.
Cargo	The allocated connotes, and what they consume.
Load plan	Where each item sits on the deck — see Load plan.
Route map	The stops drawn on a map.
Route stops	The stop list, reorderable.
Suggestions	Freight that would fit this run, ranked, with a reason for each — see below.
Changeover	Freight this run is handing to another, and freight another run is handing to it.

An unplaced count sits in the pane’s header, next to the manifest number. It is there rather than beside the drawing on purpose: a picture of a well-packed deck with a hidden “3 unplaced” underneath it is the exact failure this feature exists to avoid. When the plan is clear the chip is empty — a permanent “0 unplaced” would only train you to stop reading it.

Suggestions

The Suggestions panel ranks waiting connotes for the selected run. Each one shows a match percentage and the reasons behind it, one line per factor.

• A ✓ score is at or above the threshold on complete information.
• A score marked for a person to decide is either below the threshold or was measured with something unknown. A factor nobody recorded is left out of the score, never counted as a bad match — and an unknown always sends the suggestion to a person, however high the rest scored.
• A connote that cannot go on this run is still listed, greyed, with the reason (for example a DG class clash). It is never silently left out.

Add to run allocates it, exactly like a drag. Not this one records that it was offered and refused. Both are writes, so read-only users see the ranking without the buttons.

Changeover: two runs meeting

A changeover is two runs meeting to exchange trailers, each carrying on to its own drops. The Changeover panel on the detail pane is where you record one — not a button on the manifest card, because it needs a receiving run, a unit, a time, a place and a reason.

Hand over to another run opens the form. Choose the run collecting, the unit taking the freight, when and where it happened, and why. The reason is deliberately blank until you pick one: there is no default reason for freight changing hands.

The panel keeps two lists apart on purpose:

List	What it means
Waiting for this run	Another run has released freight towards this one and nobody has taken it. This is the only thing on the panel that needs doing, and only these offer Collect it.
In flight	This run released freight and the other has not collected it yet.

Waiting for this run also lists freight a driver released towards this run’s unit without naming a run — the usual case when a driver drops a trailer at a truck stop for whoever comes next. It is offered only while uncollected, and only to runs whose service date is within a day of the release. A run is never offered its own release.

A run cannot collect what it released — that is the other run’s action. Collecting twice is refused, and so is a collect timed before its release.

It appears on both runs’ stops

Recording a changeover writes a release stop on the run handing over and a collect stop on the run taking it, both at the location you gave. They appear in Route stops and on the timeline like any other stop, so the run’s own schedule shows the thing that interrupts it.

Both stops are written with the handover or neither is. A handover with only one half would be a record of freight going somewhere nobody took it.

A handover on a single run does not get stops. A breakdown or a shift end is one run swapping unit — the freight never moves between runs, so there is no partner stop to write.

Drop-and-hook is different. Parking a trailer for someone to collect later uses trailer release and trailer collect, which you add through Add stop. Their two halves can be days apart and on runs nothing links, so nothing can guess the other end for you.

One connote across several runs

A connote handed along a chain gets a leg badge on its card from the second run onwards — leg 2, leg 3, and so on. Ordinary freight carries no badge, so the badge means something when you see one.

Validation policies on the board

When a dispatch policy is published and set to enforce (Settings → Validation Policies), the drivers and vehicles in the Build Unit pickers are judged against it:

• Blocked candidates are hidden, behind a Show N not eligible link that always says how many. Revealed, they are greyed with every reason, and a locked block cannot be picked at all.
• Warnings stay visible with a badge. Going ahead opens a dialog listing every warning, each with its own reason box; it will not submit until each reason is long enough. Cancel, ✕ or Escape leaves the board exactly as it was.
• Unknown — for example a licence class nobody recorded — is badged unknown and stays selectable. Unknown is not a failure.

In off or shadow mode the board hides and badges nothing and looks exactly as it did before policies existed. The server re-checks every assignment either way.

Staying current

The board polls for changes every ten seconds and applies them card by card, so it does not flicker or lose your selection. The badge in the header shows the state of that feed. When the tab is in the background polling pauses and resumes when you come back, so a board left open overnight does not hammer the server.

What the board deliberately does not show

Speed, fuel, traffic-adjusted ETA, driver hours remaining and on-time percentage are absent, not blank. No routing service is called anywhere in the application and driver hours are not recorded, so any figure in those places would be invented. They will appear when there is something real behind them.