The booking system that runs your container haulage

Two screens: Bookings for the clerks and Traffic for the planner, with one database behind both.

A typical business running one of these has 30 to 80 tractor units, a yard within reach of the port, and an office of five or six across bookings, traffic and accounts, moving between 80 and 250 boxes a day. Whether it was put together in 2006 or 2018, it does the same job, and the office runs on it the same way.

In the office's words, the booking arrives from the forwarder by email and gets keyed in: container number, size, line and vessel, collection and tip addresses, the customs status, the release PIN, the return depot and the free days. The clerk books the slot on the port's booking site in another tab and keys the reference back. The planner puts a driver, unit and skeletal against it and prints the job sheet. The box moves through collected, delivered and returned, the invoice raises with the surcharge and any waiting time, and the month's invoices go to Sage.

The rules it holds are the trade's:

• Free days count from discharge for one line and from gate-out for another, and quay rent runs on the port's calendar, not the line's.
• A 20ft box over a certain weight goes only on a sliding skeletal, and two named drivers will not take them.
• One forwarder's rate includes two hours' waiting, billed in half-hours after that; another includes none.
• An import box emptied near tomorrow's export collection is offered as a triangulation before an empty run goes out.
• No box goes to a driver until customs has cleared it and the line has released it.

The contract files say some of that. The system says all of it.

Built in two halves, a few years apart. The bookings side was written in Microsoft Access in the mid-2000s by a contractor who understood merchant haulage. When the port's booking rules outgrew it, somewhere between 2010 and 2014, a local developer added a .NET Framework program for the traffic screen and the port paperwork, moved the data into SQL Server, and left both front ends running against it. The export to Sage goes at month end. All of it sits on one Windows server in the office, usually the same box the shared drive lives on, with the Access screens opened from the clerks' PCs.

Neither developer is around now. The Access half is left alone because the .NET half reads the same tables, and the .NET half has no source anyone can find. It cannot be opened from the yard or from home, the port's slot lives in another browser tab, and the free days are a printout read at eight in the morning.

The same system built between 2016 and 2022, usually by a small agency or a freelancer, as a web system in React, Angular or Node, PHP or early .NET Core, or put together in Zoho Creator or Power Apps by a bookings clerk who had taught themselves the tool. The clerks book in a browser, the planner has a board on a wide screen, the drivers have an app of sorts that shows the next box, and the biggest forwarder has a login to watch their own. From the office it looked as though the port had been brought indoors.

The free-days count is where it went wrong. It was written for the lines the haulier worked in 2018, all counting from discharge, so the line that counts from gate-out is tracked in a spreadsheet beside it, and the demurrage board promised for the second phase never arrived. The agency sent its last invoice long ago, and the driver app will not install on the phones the newest drivers carry. Hauliers who have had another go since 2023 with an AI app builder mostly got a booking screen that looked finished, then stalled at the port paperwork. Ten years younger than the Access screens, it is stuck in the same yard.

Because it is the only place that knows where every box is and what it is costing.

A container haulier lives on the gaps between events: the box discharged, the slot booked, the truck through the gate, the box tipped, the empty back at the depot. The system holds each of those against the booking, so a clerk answers a forwarder's "where's my box" from the screen rather than from a driver's phone. The job sheet carries the PIN, the slot and the return depot, which is what stops a truck being turned away at the gate with the day's plan behind it.

The invoicing link is what makes the extras real. Waiting time, the surcharge, a second tip, an out-of-hours delivery: each is a line on the job, so it gets billed rather than remembered. And the demurrage report, run each morning, is the office's early warning on the boxes that will start costing money if nobody moves them.

The office does not think of it as software. It is the way the job is done.

Systems like this do not break. The world around them changes.

The port and the lines moved to portals. The slot, the release, customs clearance and the vessel's arrival each live on a website now, and the office keys them into the system by hand, several times a box. A mistyped container number fails the check digit at the gate and the truck comes back empty, the slot wasted and the next box late.

Free days run out on a report. Either generation knows the free days, but the warning is a person reading a printout or a list at eight in the morning. A box that overstays turns up on the line's invoice weeks later and gets paid, because nobody can now prove when it left the port.

Two front ends, one set of rules, kept in step by hand. The Access screens and the .NET program each carry a copy of the rate and surcharge logic. A change is made twice, and the month one copy was missed, a big account's invoices went out at the old surcharge and the credit notes took a fortnight.

The server it shares. The .NET program and the database sit on a Windows Server 2012 box, which ended in October 2023. The insurer's questionnaire asks about it now, the IT company will not move it because the Access links break every time anyone tries, and so it stays.

The same bookings, with the port, the free days and the driver connected to them.

Every one of these comes out of something the system already does.

The port booking made once. The slot reference, the release PIN, the customs status and the container number live on the job. The number is checked against its check digit, and no driver is allocated until the box shows cleared and released. One keying, one place, and the errors behind the gate refusals go with it.

Free days on a countdown. A board of boxes ordered by days of free time left, by each line's rules, with the return depot on every card. The planner books the empty run before the charge starts, and the line's invoice is checked against the system's own dates.

One set of rules, in data. Rates, the surcharge, the waiting-time terms and the trailer restrictions come out of both codebases into screens the office owns. A change is made once and applies everywhere.

Waiting time with evidence. The driver's phone stamps arrival and departure at the customer's gate. The extra goes on the invoice with the times beside it, and the argument about it mostly stops.

The traffic screen in a browser. The planner's board opened in a browser on the same data, off the shared server or the hosting account nobody owns, from the yard or from home when a vessel is late on a Sunday.

None of this switches the old system off, whichever generation it is. Each piece is added beside it.

In the paperwork the lines and the forwarders send, and the empty runs nobody had time to plan.

AI does the reading and the matching here, and the plan stays with the planner:

Bookings read from the forwarder's email. The booking arrives as an email or a PDF, and a clerk keys the container number, the line, the vessel, both addresses, the PIN and the return depot. AI drafts the booking from it, and the clerk checks the fields against the email rather than typing them. At 80 to 250 boxes a day and two or three minutes of keying each, the bookings desk typically gets a couple of hours a day back.

The lines' invoices read against the system. The demurrage and detention invoice arrives weeks after the box went back, a PDF with a page of charges. AI reads each charge, matches it to the box and the system's own gate and return dates, and flags the ones that disagree. The clerk queries only those, typically a morning back each time a big line's invoice lands.

Tomorrow's triangulations suggested. From tomorrow's export collections and today's import empties, AI drafts the pairings for the planner to accept or bin. The half hour each evening that went on reading two lists side by side goes back to the planner.

Questions the reports never covered. "Which forwarder's boxes waited longest at the tip this quarter?" AI answers from several thousand jobs in plain words and lists the boxes behind the answer for the office manager to check. The afternoon of filtering exports before a rate review typically becomes a few minutes of reading.

Not worth doing: AI to book the port slots. Availability and the planner's knowledge of which driver can make which window decide it, and the port's own system has the last word.

Each of these reads the bookings or drafts into them, so none starts until the first stage has made the system safe to change. The assessment shows where on this system AI would pay back first.

Stabilise first, then the pieces the office feels, with the old screens running throughout.

1. Stabilise. Source for both front ends, or for the agency's code, found or recovered. The database on a version that is still supported, on a server that is too, a backup restored on purpose, and a test copy so a change can be tried away from the live bookings. This goes first because the 2012 server, or the hosting account nobody owns, is the one thing that could stop the business overnight.
2. Free days, customs and the port slot on the job. The countdown board, the customs status and the slot reference in the booking, all writing into the existing database.
3. The driver's phone. The job sheet, the PIN and the return depot on a phone, with gate and tip times stamped as the driver goes. Paper sheets keep printing until nobody collects them.
4. The traffic board in a browser, and the rules into data. Rates and surcharge out of both programs into one place. Run beside the old screens until the planner stops opening them.
5. Retire the old front ends when nothing depends on them: the Access screens first and the .NET program after, or the agency's site in one go. The last to go is usually the month-end Sage export somebody trusts.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a booking system with two front ends that means a few days with the clerks, the planner and both codebases, finding where each rule lives and which copy is right, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work, what drives the price and the payment terms each have a page, as does each technology in the system: Microsoft Access, .NET Framework, SQL Server and Sage integrations, and for the newer generation React, Angular and Node, old PHP and early .NET Core.