Treadstone Associates
Article · 11 min read

What dispatchers need from a TMS

Five features carry a dispatch desk. The rest is bought during procurement by people who will never open it.

Treadstone Associates · Updated 2026

Key takeaways

  • • Remaining hours on the board is the most-used compliance datum in dispatch, because it decides what may lawfully be planned.
  • • Appointment windows must be enforced constraints, not comment-box notes — most dispatch failures are appointment failures.
  • • Duty-status records: forwarded within 20 days, deposited within 30, kept chronologically per driver for at least six months.
  • • A compliant system supports annotations and driver-confirmed edits, never silent overwrites of a record of duty status.

The short answer

Dispatchers use five things every day: the board, remaining driver hours, appointment and window times, driver messaging, and the exception queue. They ignore almost everything else — dashboards, scorecards, analytics, optimisation they cannot override, and any screen that takes more clicks than the phone call it was meant to replace.

That is not laziness. A dispatcher’s day is a sequence of interruptions with a hard constraint attached, and any feature that does not resolve an interruption faster than the alternative loses to the alternative. Buy for the five, and treat the rest as reporting for someone else.

The five, and why each earns its place

1. The board

One screen showing every truck, its current load, its next commitment and its status. The design question that decides adoption is how many actions can be taken directly from it — assign, reassign, message, add a stop, mark an exception. If the dispatcher has to open a load record to reassign a driver, the board is a report and they will keep the spreadsheet.

2. Remaining hours, visible without asking

This is the single most-used compliance datum in dispatch, because it decides what may lawfully be planned. The federal Commercial Vehicle Drivers Hours of Service Regulations set two cycles — cycle 1, over which on-duty time is accumulated across 7 days, and cycle 2, across 14 days — and a “day” is a 24-hour period beginning at the hour designated by the motor carrier for the duration of the driver’s cycle. A dispatcher planning tomorrow needs the driver’s position in the cycle, not just today’s remaining drive time.

The regulations also apply only to vehicles above a threshold — a truck, tractor, trailer or combination with registered gross vehicle weight in excess of 4,500 kg — so a mixed fleet has drivers on two different regimes. A board that shows hours for some units and blanks for others is correct, and dispatchers need to know why rather than assume a data fault.

3. Appointment and window times, treated as constraints

Most dispatch failures are appointment failures, not routing failures. The window has to be a field the system enforces — warning when a plan cannot make it — rather than a note in a comment box. This is also where the local-operation rule matters, because the 160 km radius exemption requires the driver to return to the home terminal each day to begin a minimum of 8 consecutive hours of off-duty time. A late appointment that pushes a local driver past that is not just a service failure; it changes the day’s record-keeping regime.

4. Driver messaging in the load context

Messages attached to the load, not a parallel chat app. The value is retrieval three weeks later when a customer disputes a detention charge, and a thread sitting in a personal phone is not a business record.

5. The exception queue

Structured outcomes for everything that is not normal: late, refused, breakdown, no dock, missing paperwork, hours short. A dispatcher with an exception queue works a list; a dispatcher without one works whichever problem shouted loudest. This is the highest-leverage feature in the category and the one most often buried behind a dashboard.

What gets ignored, and why

  • Executive dashboards. Useful to an owner, invisible to dispatch. Nobody resolves an interruption with a monthly trend.
  • Driver scorecards inside the dispatch view. Dispatch is a scheduling job; performance management is a different conversation on a different day, and mixing them damages the relationship dispatch depends on.
  • Optimisation with no override. A dispatcher knows that a receiver will hold a truck for two hours. If the plan cannot be overridden with a reason recorded, it will be overridden outside the system.
  • Analytics modules bought during procurement. Nearly always evaluated by someone who will never use them, on the strength of a demo dataset.
  • Duplicate customer portals that require the dispatcher to update status twice.

The paperwork the dispatcher creates without noticing

Dispatch decisions generate records with retention obligations, and this is where a TMS quietly earns its licence fee. A driver must forward the record of duty status and supporting documents to the home terminal within 20 days of completing it, and the carrier must deposit them at its principal place of business within 30 days of receiving them and keep them in chronological order for each driver for at least 6 months. Where the local-operation alternative applies, the carrier must instead keep records showing the cycle followed and on-duty times, with supporting documents, for at least 6 months.

The carrier also has a live monitoring duty: it must monitor the compliance of each driver, take immediate remedial action where there has been non-compliance, and record the dates of the non-compliance and the action taken. That is a dispatch-adjacent workflow, not a quarterly audit — and the system either captures it as it happens or it gets reconstructed badly later.

The edit trap

Dispatchers frequently want to “fix” a driver log that looks wrong. The regulations prohibit anyone from entering inaccurate information in a record of duty status or falsifying, mutilating, obscuring, altering, deleting, destroying or defacing the records or supporting documents, and from tampering with an ELD so that it does not accurately record and retain required data. A compliant system supports annotations and driver-confirmed edits; it does not support silent overwrites. Check which one you are buying.

A worked example: an afternoon in a 22-truck dispatch office

Two hours, four interruptions. A receiver in Mississauga cancels a 14:00 dock slot. A driver in Cornwall reports a trailer light out. A customer calls asking where a load is. A second driver messages that he will run out of hours 40 minutes short of the drop.

With the five features: the cancelled slot appears as an exception with a suggested reslot; the trailer fault is logged against the unit and routed to maintenance, where it joins the inspection and repair history; the customer question is answered from the board without calling the driver; and the hours-short driver is visible before the call, because the board already showed his cycle position.

Without them, all four become phone calls, and the record of what was decided lives in the dispatcher’s memory. That memory is what the carrier relies on when a detention claim is argued six weeks later.

Where AI helps a dispatcher, honestly

The realistic wins are in the exception queue and the inbox. Reading a rate confirmation into a load record. Watching for a plan that will breach a window and surfacing it before the driver notices. Drafting the check-call update to a customer. Summarising a load’s history when a claim arrives. All of these are “prepare the decision”, and all are checkable in seconds.

What AI must not do is decide whether a driver may take a load. Hours-of-service compliance carries regulatory consequences and the duty to monitor and remediate sits on the carrier. The system can say “this plan needs 9.5 hours and the driver has 8.25”. A dispatcher decides what happens next, and the record shows who decided.

Common questions

What is the single feature dispatchers ask for first?

Remaining hours on the board without opening another system. It is the datum that determines whether a plan is legal, and it is the one most often a click away in products that were designed around loads rather than drivers.

Should dispatch and safety share a system?

They should share data and separate views. Safety needs the monitoring and remedial-action record; dispatch needs to not be looking at scorecards while assigning a load.

Do local drivers need to appear differently on the board?

Yes, if they operate under the 160 km radius exemption — different record-keeping, and a hard constraint on how far the day can stretch. Flag them.

How much dispatcher training does a new TMS need?

Budget for the board and the exception workflow, and skip the modules nobody will open. The fastest way to lose a TMS rollout is a two-day training course on features that do not resolve interruptions.

Stop losing hours to paperwork you already have the data for.

A 30-minute call is enough to tell you whether AI pays for itself in your back office.