Drayage Software Problems: The 7 That Cost You Demurrage, Per Diem and Turns

Why does the model get built around loads instead of containers?

Because everyone in freight software already has a load model, and reusing it looks like a saving. The developer has built a transport management system before, the requirements read like dispatch requirements, and the container looks like an attribute of the move rather than the thing the whole business revolves around. So the build starts with a load table and containers become a field on it.

The failure shows up about two months after go live. Someone asks how many days remain before last free day on every box currently on the ground, and there is no answer, because last free day belongs to a container and the system only knows about legs. Dispatchers respond exactly as they did in the old tool: they create several loads for one box and keep the relationship in their heads.

The fix is a structural decision made before anything is quoted. Container number, size, type, steamship line, bill of lading, vessel, discharge date, last free day, per diem free days, chassis assignment with start and stop timestamps and appointment reference sit on the container. Every leg hangs off it as a child. Only then do the clocks become computable, and only then can you build the single highest value screen in the category: every container ranked by dollars at risk over the next three days. Ask any prospective developer to draw the model before they quote. This one question filters most of the market.

What goes wrong migrating container history and rate tables?

The export is the easy part. Customers, rate tables and open loads come out of Vector, Envase or Compcare without much drama. The problem is that the data you most need is not in fields. Last free day, chassis numbers, seal numbers and per diem terms live in notes fields, typed by different dispatchers in different formats over several years, and a straight import carries them across as unparsed text.

That matters more here than in most industries because your open per diem disputes depend on history. If you cut over on a Monday with eighteen months of chassis activity stranded in free text, you have a new system that cannot defend an invoice arriving from a pool next week for a chassis returned three weeks ago.

Two things fix it. Run a parsing pass over notes fields before cutover, extracting container numbers, dates and chassis references into structured columns, and validate every container number against the ISO 6346 check digit so garbage is caught rather than migrated. Then plan a parallel run where both systems are live and the new one is scored against the old on a sample of moves. Two to three weeks inside the project timeline is realistic for migration and parallel operation together, and a proposal that shows migration as a single line at the end of the plan has not thought about the notes fields.

Why do terminal, chassis and steamship integrations break after launch?

Because none of them are your systems and none of them owe you stability. Terminal portals change session handling, add rate limits, alter page structure and adjust the times slots release. Chassis pool data is the least standardised in the business. Steamship line data ranges from a clean interface to screen scraping, and the scraped ones break without notice.

The predictable mistake is building these integrations as if they were reliable and letting the rest of the system depend on them synchronously. When a terminal portal changes, the appointment automation stops, and because it stopped silently at 4am nobody notices until a driver arrives without a slot.

Build them as fallible sources instead. Every integration writes to a staging record with a fetched timestamp and a health state, the operational screens read the last known good value and show its age, and a failure raises an alert to a named person rather than an entry in a log. Design the appointment automation so a human can take over booking for one terminal without the rest of the system caring. And ask any developer specifically which terminal portals and which chassis pools they have worked with, and what broke. Anyone who has actually done eModal or a terminal interchange receipt portal has stories about sessions and rate limits. Anyone who has not will tell you it is straightforward.

What happens when chassis events and per diem evidence are not covered?

This is where drayage operators bleed quietly. A driver flips a chassis at a yard, nobody records it, and 45 days later an invoice arrives from TRAC or DCLI for days on a chassis you gave back three weeks earlier. Without an event log you cannot dispute it, so you pay. Nobody ever adds up the annual total, which is precisely why it continues.

A chassis field in a transport management system does not solve this. A field records a value, not a history, and the dispute requires a history: out of pool at a timestamp, mounted to a specific container, flipped at a specific yard, returned at a timestamp.

Cover it by making chassis a first class entity with an event log, and capture the events where they happen, which is on the driver's phone. Each event carries geolocation, a photograph and a driver identity. Then reconciliation becomes a report: the pool's charged days against your event log, container by container, with disputes going out with photographic and location evidence attached. Two design points matter. The driver app must work offline with a local queue, because drivers lose signal inside terminals every day and an event that fails to record is worse than no app. And set a retention policy for those photographs and location records at the start, because they are the evidence that wins disputes and they are also personal data about your drivers.

Should you build custom or configure what you already own?

Configure if you run under about 25 trucks out of one terminal with one chassis pool. Envase, Vector and Compcare cover dispatch and invoicing at a small fraction of build cost, and at that size your volume does not generate enough clock management pain to justify custom code. If your plan is to stay exactly this size, the answer stays the same and you should ignore anyone telling you otherwise.

The genuine limit of those products is what they choose to model. They model a load and they model an invoice, both competently. They do not model a chassis event log, a per diem exposure figure per container, or automated appointment booking against your own priority rules, because those require the container to be the root entity. That is an architectural choice made years ago in their products, not a feature gap you can configure around.

Build when the signals appear together: past roughly 40 trucks or 150 containers a week, two or more terminals, someone whose job is substantially copying data between systems, and no ability to produce a per diem dispute with evidence. One signal decides it on its own. If you have already bought a second tool to compensate for the first, a separate appointment bot, a separate yard sheet, a separate billing spreadsheet, you are already paying for a custom system. It is just unintegrated and held together by people.

How do hidden costs get into the quote?

Terminal count is the biggest and the most commonly flattened. Every terminal portal is its own integration with its own behaviour, and a quote that prices "terminal integration" as one line is pricing whichever one the developer looked at. Ask for it per terminal, with the first one priced after a short discovery spike rather than before.

The driver app is the second. A bilingual app with offline capability, photo capture and a sync that resolves conflicts is a real piece of engineering, and it is usually described in a proposal as a single bullet. It is also the capture point for the chassis evidence that pays for the project, so it should not be cut.

Third is document extraction for delivery orders. Extraction itself is well understood, but the surrounding work is not free: a watched inbox, per field confidence scoring, a review queue for low confidence fields, and per sender learning so a forwarder's repeated layout stops reaching the queue. Fourth is multi entity billing if you run separate operating authorities per port, which changes invoicing, reporting and access control together. And if you move bonded or in bond freight, scope the customs filing touchpoints explicitly rather than discovering them after launch.

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

The builds that work start narrow and prove a number. One terminal, one chassis pool, the container model with clocks, and the dollars at risk screen. That screen either finds boxes your dispatchers were missing in the first fortnight or it does not, and if it does, the rest of the programme funds itself in an easy internal conversation rather than a capital request.

They also treat the driver app as infrastructure rather than a nice addition, because without field capture the chassis reconciliation has no data and the strongest financial argument disappears. And they design every external integration to fail visibly, with a last refreshed timestamp on screen, so a dispatcher knows whether she is looking at live terminal availability or a value from yesterday afternoon.

The failures share one pattern: a twelve month programme with nothing live until the end, usually because the plan tried to cover every terminal and every customer at once. By month eight the terminals have changed their portals, the requirements have drifted and the operation has built new workarounds. Ship something that computes a clock in the first quarter, then expand. Finally, settle ownership before kickoff. The repository in your organisation, the infrastructure in your cloud account, and container and chassis history exportable from day one. A developer proposing to host your operational data on their platform with no exit path is selling lock in, not a custom build.