A dispatch board is the single surface where carrier operations either flow or fracture. Get it right and your dispatchers can manage 30 loads at once with full confidence. Get it wrong and every shift starts with a scramble to figure out where things actually stand.
Most carriers start with a spreadsheet — shared in Google Drive, color-coded by dispatcher, revised constantly. That approach works at five trucks. It breaks somewhere between fifteen and thirty, and the failure isn't gradual. It tends to happen on a bad-weather Friday when half the fleet is delayed and one dispatcher is out sick.
A real dispatch board isn't just a prettier spreadsheet. It's a structured system with defined layers — each one handling a specific part of the load lifecycle. This guide explains those layers, the architectural decisions behind each one, and what an implementation actually looks like in practice.
Why most dispatch boards break under growth
The failure mode is almost always the same: the board was designed for a static snapshot, not a live operation. Spreadsheet-based dispatch treats the load list as a record of what has been planned. But dispatch is about what is happening right now — status changes, driver check-ins, equipment swaps, delay escalations, and reallocation decisions that happen faster than anyone can update a cell.
The symptoms of a failing dispatch board compound:
- Dispatchers call drivers to get status instead of seeing it on screen
- Assignment conflicts — two drivers sent to the same load — get discovered at pickup, not in the office
- Exceptions (breakdown, detention, missed appointment) are handled by text message and not recorded anywhere
- The safety team has no visibility into which drivers are currently on duty
- The planning board and the live board are the same document — so yesterday's intentions overwrite today's reality
None of these are dispatcher errors. They're structural failures in the tool. A dispatcher using a broken board isn't underperforming — they're compensating for missing systems by adding personal overhead (calls, texts, memory).
The scaling cliff
Spreadsheet dispatch fails predictably. Most carriers hit their breaking point between 15 and 35 active trucks — when the number of daily state changes exceeds what one dispatcher can track manually. The board that worked fine at 10 trucks creates crisis at 25.
The five structural layers
A dispatch board that scales has five distinct layers. Each one handles a defined scope of information. None of them do each other's job.
The five layers of a scalable dispatch board
- 1Load pipeline — Every load at every stage: pending, assigned, in transit, at pickup, at delivery, complete, exception. The pipeline never collapses all loads into a single list.
- 2Driver visibility — Real-time HOS status, current assignment, location (via telematics or manual check-in), and availability window. Dispatchers should never have to call a driver to find out where they are.
- 3Equipment tracking — Tractor and trailer readiness status, current location, and next scheduled maintenance window. Equipment conflicts (a trailer already assigned to a different load) surface in the board, not at the yard.
- 4Exception handling — A defined path for delays, breakdowns, appointment misses, and load cancellations. Exceptions trigger an escalation flow, not an ad-hoc text thread. Every exception is recorded with timestamp and resolution.
- 5Planning surface — A forward-looking view of the next 24–72 hours: which loads need drivers, which drivers are available, which equipment has capacity. The planning board is separate from the live board and feeds it.
The most common structural mistake is collapsing layers 1 and 5 — using the live board for planning and the planning board for status. This creates constant merge conflicts where dispatchers overwrite live status with planned assignments, and planned assignments get corrupted by live updates.
The second most common mistake is omitting layer 4. Without a structured exception path, exceptions are handled informally and never captured. That means your safety and compliance teams can't audit what happened, and your dispatchers spend time re-solving the same types of problems instead of building a resolution playbook.
Assignment rules that skip the phone call
Every load assignment involves at least three decisions: which driver, which tractor, and which trailer. In a spreadsheet-based operation, those decisions live in the dispatcher's head — filtered by HOS, equipment availability, customer preferences, driver qualifications, and proximity. That's a significant cognitive load per assignment, and it grows non-linearly as the fleet grows.
A structured dispatch board offloads that cognitive load by surfacing only valid assignment options. When a dispatcher opens a load to assign, they should see:
- Drivers who have sufficient HOS to complete the load
- Drivers whose current location makes them a realistic candidate (not sending a driver from Phoenix to cover a load starting in Dallas in six hours)
- Tractors that are mechanically available and not already assigned
- Trailers that match the load type and are not committed to another load
The board filters — it doesn't just list. A driver who is 11 hours into their HOS cycle shouldn't appear as a valid option for a 9-hour load. A tractor with a scheduled PM tomorrow shouldn't be assigned to a multi-day run. These constraints should be enforced by the system, not remembered by the dispatcher.
Assignment rules also encode business logic: preferred carriers for certain lanes, driver-customer relationship preferences, equipment restrictions by customer or load type. Rules that previously lived in institutional memory get written once and applied consistently.
Planning board vs. live board
These two surfaces need to be kept structurally separate. The live board reflects reality as it is right now. The planning board reflects intentions for the next 24–72 hours. They inform each other — planned assignments become live assignments, live exceptions inform the planning buffer — but they shouldn't be the same view.
In a properly structured system:
- The planning board shows unassigned future loads alongside available drivers and equipment. Dispatchers drag-assign, apply rules, and build out the next shift without touching live loads.
- The live board shows current-state loads with real-time status: in transit, at pickup, awaiting POD, exception. Changes here are driven by driver updates, telematics, and dispatcher edits — not by forward planning activity.
The boundary matters operationally. A dispatcher who touches the live board to update yesterday's plan corrupts today's reality. A dispatcher who plans on the live board has no buffer for the surprises that come during execution.
In RigBase, these surfaces are maintained as separate views with different interaction models: planning board is drag-assign with future availability windows, live board is status-driven with exception escalation paths. They share the same underlying data model but expose different lenses onto it.
Exception handling and escalation
Exceptions are the true test of a dispatch board. Any board can handle clean loads. The question is what happens when a driver breaks down at mile marker 212, or a shipper pushes the appointment by four hours, or a customer rejects a load at delivery.
An exception handling system needs three things:
- A defined input path. The dispatcher, driver, or system triggers an exception and categorizes it. The board captures what happened, when, and who's responsible for resolution — not a text message that disappears.
- An escalation path. Some exceptions resolve at the dispatcher level (appointment reschedule). Others require safety involvement (breakdown with potential cargo claim). Others require fleet management (equipment failure). The board routes based on type.
- A resolution record. Every exception closes with a resolution: what was done, what the outcome was, and whether it triggered downstream action (maintenance work order, safety incident report, customer claim). This record is searchable and auditable.
The escalation path is where most informal dispatch systems fail. Without it, breakdown resolution happens via group text, the safety manager finds out about the incident on Monday, and the maintenance team doesn't know about the component failure that caused the breakdown.
Implementation checklist
Dispatch board implementation checklist
- Define load stages explicitly — every load should have a clear current stage at all times (pending, assigned, in-transit, at-pickup, at-delivery, complete, exception)
- Separate the planning board from the live board — they should be different views, not the same spreadsheet tab
- Build driver visibility into the board directly — HOS status, location, and availability should be on-screen, not a phone call away
- Encode assignment constraints as rules — HOS availability, equipment type, customer restrictions, and driver qualifications should filter valid options
- Define your exception types and escalation paths before you need them — breakdown, detention, missed appointment, cargo claim, customer reject
- Ensure every exception is recorded with timestamp and resolution — not just handled informally
- Connect the dispatch board to fleet records — assigned equipment should show maintenance status and prevent assignment of vehicles with upcoming PM holds
- Give the safety team read access to the live board — they should know driver status without asking dispatch
- Review assignment rules quarterly — lanes change, customer requirements change, and the rules need to reflect current operations
- Measure exception rate by type and dispatcher — this is the operational signal that tells you where the process is fragile
“The best dispatch board is the one your dispatchers actually trust. If they're keeping a shadow spreadsheet "just to be sure," the board has already failed.”
See the RigBase dispatch board in action
Walk through the live board, planning board, assignment rules, and exception handling with your operation in mind — not a scripted demo.
Carrier intelligence
Get guides like this in your inbox.
New operational guides, compliance frameworks, and platform updates — straight to you. No spam. Unsubscribe anytime.