Chassis Pool Management Software: Who Had the Unit, and Who Pays for the Damage?

Why a chassis pool breaks every system it touches

It is 6:40 on a Tuesday morning at a marine terminal. A driver pulls a chassis off the stack, the gate camera reads a number one character off because the plate is caked in road grime, and the terminal books the interchange out to the wrong motor carrier. That unit spends eleven days on the street, gets dropped at a depot thirty miles away with a cracked light bar and a bald tire, and appears on a per diem invoice six weeks later against a carrier that never touched it. The carrier disputes. The pool has a gate record. The depot has a scan. The driver had a photo on a phone he no longer owns. Somebody absorbs the charge, and it is always whoever keeps the worst records.

That is the entire business problem in one paragraph. A chassis pool is not an asset tracking exercise, it is a chain of custody exercise with money attached to every handoff. The unit is interchanged between a terminal, a motor carrier, a shipper's yard, a depot and back, sometimes four times a week. Each handoff creates a liability transfer for per diem, for damage and for roadability. The record of that handoff is generated by a party who has no incentive to make it precise, in a format built for their own operation.

What most operators run today is Blume Global for the pool side plus terminal gate systems, depot spreadsheets, emailed equipment interchange receipts as PDF scans, and a billing analyst whose full time job is comparing invoices to a list. Blume is real infrastructure and it is genuinely good at network visibility across the intermodal ecosystem. What it is not is your pool agreement. It does not know that your interchange with one drayage carrier gives three free days measured in business days while another gives two measured in calendar days, that a terminal closure suspends the clock at one port and not another, or that your repair chargeback matrix splits tires by tread depth. Those are the things the disputes are actually about.

Problem one: the interchange event has three versions and no owner

Every interchange produces multiple records. The terminal operating system logs a gate transaction. The depot logs a receipt with its own condition notes. The driver's app, if there is one, may or may not have captured photos. A paper equipment interchange receipt may exist in a scan folder. None of these agree on time, and half of them do not agree on which unit.

The consequence is that reconciliation is retroactive. The billing analyst rebuilds a unit's history at dispute time, six weeks late, from sources that contradict each other, and the outcome depends on who argues harder. Over a fleet of several thousand units this is not a rounding error. It is a permanent leak that nobody can size, because sizing it would require the record you do not have.

What a custom build does: make the interchange event the primary object, not the chassis. Every event has a unit, a timestamp, a location, a counterparty, a direction, a source system and a confidence level. Conflicting events from different sources are not overwritten, they are stored side by side and resolved by a rule you set, with the resolution logged. Gate activity arrives through the EDI 322 terminal and ramp activity messages where the terminal supports it, through file drops where it does not, and through the driver app for yard moves nobody else sees. When two sources disagree, the system flags a unit as contested before the invoice arrives rather than after. That single change moves you from arguing about history to presenting it.

Problem two: per diem is a contract calculation, not a rate

Per diem looks like a daily rate multiplied by days. It never is. Free time varies by agreement and is sometimes business days, sometimes calendar. The clock stops for terminal closures, for port congestion declarations, for weather events, for a unit already flagged out of service. Some pools have flip charges, some have street turn credits, some have different rates after a threshold. Motor carriers hold their own version of these rules and bill against them.

General leasing and fleet systems, and even purpose built pool visibility tools, model per diem as a rate table. They cannot express the conditional logic, so the logic lives in an analyst's spreadsheet, which means it is not audited, not versioned and not defensible when a carrier's own analyst shows up with a different answer.

What a custom build does: express each agreement as executable rules with an effective date and a version history, then compute per diem from the event ledger rather than from a monthly snapshot. Every charge line carries its own explanation: which events bounded the period, which free time rule applied, which suspension days were subtracted and why. When a carrier disputes, you send the derivation, not a spreadsheet. In our experience this is the feature that ends most disputes without a phone call, because the other side can see immediately whether they have a case.

Problem three: damage liability turns on a timestamp you cannot produce

Damage is found at gate in. The pool bills the last recorded custodian. The last recorded custodian says the damage predated them, and often they are right, because the previous inspection was a visual glance from a gate clerk with forty trucks in the lane. Without a condition record at each handoff, liability defaults to whoever is easiest to bill.

What a custom build does: attach a condition record to the interchange event itself, captured where the handoff happens. That means a driver app that works with no signal in a terminal lane, forces a fixed set of photo angles, timestamps and geotags them, and syncs when the phone finds a tower. It means depot inspection on a tablet against your own damage code list, not free text. It means the repair estimate references the specific photos and the specific event, so a chargeback carries its own evidence. Build the photo store as append only. The moment anyone can replace an image, every image becomes arguable.

Problem four: roadability status and availability are different facts

Federal intermodal equipment provider rules put the maintenance and inspection obligation on the equipment provider, while the driver still performs a pre trip and can refuse a unit. Operationally this means a chassis has 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 most systems show it as inventory.

The result is a dispatcher who sends a driver for a unit that cannot leave the gate, a driver refusal, a wasted turn and a detention claim. The fix is not more visibility. It is modelling status properly: inspection due dates, out of service flags raised by driver refusals, open repair orders and holds, all resolving into a single availability answer that dispatch and the pool portal both read.

Problem five: you cannot balance a pool you cannot count

Repositioning is expensive and slow, so it is planned from feel: someone in operations knows that a particular depot runs short on Thursdays. That is fine at one port complex. Across several, with street dwell varying by carrier and season, it costs real money in emergency moves and missed pulls.

What a custom build does: derive true position from the event ledger rather than from reported inventory, split by roadable and non roadable, then forecast shortfall by location and day using your own booking and gate history. This is worth building only after the event ledger is clean. A balancing model on top of contested data produces confident nonsense.

What this costs and how long it takes

Across the projects Digital Heroes has delivered in intermodal and asset heavy logistics, the shape is consistent. A focused first release, meaning the interchange event ledger with multi source ingestion, per diem calculation against your real agreements, and the damage evidence trail with a driver capture app, runs $80,000 to $160,000 and ships in 12 to 18 weeks. That is a system your billing analyst works from on day one.

A full platform adding depot and repair order workflow, roadability and inspection status, pool balancing, carrier self service for disputes, and billing integration runs $200,000 to $450,000 phased over 7 to 12 months.

What pushes cost up here specifically: the number of terminals and depots you must ingest from, because each one is its own integration and some will only give you a nightly file. The number of distinct interchange agreements, since each becomes a rules module. Telematics, if you are fitting GPS units and want position and mileage in the same ledger. And the offline requirements of the driver app, which are not optional at a marine terminal and are the part inexperienced teams underestimate by a factor of two.

What keeps cost down: 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.

Build versus buy, and when buying is right

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

Build when two or more of these are true. You are the equipment provider or pool operator and therefore carry the roadability obligation. You have more than one interchange agreement with materially different per diem terms. Your damage chargebacks are written off at a rate you do not like to quote out loud. Your event data comes from more than three source systems that disagree. Or you are a drayage carrier large enough that per diem is a line item your CFO asks about, in which case you are building the mirror image of the same system to defend yourself.

How to choose a developer for chassis and interchange systems

Ask them to model an interchange event on a whiteboard before you sign anything. A developer who has done this will separate the event from the asset, will ask what happens when two sources disagree, and will ask whether you need to reconstruct position as of a past date. A developer who draws a chassis table with a current location column has built an asset register and is about to learn intermodal on your budget.

Ask specifically how per diem rules will be versioned. If the answer is a rate table, walk. Agreements change mid year and you will need to recompute a prior period exactly as it stood then.

Ask what they have integrated. EDI 322 gate activity, terminal file drops, depot systems and telematics are four different problems. Ask for the named counterparty and the named message type, not a claim about integrations in general.

Ask who owns the code, and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit, and we would tell you to walk away from any firm that hedges on that.