Running Freight Taught Us About Building a Transport Management System

Almost every operation is described in the process document, and then there is the way it actually works. Most transport management and freight software is developed based on the first.

There is a point in every enterprise software requirements exercise where the team describing the operation of their business does so accurately but omits the critical parts of the process.

Nobody’s intentionally been being dishonest. What people describe is how they intend to do something, and those are the processes and the workarounds that have evolved in order to deal with the normal difficulties of running a business, and they’re embarrassingly obvious. Or so fully ingrained that they don’t even see them anymore. Or someone realizes that everybody else knows this too.

In most software domains the difference between the described process and actual workarounds for the process is mostly a nuisance to develop around. In freight/transportation management this is critical to get right, as there are many daily ‘load-bearing’ workarounds that are required on top of the ‘official’ processes to get freight moved.

We have an unusual perspective to this. Before building a TMS for sale that can be used by other transportation management organizations, we spent a decade running a national network of logistics services. So all the “workarounds” to processes that we described in our software requirements discovery sessions for the TMS were our workarounds to run our own network of transportation management services. We weren’t told about them in our software requirements discovery sessions, yet operators were paying for them.

The following everyday workarounds for processes within freight transport and logistics particularly affected the TMS development at ElasticRun and pose specific requirements to the architecture of a freight TMS:

The 7 a.m. phone tree: why freight visibility has to push, not store

There are many transport desks around operating in exactly the same way. On one of the long lanes that we ran, the transport desk at the origin warehouse would be called every morning to confirm whether the vehicle had departed and, if so, when it would arrive. The answer would then be relayed to the parties waiting at the destination end.

This was not a process that needed to be documented, as it was simply the way the morning started.

The cost of such actions survives only because it is not visible in the budget. It does not decrease any key performance indicators. It even creates lots of very valuable information. Across all lanes and people involved, it adds up to hours a week of highly skilled people’s time. The entire output of their efforts is a status update, which is already outdated by the time it is relayed to someone else.

Tracking on a dashboard does not solve this problem. The problem is that people do not have time to go look for this information and thus call and ask instead. The only thing that can solve this problem is real-time information that automatically and proactively updates all the relevant stakeholders. To build this, however, the TMS must have information about who the various stakeholders are for each shipment and why they care. This means that stakeholder context would need to be attached to each trip in the TMS.

The dispatch question nobody has time to answer: capacity and route planning

Every dispatch involves five decisions: how many vehicles, what type, which route each takes, what loading sequence, and whether holding some volume until tomorrow costs less than sending a part-loaded vehicle today.

Watch a planner at 4 p.m., and you will see four answered and the fifth skipped. Not ignored, rather skipped, because answering it means weighing today’s known cost against tomorrow’s projected consolidation, and the cutoff is in forty minutes.

So the default is always the same: send it. Every part-loaded vehicle leaving a yard is that question going unasked, and the loss surfaces nowhere, because nothing went wrong. The load was delivered on time at the agreed rate.

Requirements-gathering cannot find this. Ask a planner to describe their process, and they describe the four questions they answer; the fifth is not part of the process precisely because there is never time for it.

It became the clearest argument for a capacity and route planning engine that answers all five at every planning cutoff rather than helping a human answer them faster and that replans the entire dispatch when something changes at 16:20, instead of patching the plan that already exists. In a conventional TMS the planner is the optimizer and the software is the workbench. That is the wrong way round at 4 p.m.

The shadow spreadsheet: freight tracking across a fragmented carrier base

Every visibility program we have seen has a shadow. Coverage looks strong, and then somebody quietly maintains a separate sheet for the subcontracted carriers who never got onto the system.

The reason is structural. Large carriers have telematics. The operator running three trucks does not and will not buy a platform because a customer asked. So those loads get tracked by phone and recorded by hand, while the official dashboard shows excellent coverage of the freight everyone was already confident about.

From the operating side the implication was uncomfortable: the shadow spreadsheet held our highest-risk freight. The partners with the least instrumentation had the least formal process and the least margin to absorb a problem.

That pushed the design toward layered tracking rather than a single integration from telematics where it exists, then network-derived location, then toll and checkpoint data, so that every load resolves to some signal and coverage degrades gracefully instead of failing silently. And toward participation light enough that a two-truck operator will actually use it: browser-based apps for drivers and carriers, nothing to install, nothing to maintain.

The rate that lived in an email: contract-aligned freight invoicing

Ask a finance team how freight invoices get approved, and you will hear a clean description involving contracts and matching. Sit with them at month-end, and you will watch somebody search their inbox for what was agreed on a Friday afternoon when capacity was short.

The rate was real. It was just never anywhere a system could see it.

This is the most common source of billing disputes in freight, and it is rarely fraud. It is drift: a rate agreed in one system, executed in another, and billed from a third, with a person retyping figures at each boundary. Every retyping is a chance for the number to change, every changed number becomes a query, and queries take weeks.

Better invoice-matching software does not fix it, because the problem is upstream. It disappears only when procurement and invoicing share a data layer, so the rate agreed during contract or spot bidding is the rate that appears on the invoice with nobody touching it. That is an architectural property of the freight transport management system, not a module you bolt on afterwards.

The planner’s private list: why AI planning needs a human in the loop

Every experienced planner keeps one, sometimes on paper. The site whose gate staff leave early on the first Friday of the month. The customer who insists on a particular vehicle type for reasons lost to history. The road has been closed since Tuesday.

This is among the most valuable operational data in the business, and it exists in no system. When that planner leaves, it leaves with them.

The instinct is to treat it as data entry. That fails with nobody maintaining a constraints database, and the knowledge arrives as corrections rather than entries.

What works is capturing it at the moment of use. When a planner overrides an AI-generated plan, the correction is the data: the closed road, the real cutoff, and the customer requirement. Freeze that one decision, let the rest of the network continue replanning automatically, and store the correction so it applies next time instead of being reapplied every week. The private list becomes system knowledge without anyone being asked to write it down, and the planner keeps authority over the decisions that need judgement.

The check at the gate: automated compliance before dispatch

Document verification appears in every process document as a step. In practice it is a person at a gate reading paperwork under time pressure while a driver waits.

It fails often enough to be one of the largest avoidable costs in freight: a detention, a penalty, and a delay cascading into everything downstream. And it is entirely deterministic; no judgement is involved. It is a checklist being run by a human because nobody built the thing that runs it automatically before the vehicle moves.

Of everything here, it was the least interesting to build and among the fastest to pay back.

What the workarounds added up to

Even if we broke out all of the above into six features, they would all still map back to one architectural requirement: the TMS we built is four modules on top of a single data layer (procurement, planning, execution, and invoicing).

Procurement contains direct allocation of load as well as contract and spot bidding of carriers with AI-based scoring of bids by commercial terms and service history. Planning answers all 5 of the dispatch questions at every cutoff time and replans on change. Execution contains automated pre-dispatch compliance checking as well as layered tracking and computer-vision-based proof of delivery. Invoicing creates contract-aligned invoices with a full audit trail. A control tower ranks exceptions by predicted consequence and recommends action for the user. All users (drivers, dockers, carriers, consignees, security at gates, etc.) have simple web apps to interact with the system.

Each of these features was first worked around.

Read Next

A few related pieces worth your time:

• The Best Golang Courses for Building Career-Level Back-End Skills
• Building Resilient Scalable Real-Time Performance in Embedded Software
• One Side of the Invoice Is Automated – Pay Oper Automates the Other

The pattern worth taking away

Looking at the six items in the above figure together, they all sit at handoffs. Between the function that runs procurement and the function that runs finance. Between the function that makes plans and the function that carries out those plans. Between your operation and a partner’s.

Not coincidentally, these handoffs are also non-optimizable points of disintegrated process, where documentation is inherently motivationalless and thus gets gotten by the person closest to the point, in the form of a phone call, a shared spreadsheet, or an ad hoc list. Thus, buying TMS in a module-by-module fashion yields tools sitting in the midst of functional stages, with all seams intact.

Don’t confuse a workshop with a method to find out your own processes before you go out to evaluate TMS again. Ask the following questions: What would you hide from the vendors? What did the newest member of your team find confusing in the first week? Which of your spreadsheets would cause the most problems if it were to get deleted tonight?

These are the answers you are looking for, and they will probably not be in your process description, but they will be the most accurate description of how you are doing things at the moment and thus a good specification for the system you need to buy.