Tank Truck Dispatch Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does trailer state get scoped as fields on a record?

Because that is how every transportation system you have ever used models a trailer, and it is how your current one models it now. A trailer has a number, a type, a capacity and a location, plus a notes field where somebody types the last product if they remember. A developer looking at that will naturally propose the same shape with more fields: last product, wash date, wash type. It demonstrates well and it fails identically.

The defect is that fields are set by people, and people set them from memory, under pressure, at the moment they are trying to cover a load that fell apart overnight. A field that can be set can be set wrongly, and nothing in the design distinguishes a trailer that was washed from a trailer somebody said was washed.

The fix is event driven state, specified before pricing. A load completes and the trailer inherits the product it carried. A wash is performed and a wash event is created at the rack with the trailer number, the standard applied, the operator and the certificate image, and only that event changes the trailer to clean. There is no user action that sets the state directly. Ask any prospective developer how a trailer becomes clean in their model. If the answer contains the word checkbox or flag, they will ship the failure you are paying to eliminate, and you will find out through a claim rather than through testing.

What goes wrong when you load your existing trailer, product and wash data?

There is far less of it than the project plan assumes. Wash certificates are paper in a folder at the rack or images in a text thread, so historical trailer state cannot be reconstructed and the system starts with every trailer in an unknown condition. That is survivable if it is planned for and disruptive if it is discovered in the week of go live, because dispatchers will find every trailer blocked on day one.

The product master is the second problem and the larger one. The same commodity appears under a customer name, a shortened name a dispatcher typed, and a specification code, and your compatibility rules have to be written against a single canonical product. Consolidating those names is judgement work that needs your operations people, not a matching script, and it has to finish before the rule set can be encoded.

The fix is to sequence product master consolidation as its own phase ahead of the rule engine, with a named owner from operations and a deadline that is not the launch date. Plan an explicit trailer state initialisation exercise: a scheduled wash and inspection cycle that brings each unit into a known, evidenced state as it comes through, with a documented interim rule for how dispatch operates while the fleet is still being brought in. Start with your food grade fleet, since that is where the exposure is highest and the population is smallest.

Why do the transportation system and in cab integrations break after launch?

The transportation system integration breaks because both systems believe they own the trailer. If McLeod or Trimble TMW is still handling order to cash and dispatch billing, and your new layer owns trailer state and assignment, then any change made in one has to reach the other without either overwriting the other's truth. Teams that skip that design get a trailer marked available in one system and blocked in the other, and dispatchers learn to trust whichever screen agrees with them.

The in cab side breaks on connectivity. Drivers load inside steel buildings and at rural terminals with no coverage, so seal capture, photographs and delivery confirmations have to be created offline and reconciled later. Naive implementations discover during the first month that the same trailer receives events from two sources with different timestamps, and the reconciliation silently corrupts the state everything else depends on.

The fix on both sides is to name one owner per fact and enforce it. Your layer owns trailer state, compatibility and assignment permission. The transportation system owns the order, the settlement and the invoice. Nothing writes across that line except through a defined interface with reconciliation reporting that surfaces disagreement rather than resolving it quietly. On the in cab side, require the developer to explain conflict resolution when two sources report events for the same trailer, and test it deliberately by taking a device offline for a full shift before you accept the work.

What happens when the compatibility rule set is not written down?

The project stalls, and it stalls at exactly the moment everyone thought the hard part was over. Which products can follow which, and after what cleaning, is not a public table. It is an accumulation of what your customers demand, what your product data sheets say and what you have learned from your own incidents, and in most carriers it exists as one laminated sheet and one dispatcher with twenty years of service.

Developers cannot write that for you and should not try. What we see when it is skipped is a rule engine delivered empty, a fleet that either blocks everything or nothing, and a dispatch team that reverts to the phone within a fortnight. The build is then judged a failure when the missing input was never software.

The fix is to treat rule elicitation as the real deliverable and give it two to three weeks of structured sessions with your senior dispatchers, quality lead and largest customers' requirements in front of you. Encode the outcome as explicit product to product rules with a required cleaning standard as the result, evaluated at the moment of assignment. Then allow overrides, because a system that forbids them entirely gets bypassed on paper within a month, but require a reason and an attributable name and report on them monthly. The override list is the most accurate picture you will ever get of where your written policy and your actual operation disagree.

Should you build custom or configure what you already own?

If you run under roughly 25 trailers in a single commodity with a stable customer base and one dispatcher who knows every unit, keep McLeod or Prophesy and run a disciplined paper wash log. A build at that size formalises something that already works, and the money is better spent on equipment. This is a genuine recommendation, not a hedge.

Keep your transportation system regardless of size. McLeod LoadMaster, Trimble TMW Suite and Prophesy are capable at order to cash, settlement, fuel tax, imaging and the dispatch board itself, and replacing them puts your cash collection at risk for a safety benefit you can obtain far more cheaply alongside. What none of them does is model a trailer as a vessel with a history, because that concept does not exist in the market they sell to, and no amount of configuration will create it.

Build the safety layer when two or more of these are true: you run more than about 60 trailers, past the point where one person can hold trailer state in their head, you haul food grade and non food in the same fleet, you have had a contamination claim or a near miss you know was luck, you cannot state your own compatibility policy in writing today, or customers have started asking for prior load documentation before they will unload.

How do hidden costs get into the quote?

Through five doors. Commodity group count is the first. Food grade, chemical and petroleum each bring their own rule structure and their own customer requirements, and a quote written after looking at one of them has priced roughly a third of the rule work.

Owning wash racks is the second. If you operate your own, cleaning becomes a schedulable resource with capacity, duration by standard and a costing model, which is a subsystem rather than a feature, and it is also where the largest savings sit because nobody has ever measured wash avoidance.

In cab connectivity is the third, and offline creation with conflict safe reconciliation is weeks of work that quotes routinely treat as a mobile screen. Integration depth with your transportation system is the fourth, and the difference between reading trailer and order data and writing assignment decisions back is substantial.

The fifth is the rule elicitation time described above. It is not overhead, it is the input the whole system runs on, and a supplier who has not priced facilitated sessions with your dispatchers has assumed you will hand them a document that does not exist.

What separates a build that works from one that fails here?

Ask how a trailer becomes clean. The correct answer is that only a completed wash event with a certificate changes state and no user can set it directly. Anything else and the project cannot deliver its purpose.

Ask how they handle an override at 5am. The right design permits it with a required reason and a named person, then reports on overrides so you can see where policy and reality diverge. A system that blocks absolutely gets worked around on paper, and a system with no record of overrides is a system with no evidence.

Ask about offline behaviour in the cab, specifically what happens when the same trailer receives events from two sources with conflicting timestamps. A developer who has not built for that will discover it in week eleven and the discovery will cost you trailer state integrity.

Ask what a claim packet looks like as an output. Prior product, the wash event with rack, standard, operator and certificate image, the seal applied at loading with number and photograph, the seal verified at delivery, and any retained sample, exported in one action. Carriers commonly tell us the first successful claim defence covers a meaningful share of the build cost. Then settle ownership before kickoff: your repository, your infrastructure accounts, your unrestricted right to hire anyone else. At Digital Heroes the client owns the code from the first commit.