Chassis Pool Management Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the scope creep from per diem billing into a full asset register?

You start with the thing that hurts, which is billing. Six weeks later the requirements document has a maintenance module, a parts inventory, a tyre tracking screen and a map. None of that settles a dispute.

The drift happens for a reason that sounds sensible in the room. Somebody points out that if the system knows about the chassis, it may as well hold the specifications, the purchase date, the depreciation and the service history. That is true, and it is also how a twelve week project becomes a nine month one, because an asset register wants a current state per unit while a billing and liability system wants an immutable history of events. Those are different data models, and the asset register usually wins the argument because it is easier to picture.

The fix is to make the interchange event, not the chassis, the primary object, and to say so in the statement of work. Every event carries a unit, a timestamp, a location, a counterparty, a direction, a source system and a confidence level. Position, availability and per diem are all derived from that ledger rather than stored as fields somebody updates. Once the ledger exists you can add a maintenance module cheaply. Build the maintenance module first and you will bolt the ledger on afterwards, which in this category means rebuilding.

Push the map to phase two as well. Everyone asks for it, nobody wins a dispute with it.

What goes wrong when you migrate years of interchange receipts and gate records?

The history you want to bring across is scattered across terminal gate exports, depot spreadsheets, a scan folder of equipment interchange receipts, and an email archive. Each source has its own idea of what a unit identifier looks like, and they disagree constantly.

Three specific problems show up every time. Unit numbers were transcribed by people reading grimy plates, so a meaningful share are wrong by one character, and the wrong ones cluster on the units that moved most. Timestamps are recorded in local time with no zone, so a movement that crossed midnight looks like it happened in the wrong order. And the same physical handoff appears twice with different times, once from the terminal and once from the depot, so a naive load creates two events and a phantom gap between them.

The fix is to accept that migrated history is evidence, not truth. Load every source as its own event stream with the source recorded, rather than merging into one clean table. Resolve conflicts with a stated rule and log the resolution so anyone can see which source won and why. Normalise every timestamp to a single zone at ingestion. Then run one acceptance test: pick twenty units with known disputes and confirm the system reconstructs each unit's custody chain in a way your billing analyst agrees with. If it cannot, you have found the gaps early, which is the entire point of doing it before go live.

Why do terminal, depot and telematics feeds break after launch?

Because none of those feeds is yours, and each one is maintained by an organisation with no obligation to tell you when it changes.

The failure modes are dull and expensive. A terminal that sends EDI 322 gate activity adds a segment and your parser rejects the file silently. A depot that emails a nightly spreadsheet changes a column header when someone rebuilds the report, and the load succeeds while writing every condition note into the wrong field. A telematics provider rotates credentials and nobody notices for eleven days because the last position for every unit still looks plausible. In each case the system keeps producing invoices, which is worse than stopping, because now the errors are in front of a customer.

The fix is three pieces of unglamorous engineering that inexperienced teams skip. First, per source freshness monitoring: if a feed that normally delivers every hour has been quiet for four, someone is told, and the alert names the terminal rather than saying a job failed. Second, schema validation at ingestion with the file quarantined and a human notified rather than partially loaded. Third, a pre invoice reconciliation that lists every unit with a gate out and no gate in, every unit with overlapping custody at two counterparties, and every event whose sources disagree by more than a set tolerance. That report is where the money is, and it has to run before billing rather than after a dispute.

What happens when roadability and inspection status are not covered?

You dispatch drivers to units that cannot legally leave the gate, and you pay for the wasted turn twice.

Federal intermodal equipment provider rules put the systematic maintenance and inspection obligation on the equipment provider, while the driver still performs a pre trip inspection and can refuse a unit. Operationally that gives a chassis at least three states that people constantly conflate: physically present at a location, legally roadable, and available to dispatch. A unit with an expired annual inspection sitting in a stack is present and unavailable, but a plain inventory system shows it as stock, so dispatch sends a driver, the driver refuses it, and you absorb the empty move plus whatever detention claim follows at the load.

The slower version of this failure is worse. If out of service flags raised by driver refusals never reach a queue with an owner, a unit bounces between refusals for weeks. Every refusal costs a turn, and none of them causes a repair, because nobody owns the flag.

The fix is to compute availability rather than store it. Inspection due dates, open repair orders, damage holds and driver refusal flags all feed one derived answer that dispatch, the depot and the pool portal read from the same place. Refusals open a repair order automatically with a named owner and an ageing clock, so a unit cannot sit refused and invisible. This is not sophisticated engineering. It is a set of date range checks that nobody has because the inspection records and the inventory have never lived in one system.

Should you build custom or configure what you already own?

If you run a few hundred units in a single pool under one interchange agreement, and your disputes are occasional rather than structural, do not build. Blume Global plus your pool operator's portal plus a competent billing analyst is proportionate at that size, and a custom platform would be a hobby you fund forever.

Blume Global is real infrastructure and it is genuinely strong at network level visibility across the intermodal ecosystem. Configure it properly before you conclude it has failed you. Most operators use a fraction of what they already pay for, and the honest first step is to check whether your disputes are about where a unit was, which the portal can answer, or about what your agreement says, which it cannot.

Build when the disputes are contractual. Concretely: you hold more than one interchange agreement with materially different free time and suspension terms. You are the equipment provider or pool operator and therefore carry the roadability obligation. Your damage chargebacks are written off at a rate you would rather not quote aloud. Your event data arrives from more than three systems that disagree. Or you are a drayage carrier large enough that per diem is a line item your finance director asks about by name, in which case you are building the mirror image of the same system to defend yourself.

How do hidden costs get into a chassis software quote?

They arrive through counterparties, not through code. The quote prices what your team will build. The schedule is set by organisations that do not work for you.

• Every terminal and depot is a separate integration. Some send EDI 322, some send a nightly file, some send nothing and want you to scrape a portal. A quote for the pool is not a quote for eleven terminals.
• Data access takes longer than the build. Getting a terminal to agree a feed involves their operations team and their vendor. Start those conversations before kickoff, not at integration week.
• Offline capture in the driver app. Marine terminal lanes routinely have no signal, so photos, condition confirmations and signatures must queue locally and survive the app being killed. Teams without field experience underestimate this by roughly a factor of two.
• Each interchange agreement is a rules module. Business days against calendar days, suspension conditions, flip charges and street turn credits are all logic, and every agreement needs versioning with effective dates so a prior period recomputes exactly as it stood then.
• Photo storage grows fast. Fixed angle capture at every handoff across thousands of units produces a large, permanent, append only store with a retention policy you must decide early.

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

Four things, and none of them appears in a feature list.

The first is the data model. Ask a developer to whiteboard an interchange event before you sign anything. Someone who has done this separates the event from the asset, asks what happens when two sources disagree, and asks whether you need to reconstruct a unit's position as of a past date. Someone who draws a chassis table with a current location column has built an asset register and is about to learn intermodal on your budget.

The second is per diem versioning. If the answer to how agreements are stored is a rate table, walk. Terms change mid year and you will need to recompute a closed period exactly as it stood at the time, with the derivation visible on every charge line.

The third is scope discipline at the counterparty boundary. Start with one port complex, one pool and your top five counterparties by dispute volume. That covers most of the money and all of the arguments, and it gets a working system in front of your billing analyst inside a quarter instead of a year.

The fourth is ownership. You should hold the repository, the cloud accounts and the unrestricted right to hire another firm, agreed in writing before kickoff. At Digital Heroes the client owns the code from the first commit. The value here accumulates in years of event history and rule versions, and that history has to be portable or it is not really yours.