Drayage Software: Stop Demurrage and Per Diem From Eating Your Margin

Why drayage software makes or breaks a container trucking operation

Drayage runs on clocks, not miles, and the software either tracks those clocks or your margin quietly walks out the gate. Last free day. Per diem free time on the chassis. The appointment window at the terminal. The pier pass cutoff. The customer's receiving hours. Miss one and the move that quoted at $475 becomes a $1,240 move with $600 of demurrage nobody will pay you for.

Here is what the stack actually looks like at a 60 truck operation running Long Beach and Oakland. Vector or Envase or Compcare handles the dispatch board and invoicing. Somebody has eModal, the terminal websites and TIR portals open in eight browser tabs. Appointment slots come from Voyage Control or the terminal's own booking page, and someone refreshes them by hand at 4am when the drops release. Container status comes from the steamship line site, or a spreadsheet the customer emails on Monday. Chassis pool balances live in a Google Sheet that one dispatcher maintains and nobody else fully trusts. Driver messages are on WhatsApp. Delivery orders arrive as PDFs in a shared inbox and a coordinator retypes container numbers, seal numbers, LFD and weight into the TMS at maybe 90 seconds each, and a transposed digit sends a driver to the terminal for nothing.

The scene that tells you everything: it is Thursday, 6:15pm. A dispatcher is comparing a terminal appointment page against a per diem billing statement against the TMS load list, on three monitors, by eye, because there is no single record that knows a container's last free day, its chassis start date, its appointment, and whether the customer's warehouse can even take it Friday. She finds two containers going into demurrage tomorrow. She catches those. She does not catch the third, because there is no query that could have caught it. That third container ran nine days of demurrage. Take whatever your terminal charges per day, multiply by nine, then by however many of those slip through in a month, and you are looking at real money leaking on the exact thing your software was supposed to prevent.

Problem 1: nothing owns the container as an object with clocks on it

Off-the-shelf TMS products model a load: pickup, delivery, driver, rate. Drayage does not work that way. One container might be a pull, a yard drop, a live unload three days later, an empty return, and a chassis flip in the middle. Each of those legs has its own clock and its own cost, and they all belong to the same container.

Because the incumbent tool models a load, dispatchers create four loads for one container and then keep the relationship in their heads. The last free day gets typed into a notes field. Chassis start date lives nowhere. When per diem invoices arrive from TRAC or DCLI 45 days later, nobody can dispute them because there is no defensible record of when the chassis left the pool and when it came back.

A custom build starts from the container as the root entity, not the load. 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, appointment reference, and every leg hanging off it as a child. Then the clocks become computable. Demurrage risk stops being a note and becomes a field: days remaining until LFD, refreshed against terminal availability. Per diem exposure is a running dollar number per container, per customer, live. One screen: every container in the system ranked by dollars at risk in the next 72 hours. That query does not exist in the tools you are paying for, and it is the single highest value screen in the entire build.

Problem 2: appointments are a manual 4am job, and the slots are gone by 4:07

Terminal appointment systems release slots on their own schedule, and the good windows evaporate in minutes. So somebody sits on eModal refreshing, or you pay a person to work nights doing nothing but booking. If the container is not yet available, the appointment cannot be made. If the appointment is made but the container gets a hold, the slot is wasted and may cost a no-show fee.

Generic TMS platforms will not solve this because they do not want to own the terminal relationship. Some offer a booking integration bolted on the side, but it does not know your dispatch constraints: which driver is near which terminal, which chassis is under which box, which customer can actually receive Friday morning.

What a custom build does: a polling service against terminal availability and eModal, running continuously, matched against your own container list. When a container flips to available and its hold status clears, the system books against your priority rules automatically, at 4:03am, without a human awake. Priority rules you define: closest to LFD first, then highest per diem exposure, then customer SLA tier. This is the part of the build where a model does real work. It can read the messy signals, hold status text, terminal notes, vessel updates, and decide whether a slot is worth taking given the driver plan for that morning, rather than blindly grabbing the first open window. It also handles the after-hours booking window that you are currently staffing with a human, or losing entirely.

Problem 3: delivery orders arrive as PDFs and someone retypes them

Every customer sends the delivery order differently. Some are clean PDFs from a forwarder's system. Some are scans. Some are an email body with container numbers in a paragraph. A coordinator opens each one and retypes container number, seal, weight, LFD, commodity, delivery address, and appointment requirement into the TMS. At 200 containers a week that is roughly 5 hours of pure transcription, plus the errors, and a wrong container number means a driver goes to the terminal for nothing.

Incumbent tools offer EDI, which works beautifully with the two customers big enough to have EDI, and does nothing for the other thirty. So the manual channel stays.

Document extraction with a vision model is solved well enough to rely on now, and this is the clearest AI win in the category. A watched inbox, an extraction pipeline that pulls the fields, a confidence score per field, and a human review queue that only surfaces the low-confidence ones. Container number validation is free: the ISO 6346 check digit tells you instantly if the number is garbage before a driver wastes a turn. We build this so the coordinator reviews the exceptions instead of typing every document. The extraction also learns per customer, because the same forwarder sends the same layout every time, and once it has seen enough of that sender's documents the reviewer stops seeing them in the queue at all.

Problem 4: chassis are invisible until the bill arrives

Chassis is where drayage operators bleed and do not know it. A driver flips a chassis at a yard, nobody records it, and 45 days later a per diem invoice arrives from the pool for a chassis you gave back three weeks ago. You cannot dispute it, so you pay it. Nobody ever adds up the annual total of that, which is precisely why it keeps happening.

The off-the-shelf TMS has a chassis field, and a field is where data goes to be ignored. It does not track pool, ownership, in and out timestamps, flips, or which container was on it at each moment.

A custom build treats chassis as its own first-class entity with an event log: out of pool at timestamp, mounted to container X, flipped at yard Y, returned to pool at timestamp, with the driver's geolocation and photo attached at each event through the driver app. Now when the DCLI invoice hits, you run a reconciliation: their charged days versus your event log, container by container. Disputes go out with photographic and GPS evidence attached. Digital Heroes has shipped this reconciliation view on several logistics builds, and it is usually the feature the CFO points to when the project gets re-approved for phase two.

Problem 5: the customer calls, and you cannot answer

Your biggest account calls at 2pm: where are my 18 containers. The answer requires a dispatcher to check the TMS, then the terminal site, then a driver on WhatsApp. Twenty minutes for one call. You get that call fifteen times a day. That is a full-time person answering questions your software should have already answered.

Off-the-shelf portals exist but they show what the TMS knows, which is the load status a dispatcher last typed. They do not show terminal availability, hold status, or a real ETA.

The custom answer is a customer portal fed by the same container object: live status, LFD countdown, appointment time, driver ETA from the driver app's GPS, POD photo the moment it is taken, and per diem exposure visible to the customer so they stop blaming you for their own warehouse delays. Add proactive alerts: an email at 48 hours to LFD saying we need a delivery window or you will incur demurrage, with the dollar figure. That email single-handedly kills a category of argument. AI helps on the follow-up side: draft the exception notes and the customer updates from the event log, so a dispatcher approves a message instead of composing one from scratch.

What this costs and how long it takes

These bands are Digital Heroes delivery experience across 2,000-plus projects, not an industry survey. A focused first release, meaning the container object with clocks, chassis event tracking, appointment automation against one or two terminals, document extraction, and a driver app, runs $60k to $130k and ships in 12 to 16 weeks. A full platform, adding billing and per diem reconciliation, customer portal, EDI, multi-terminal, yard management and reporting, runs $150k to $400k phased over 6 to 12 months.

What pushes price up specifically in drayage: the number of distinct terminals you touch, because every terminal portal is its own integration with its own quirks and no two behave alike. Steamship line data, which ranges from a clean API to screen scraping. Chassis pool integrations, which are the least standardized data in the business. A driver app in two languages with offline capability, because drivers lose signal inside terminals and the app has to queue events and sync later. And multi-entity billing if you run separate operating authorities per port. What pushes it down: starting with one terminal and one chassis pool, proving the demurrage-risk screen pays, then expanding.

Build versus buy: take the honest position

Buy if you run under about 25 trucks, one terminal, and one chassis pool. Envase or Vector at their list pricing will cost you a fraction of a build and your volume does not generate enough clock-management pain to justify custom code. Buy also if your growth plan is to stay exactly this size.

Build when these signals show up together: you are past 40 trucks or 150 containers a week, you touch two or more terminals, you have a person whose job is substantially copying data between systems, and you cannot produce a per diem dispute with evidence. One more signal that decides it: when you have already bought a second tool to compensate for the first one, a separate appointment bot, a separate yard sheet, a separate billing spreadsheet, you are already paying for a custom system, just an unintegrated one held together by people. At that point the build is the cheaper option, and it is the one you own.

How to choose a developer for drayage software

Ask them to model the data before they quote. If their proposal has loads at the root and containers as an attribute, they have built freight software, not drayage software. The right answer puts the container at the center with legs, chassis events, and clocks hanging off it. This one question filters most of the market.

Ask specifically what they have integrated. Not "we do integrations." Which terminal portals, which chassis pools, which steamship lines, and what broke. Anyone who has actually done eModal or a TIR portal has stories about session handling and rate limits. Anyone who has not will say it is straightforward.

Ask how they handle the driver app going offline. Drivers lose signal inside terminals, every day. If the answer does not involve a local queue and conflict resolution on sync, they have not shipped a driver app that survived contact with a real yard.

Ask who owns the code and where the data lives. You want the repository in your organization, the infrastructure in your cloud account, and the container history exportable on day one. Also ask about FMCSA hours of service handling and how ELD data flows in, and if you move bonded or in-bond freight, ask what they know about CBP and ACE filings before you sign anything.