Dispatch automation blueprint: McLeod and Samsara

Dispatch automation is done in stages, and the order matters more than the software. Write the rules down, take the baseline, connect the TMS and the telematics, run copilot mode where the dispatcher approves every line, measure the overrides, then let routine loads run alone, one class at a time. This blueprint is those stages with the checks between them.

What is dispatch automation, and what is it not?

It is a system that drafts the board from the rules your best dispatcher applies and the live position and hours of every truck, and re-drafts it when something changes. It is not a system that dispatches. The dispatcher keeps the decision until, class of load by class of load, the drafts have matched their judgment for long enough that reading them is a formality.

The reason for the staging is that a dispatch board carries knowledge nobody wrote down: which shipper's dock is slow, which driver will not take a reefer, which window is really a window and which is a wish. A system that skips the writing-down stage learns those things by getting them wrong on live loads. A system that is fed the page first gets most of them right from the first draft, and the rest come out of the override reasons.

One opinion: the most valuable stage is the first one, and it is the one most likely to have been skipped. A page of dispatch rules that a new hire could follow is worth having even if no system ever reads it.

How do I write the rules down?

Sit with the best dispatcher for a week of boards, morning and afternoon, and write what they do, not what they say they do. Every assignment they make, ask why that driver, why that order, why not the other one. The answers are the rules, and they come in four kinds. Constraints, which cannot be broken: certifications, equipment, hours of service, hazmat, union rules. Preferences, which are broken when they have to be: which drivers a customer likes, which lanes a driver knows, who finishes near home on Friday. Priorities, which decide between two valid boards: the customer who is never late, the load that pays the most, the truck that must be back for service. And exceptions, with the name of the person who decides each.

Write all four on one page, line 1 of the worksheet, in the dispatcher's own words. Then have the second-best dispatcher read it and mark everything they would do differently. The disagreements are the most useful part; the operations manager settles them and the page records the settled rule.

The data you need for each rule tells you what the systems must provide. A rule about hours needs live hours from the telematics. A rule about a customer's dock needs a field in the TMS that may not exist yet. Write those needs next to the rules; they become the checklist for the connection stage.

What is the baseline, and why does it come before the software?

Four numbers, for a month, with dates, on line 2. How long the board takes to build each day, from the time the dispatcher sits down to the time the last driver has their first load. How many loads the board covers. How many times the board is rebuilt after a callout or a shipper change, and how long each rebuild takes. And the empty miles, from the TMS, which is the number that turns into dollars.

The baseline is taken before anything is connected, because a number taken after go-live is not a baseline, and because it is the page every promise is measured against. A vendor who proposes dispatch automation without asking for these four numbers is proposing a system with no way to be judged. Where we have a written commitment on a dispatch deployment, its metric, baseline and target read Agreed in the build plan, written against exactly this page.

What data does the blueprint need, and where does it come from?

Two systems. The TMS holds the loads, the drivers, the tractors and trailers, the customers and their windows; McLeod is one. The telematics holds where every truck is right now and how many hours each driver has left; Samsara is one. The blueprint reads from both and, in copilot mode, writes to neither; the approved board goes wherever drivers already receive their work, which is usually the TMS.

Connect both on credentials the operator issues for the integration, never on a person's login, read-only first. Then check a day of data before building anything on it: the loads the system reads match the board, the positions match the map at the same minute, the hours match what the driver's device shows. The fields the system found and the fields it did not are written on line 3; a rule that needs a field that does not exist is a rule that waits until the field does.

Which objects carry each of those, and how often each is read, is specific to the operator's setup and is Details to follow. The pattern does not change: loads and constraints from the TMS, live position and hours from the telematics, events from either when something changes.

What does copilot mode look like day to day?

The afternoon before, the system drafts tomorrow's board from the rules on the page and the live data. The dispatcher opens the draft, and for each line, approves it as drafted, edits it, or rejects it and assigns by hand. Every edit and rejection records a reason, in a sentence, and the reason is the whole point of the stage. The dispatcher does not spend less time yet; they spend the same time reading a draft instead of building from nothing, and they get faster as the drafts get better.

When a driver calls out, the system re-drafts the remaining board from live positions and hours and shows the dispatcher what changed. The callout is the case to test first, because it is the one the dispatcher most wants help with and the one where a wrong draft is most visible.

Copilot mode lasts until the drafts match the dispatcher's judgment on the loads that matter, and the record on line 4 says when that is. It is measured per class of load, because a system that drafts the local routine loads perfectly may still get the long-haul exceptions wrong for months.

How do I measure approvals and overrides?

Each week, from line 4: lines drafted, approved as drafted, edited, rejected. Then read every reason. Overrides sort into two kinds. A reason that names a rule the page did not have, "that shipper only receives before noon," is a missing rule; add it to the page, line 5, and the next draft has it. A reason that is a judgment call, "I had a feeling about that lane today," stays with the dispatcher, and that class of load stays in copilot mode.

Monthly, take the four baseline numbers again, the same way. On the deployments we have measured, board build time is the first to move, and empty miles move slowest and matter most. If a number is not moving after two months of copilot mode, the rules page is missing something the dispatcher knows and has not said, and the way to find it is another week of sitting with them.

When do routine loads move to autopilot?

When the approval rate on a class of loads has held high for long enough that the dispatcher no longer reads those lines, and the dispatcher agrees. The threshold and the period are the operator's to set and are written on line 6 with the date each class moved; where we have set one on a named deployment, the figure reads Pricing on request. Then that class runs without approval, the dispatcher watches exceptions only, and every other class stays in copilot mode.

Widen one class at a time. Keep measuring the same four numbers. A class that starts producing overrides again goes back to copilot mode without ceremony; that is not a failure, it is the measurement working.

Where does this go wrong?

The rules are written by the operations manager instead of the dispatcher, and describe how the manager thinks the board is built. The baseline is skipped because everyone already knows it is bad. The telematics is connected but the hours feed is not, so the system drafts loads for drivers who cannot legally take them and the dispatcher stops trusting every draft. Copilot mode is cut short because the drafts look good on the easy days. Autopilot starts on every class at once because the approval rate was good on average.

And the one that ends projects: the dispatcher was told about the system by the vendor, not by the owner, and reads it as their replacement. Tell them first, tell them what it does and what it does not, and put their name on the line as the person who approves every draft. Bring line 1 and line 2 to a working session and we will say which class of load to start with and what the written commitment would name.