Drayage operating systemNY / NJ first
The Operating System
for Drayage
The container, the chassis, the driver and the invoice belong on one record. We are building DrayBase for the way dispatchers working Newark and Elizabeth already do the job — starting from the move, not from a clipboard.
01The work
Most drayage software still assumes a clipboard
This list did not come from a survey. It came from one real Newark operation — the carrier we are building for first — and from taking apart, screen by screen, the drayage TMS it pays for today. None of the losses was about a missing button.
- Screen hopping
- Moving between the dispatch list, the itinerary and the planner to complete one assignment. The data is the same in all three; only the layout changes.
- Report sprawl
- Several reports answering the same question about the same week, none of them marked as the one accounting trusts. So the controller rebuilds it in a spreadsheet anyway.
- Per diem
- Charges on a container whose last free day passed while the LFD list was being reconciled by hand on a Monday morning.
- Proof by text
- A single delivery's proof arriving as separate photos on a dispatcher's personal phone, then re-keyed at the office before anyone can invoice it.
- Dead alerts
- A failed accounting sync banner that has been on screen so long that every real alert now gets scrolled past along with it.
Every one of those is a modeling problem, not a feature request.
So DrayBase starts from the move — one container, one chassis, one driver, one clock — and lets the screens follow from it.
02Dispatch
One board, saved per dispatcher
Columns, filters and sort are yours to keep. Select rows and the action bar comes to you. When an agent has a better plan it is designed to appear as a row on the board, with its evidence attached — and to wait for a person.
03The box
The container, the bogie and the clock on one record
Free time, appointment window, chassis pool, empty return and the paperwork belong on the same screen, because on the ground they are the same problem. Split them across three systems and the clock is the thing that gets lost.
Illustration of the data model — a sample record, not live data. The consignee and the steamship line are fictional.
Nothing about this container lives in a second system.
Chassis splits, pool balances, terminal appointments and last free day are the four things that decide whether a move earns money. In most systems they are four separate screens owned by three different teams.
04Agents
Six agents on the board, and a switch on every one
This is the roadmap, not the changelog: none of the six is built yet. Each is designed to watch a specific set of signals with an autonomy level you set, and none of them will change state on its own out of the box — they suggest, alert or draft, and a dispatcher decides.
Anything that changes state waits for a person. Autonomy is raised per account and per lane, once you have watched an agent work — never as a default we chose for you.
Every suggestion carries the record it was built on. If the evidence is thin, the agent has to say so instead of rounding it into confidence.
Anything an agent does can be undone, and the trail stays on the record. An action you cannot walk back is not one we will hand to a model.
05Switching
What actually changes when you move
A comparison of design decisions against the legacy drayage systems most East Coast carriers run today — not a benchmark, and not a bake-off we ran. Where an incumbent is better, we will tell you on the call.
Rows marked Planned are not built yet. The left column is what DrayBase is being built to do; the right is what carriers tell us they live with now.
Early access
Put your own lanes on DrayBase
Access opens one port at a time so we can migrate properly. Tell us where you run and you will hear from us when your port is next.
Or write to [email protected]. The founders read it.
Operated by DrayBase LLC · governing law Georgia
Smarter Drayage.
Stronger Connections.