Will AI replace my dispatcher? No, here is what it does

No. A dispatcher copilot drafts the next-day board, runs the check-calls through an SMS agent, and re-plans when a driver calls out. The dispatcher approves or overrides every line and keeps the exceptions and the shippers; every override trains the model. At a regional logistics agency, route planning fell from 2 to 3 hours to under 1 hour per dispatcher.

What does the copilot take off the dispatcher's desk?

Three pieces of the day, the ones that are arithmetic.

The board draft. The copilot is wired into McLeod and Samsara. It suggests driver-to-load assignments from location, hours available, equipment type and shipper preferences, and generates the next-day board as a draft in McLeod for the dispatcher to review and approve. At the logistics agency in our case study, that board used to be built by hand on a whiteboard and transferred to McLeod each morning: 2 to 3 hours per dispatcher per day, and until 8 or 9 p.m. in peak season. After the copilot went live, planning took under 1 hour per dispatcher.

The check-calls. This one is not the copilot alone. The SMS agent that usually follows it in months 2 to 3 pulls real-time location from Samsara, checks it against the pickup and delivery windows, and sends the update to the shipper before anyone asks. Each dispatcher had been making 60 to 80 calls a day to drivers and shippers for status updates; after check-call automation went live it was 10 to 15 a day, exceptions only.

The re-plan. When a driver calls out or a delivery window shifts, the copilot re-optimizes the remaining routes within minutes and shows the dispatcher what changed. The scripted demo on the logistics agent page is that morning: a driver calls out sick at 5:40 a.m., the copilot pulls the stops from McLeod, checks hours and position in Samsara, proposes the reassignment, and drafts the shipper reply for the dispatcher to send. The names and numbers in the demo are made up.

What does the dispatcher keep?

The decision, the exceptions, and the customers.

The approval. The copilot goes live in copilot mode, which the case study calls suggestion mode: the AI recommends, and the dispatcher approves or overrides every assignment. At the logistics agency that was weeks 5 to 6. In the blueprint we publish, each line of the draft is approved as drafted, edited, or rejected and assigned by hand, and every edit records a reason.

The exceptions. The service page says it in one line: the dispatchers handle the exceptions and the customer relationships, and the AI handles the math. The exceptions the SMS agent finds (late, off-route, breakdown) escalate to the dispatchers. The complicated shipper emails go to the right person; the email agent handles the routine rate requests, load tenders, POD requests and status inquiries on its own.

The judgment on a customer. "Shipper Y only wants Driver Z" is not arithmetic, and the first version of our copilot did not know it. The dispatcher says it once as an override reason, and the system carries it on every later draft.

Why does every override matter?

Because the override is the training: on the logistics agent page, the AI proposes assignments, dispatchers approve or override, and every override trains the model. The blueprint sorts overrides into two kinds. An override with a reason ("that shipper only receives before noon") is a rule the page was missing; it gets added, and the next draft has it. An override with no reason ("I had a feeling about that lane today") is a judgment call; it stays with the dispatcher, and that class of load stays in copilot mode.

The threshold is on the service page: once the approval rate exceeds 90%, routine assignments run on their own and dispatchers handle exceptions only. Routine assignments, not the board. The blueprint moves one class of load at a time, keeps every other class in copilot mode, and sends a class back to copilot mode the moment it starts producing overrides again.

So the dispatcher who approves every line for the first weeks is not a placeholder; they are the reason the system gets ready. A copilot with no overrides to learn from drafts the same wrong board every day.

How long does the dispatcher approve every line?

At the logistics agency the copilot MVP ran in suggestion mode only in weeks 5 to 6, after four weeks of diagnosis, a McLeod data audit and driver interviews. Check-call SMS automation followed in weeks 7 to 10, and in weeks 11 to 16 the email agent went live and the copilot moved to semi-autonomous mode. The implementation spanned 6 months. The service page's general shape is 2 to 3 weeks of discovery and go-live in copilot mode inside 6 to 8 weeks from kickoff.

Copilot mode lasts, in the blueprint's words, until the drafts match what the dispatcher would have done on the loads that matter and the dispatcher says so; the approval rate per load class decides, not a calendar. And every deployment ships with a kill switch, per how we work: if something breaks, you turn it off.

What do I tell my dispatchers?

Tell them first, and tell them what the system does not do. In the blueprint's list of where dispatch automation goes wrong, the one that ends projects is the dispatcher told about the system by the vendor, not the owner, who reads it as their replacement. Put their name on the line as the person who approves every draft.

I tell owners the same thing on every call: if the plan is to run the copilot for 6 months and then let a dispatcher go, do not hire us, because the copilot you would end up with is the one nobody trained. The overrides in weeks 5 to 6 are the product. At the logistics agency the first version of the copilot ignored "Driver X doesn't do NYC" because nobody had written it down, and it cost an extra two weeks in month 2 to build a preference engine from what the dispatchers knew. What the copilot replaces is the whiteboard, the 8 p.m. finish, and the operation that visibly degraded when one dispatcher took vacation. It does not replace the person who approves the board.

What we saw in deployment

At a regional logistics agency (LTL and FTL, 40+ shippers, two senior dispatchers and a whiteboard) the copilot on McLeod and Samsara took the dispatchers' day from an 8 to 9 p.m. finish to 5 to 5:30 p.m., and the SMS agent took check-calls from 60 to 80 a day to 10 to 15 exception-only calls, both dated 2026-03-18 on the case study, whose own closing note says the measurement dates are still to be confirmed. Route planning, NPS and the rest are on the case study.

What went wrong is the case study's own note: the first version of the copilot optimized purely on efficiency metrics and ignored the driver and shipper preferences that lived in the dispatchers' heads, and the preference engine cost an extra two weeks in month 2. The dispatch automation blueprint is that lesson as its first step: sit with the best dispatcher for a week of boards and write every rule down before anything is connected.

Set out in the agreement