McLeod dispatch automation: a copilot's day, hour by hour

A dispatcher copilot on McLeod and Samsara drafts tomorrow's board the afternoon before and re-drafts it when a driver calls out; an SMS agent beside it runs the day's check-calls. It starts in suggestion mode, where the dispatcher approves every line. At a regional logistics agency, route planning per dispatcher fell from 2 to 3 hours to under 1.

What does the copilot do the afternoon before?

Tomorrow's board is drafted today. The copilot reads the loads, the drivers, the equipment and the shipper windows from McLeod, and where every truck is and how many hours each driver has left from Samsara. From those it suggests driver-to-load assignments, weighing location, hours available, equipment type and shipper preferences, and drafts the next-day board in McLeod for dispatcher review and approval. The dispatcher's rule set, captured in the diagnosis weeks, is wired into McLeod first, so the draft starts from how the board is built today.

The dispatcher opens the draft and, line by line, approves it as drafted, edits it, or rejects it and assigns by hand. Every edit and rejection records a reason in a sentence. In the first weeks the dispatcher does not spend less time; they spend the same time reading a draft instead of building from nothing, and they get faster as the drafts get better.

At the logistics agency, the board used to be built by hand on a physical whiteboard and transferred to McLeod each morning, 2 to 3 hours per dispatcher per day, and in peak season the two dispatchers regularly worked until 8 or 9 p.m. to finish it. After the copilot went live, they finished by 5 to 5:30 p.m. The dispatcher copilot service page carries the 6 to 8 week plan that gets a fleet to that first draft.

What happens when a driver calls out?

The callout is the case suggestion mode is tested on first, because it is the one the dispatcher most wants help with and the one where a wrong draft is most visible. When a driver calls out at six in the morning, the copilot re-drafts the remaining board from live positions and hours in Samsara and shows the dispatcher what changed, within minutes rather than the hours a manual rebuild takes. In suggestion mode the dispatcher checks the re-draft instead of starting from a blank board, and the drivers get the changes. The same path handles a shipper who moves a delivery window to the afternoon, weather and traffic.

The scripted demo on the logistics agent page is a morning like that. You pick what happens, the 5:40 a.m. callout or the moved window, and watch the copilot pull the stops from McLeod, check hours and position in Samsara, propose the reassignment, and draft the shipper reply for the dispatcher to send. It runs with no sign-in and no API key; nothing is sent to a model, and the names and numbers are made up.

Does the copilot make the check-calls?

Check-calls are the SMS agent's job, not the copilot's, and at the logistics agency it went live in weeks 7 to 10, after the copilot. It pulls real-time location from Samsara, checks it against pickup and delivery windows, and sends proactive updates to shippers. Exceptions, late, off-route or breakdown, escalate to the dispatchers. Before it, each dispatcher made 60 to 80 calls a day to drivers and shippers for status updates; after it, 10 to 15 exception-only calls.

An email agent, live in weeks 11 to 16, handles the inbound shipper email in the same hours: rate requests, load tenders, POD requests and status inquiries. Routine requests are handled on their own; complicated ones go to the right person. The dispatcher's day, then, is the exceptions the SMS agent raises, the emails the email agent could not close, and the board.

Why does suggestion mode come first?

I tell owners that suggestion mode comes first because the board carries knowledge nobody wrote down, and the only place it comes out is in the dispatcher's overrides. At the logistics agency, the first version of the copilot optimized purely on efficiency metrics and ignored the driver and shipper preferences the two dispatchers had carried in their heads for 10+ years. The fix was a preference engine, an extra two weeks in month 2. A copilot that runs on its own from day one learns those rules by getting them wrong on live loads, with a shipper on the other end of each one. There is a second reason, and it is the one that ends projects: a dispatcher who was told about the system by a vendor reads it as their replacement, and a dispatcher who has approved every draft through the suggestion-mode weeks knows exactly what it does and does not do. Every override trains the model. Every override also trains the dispatcher's trust, and I have not found a shortcut for either.

When does the copilot move to semi-autonomous mode?

When the approval rate says so, not the calendar. Each week, count the lines approved as drafted, the lines edited and the lines rejected, and read the reasons. An override with a reason, "that shipper only receives before noon," is a rule that was missing; add it and the next draft has it. An override with no reason is a judgment call; it stays with the dispatcher, and that class of load stays in suggestion mode. The service page's threshold: once the approval rate exceeds 90%, routine assignments run on their own and dispatchers handle exceptions only. Move one class of load at a time and keep measuring the same numbers; a class that starts producing overrides again goes back to suggestion mode without ceremony.

At the logistics agency, the copilot went live in suggestion mode in weeks 5 to 6, after four weeks of diagnosis, a McLeod data audit and driver interviews, and moved to semi-autonomous mode in weeks 11 to 16. From month 5 it was expanded to include rate quoting assistance. The stages, the four baseline numbers to take before anything is connected, and the worksheet are in the dispatch automation blueprint. The service is wired into McLeod, Samsara, Project44, FourKites, Motive and Trimble; the deployment below ran on McLeod and Samsara.

What we saw in deployment

A regional logistics agency (LTL and FTL freight for 40+ shippers across the Eastern US, $15M to $25M in annual revenue, a fleet of 80+ owner-operators and company drivers, dispatched from a single operations center) ran all dispatch through two senior dispatchers who had been with the company 10+ years and a whiteboard. When one took vacation, the operation visibly degraded: late pickups, missed appointments, shipper complaints. We built the dispatcher copilot on McLeod and Samsara, then the SMS check-call agent, then the email agent, in a custom implementation spanning 6 months that moved to ongoing support at a flat monthly rate.

The case study dates every metric 2026-03-18 and states the method for four of the five in one sentence each; its own closing note says the measurement dates are still to be confirmed. Route planning time dropped from 2 to 3 hours to under 1 hour per dispatcher, a 50% reduction, after the copilot went live. Check-calls dropped from 60 to 80 manual calls a day to 10 to 15 exception-only calls, after check-call automation went live. Shipper satisfaction, measured by NPS, increased from 32 to 51 in the first quarter after deployment. Dispatchers went from working until 8 to 9 p.m. to finishing by 5 to 5:30 p.m., after the copilot went live. The copilot manages 200+ daily routes; the case study marks the date and method behind that figure as still to be confirmed. Read the case study.

What went wrong: the first version of the copilot optimized purely on efficiency metrics and ignored soft factors like "Driver X doesn't do NYC" or "Shipper Y only wants Driver Z," so a preference engine cost an extra two weeks in month 2. In logistics engagements since, we capture driver and shipper preferences as structured data during the diagnosis phase, the four weeks before the first draft board exists.

Set out in the agreement