What Actually Belongs on a Dispatch Board
A board that shows everything shows nothing. The useful question isn't what data you have, it's what a dispatcher needs to see without clicking.
Most dispatch boards are built by adding columns. Someone asks for reference numbers, someone wants commodity, someone wants the customer's PO. Two years later there are twenty-six columns, everybody scrolls sideways, and the dispatcher has a second board in a spreadsheet with the eight things they actually use.
That spreadsheet is the real requirement. It's worth looking at before designing anything.
What a dispatcher does all day
Three things, and the board should serve them in this order:
- Find the loads that need attention right now. Not all loads. The ones off plan.
- Cover what isn't covered. Match trucks or carriers to loads.
- Answer questions. Where is it, when will it deliver, what happened.
A board optimized for the third one — a complete searchable record — is the one that gets built, because it's the easiest to specify. It's also the least valuable, because the third task is the least frequent and the most automatable.
Exception first
The single highest-value design decision: the default view is not all loads. It's loads that need something.
- Late for pickup or delivery against the appointment
- No driver update within the expected window
- Uncovered, with pickup approaching
- Sitting at a shipper past the free time
- Delivered without documents
- Anything a driver flagged
Everything else is fine and doesn't need a dispatcher's eyes today. A board that shows all 140 active loads with the eleven problems mixed in requires a human to do the filtering, every time, all day. That's the actual job you're paying to automate.
The "all loads" view should exist. It shouldn't be the front door.
The columns that earn their space
For the exception view, roughly:
- Load reference — short, tappable
- Status, as a stage with color
- Lane, origin to destination, abbreviated
- Next appointment, with time remaining, colored as it approaches
- Driver or carrier, with an obvious way to message them
- Last update, as elapsed time, not a timestamp — "3h ago" is a judgment, "11:42" is arithmetic
- The exception itself, in words
Eight columns. Everything else lives on the load detail, one click away.
That "last update as elapsed time" detail sounds small and isn't. A board full of timestamps makes a dispatcher compute staleness thirty times a minute. A board showing "3h ago" in amber has done that work for them.
The board is not the record
Worth separating in your head.
The board is an operational tool. Optimized for scanning, exception-finding, and acting. Sparse on purpose.
The load record is the complete history. Every document, message, cost, timestamp, status change. Optimized for depth.
Reporting is the aggregate view. Margin, on-time, volume.
Boards get ruined when they're asked to be all three. If you find yourself adding a column so someone can run a number off the board, the answer is a report, not a column.
Actions where the eyes are
The other half of a good board is that seeing a problem and acting on it happen in the same place.
- Message the driver, from the row
- Reassign, from the row
- Log a status update, from the row
- Attach a note, from the row
- Escalate or flag for a manager, from the row
A dispatcher who has to open the load, then a separate messaging tool, then come back, is doing four steps per exception. Across a day that's most of an hour, and it's the reason boards get abandoned for spreadsheets and phone calls.
Different desks, different boards
Not everyone needs the same view.
Dispatch wants exceptions and today's coverage.
Sales or account management wants their customers' loads and anything at risk of a service failure they'll be asked about.
Accounting wants delivered-without-documents and anything ready to invoice.
Ownership wants none of this — they want margin by lane and customer, weekly.
Same underlying records, four saved views. Trying to make one board serve all four is how you get twenty-six columns.
Test it honestly
Sit behind a dispatcher for two hours. Count:
- How often they scroll sideways
- How often they open a load just to see one field
- How often they leave the board for another tool mid-task
- How often they check something the board could have flagged
- Whether they have a spreadsheet open
That last one is the finding. If they do, what's in it is your requirements document, and it was free.
The honest caveat
A better board doesn't add capacity on its own. It removes friction, and freed-up dispatcher time only becomes value if it goes somewhere — more loads, better carrier relationships, actually handling the exceptions properly instead of triaging.
If you rebuild the board and change nothing else, you'll have calmer dispatchers and the same throughput. That's not nothing. It's just not the return anyone put in the business case.
We build dispatch boards, exception handling and driver messaging for US carriers and freight brokerages. See how it fits together, or tell us what's in the spreadsheet.