Loads and dispatch

A Dispatcher starts with a freight load whose number and subject tell the team what is moving. The record holds its organization, Load Owner, Transport Partner, promised delivery time and freight amount. The promised time is the baseline for delivery review. Actual pickup and actual delivery are recorded as separate moments; a change in transit does not rewrite the original commitment.

For a load moving through several stops, the Dispatcher should open the ordered stops before committing the route. Each stop has its own sequence and delivery window. The Dispatcher approves the route against the current load revision and stop order. If a stop changes afterwards, the owner requests a correction and the Dispatcher checks the changed scope before planning it again.

• Plan. Draft loads carry the owner, partner and promise while the Dispatcher checks stops, equipment needs and assignment availability.
• Move. The Dispatcher records physical pickup before marking a load Dispatched, then follows it in transit. Operations Overview shows active loads and pending decisions together.
• Close. The recipient proof on the stop and actual delivery time on the load support the Delivered state. An exception remains visible until its reason and next action are resolved.

The Load Owner can review the same load without changing the route. Operations Reviewer can record an independent decision tied to the specific revision. This matters when a correction arrives while a vehicle is already committed: the team needs to distinguish draft scope from work that was accepted or executed.

Decide who creates loads, who owns them and who can mark physical pickup. Define how Transport Partners are selected within each Organization, and when an independent revision review is needed. Agree whether a load can move back into planning after a route decision and how a changed promise is communicated outside the app. Keep the original promised delivery time available for later comparison.

The team should also decide how it records exceptions. A load in Exception has an operational issue, but that status alone gives no remedy. The owner should attach relevant evidence, identify the affected stop or carrier event, and ask for a review decision when the load revision changes. Finance can use a separate settlement process after delivery evidence is complete.

Take a load with two scheduled destinations and a named Transport Partner. The Dispatcher records the promise, sequences the stops and reserves an eligible driver and ready vehicle for the planned interval. The Dispatcher checks the current revision and approves the feasible route before marking the load Planned, records actual pickup, then moves it through Dispatched and in transit.

At the destination, compare the stop’s actual arrival with its window. Record the recipient’s proof reference before marking the load Delivered and entering the actual delivery time. Open the delivery timing report: it should compare the load’s actual delivery time with the promise stored on the load. If the event needs correction, use the revision and receipt history to keep the original work visible.

• Active loads — Current planned, dispatched, in-transit and exception work with owner, partner and promised time.
• My loads — The Load Owner’s records and delivery commitments.
• Load status board — Loads grouped by their actual lifecycle status.

See planning and route review, pickup and transit and delivery evidence.