The dispatch system that runs your haulage fleet

One screen, usually called Traffic or the Board, and one person who lives in it.

A typical business running one of these has 20 to 60 vehicles, one or two depots, and a traffic office of two or three planners handling somewhere between 80 and 300 loads a day. Whether it was written in 2004 or 2019, it does the same job, and the office runs on it the same way.

Plenty of fleets this size run a bought transport package instead. This page is about the other kind: the board written for one fleet, or a package customised so far that it can no longer be upgraded.

In the planner's words, it takes the job from the customer's phone call or email, puts it on the board, allocates a driver and a vehicle, prints the run sheet and the delivery notes, records the POD when the paperwork comes back, and raises the invoice. Somewhere in it is a rate table nobody dares open, a subcontractor screen for the loads the fleet cannot cover, and a report the MD reads every Monday.

The rules it holds are the reason it has lasted:

• The rate for one supermarket contract is per pallet up to 26 and per load beyond it, except on a Friday.
• Certain vehicles cannot go to certain sites, because of a low bridge, a weight limit, or a customer who banned a driver in 2016.
• A job is not invoiceable until the POD is scanned, unless it is for the two customers who accept a signed run sheet instead.
• A multi-drop job is priced as one load but reported as several deliveries, for the KPI the biggest customer measures.

Nobody wrote any of that down. The system is the document.

Written somewhere between 2002 and 2012 by a contractor who knew the trade, and extended every year since. A Windows program in Visual Basic 6 or Microsoft Access, with the data in SQL Server or an Access file, Crystal Reports for the run sheets and delivery notes, and an export to Sage on a Friday afternoon. It runs on a PC in the traffic office or a server in the comms cupboard, and it prints to the printer it has always printed to.

The contractor has retired or moved away and the support contract lapsed years ago. Nobody has changed the code since, which is why it still works, and why nobody wants to be the first to try. It cannot be opened from home, it does not know where the truck is, and the POD comes back on paper.

The same board built between 2016 and 2022, usually by a small agency or a freelancer, as a web system in React, Angular or Node or PHP, or put together in Bubble or Power Apps by someone in the office who was good with that sort of thing. It opens in a browser, the drivers have an app of sorts, and the biggest customer has a login. From the traffic desk it looked like the future had arrived.

What stopped this one is usually something the customers noticed first. The tracking was wired to the telematics box the fleet had in 2019, and when the fleet changed provider the trucks dropped off the board. The rate table only knows that year's customers, so every new rate waits for a developer the business no longer has. Meanwhile the agency has moved on, the code has stood still, and the driver app has quietly fallen off the newer phones. Since 2023 a few offices have tried again in an AI app builder and got as far as the driver's screen before the work stalled. Newer than the Old Guard, and stuck just as fast.

A day of loads run by two people, and an invoice for every one of them.

The board is what lets a small traffic office run a fleet that would otherwise need twice the staff. The planner sees every load, every driver and every gap at once, and moves work with a few clicks. The run sheet the driver picks up at six in the morning comes out of the same screen, so what was planned is what gets done.

The link to invoicing is the other half. Because the POD closes the job and the job feeds the invoice, the business bills every load it moves, at the right rate, and the weekly Sage export keeps the accounts within a week of the wheels. When a customer disputes a delivery, the answer is on the screen in ten seconds: who, when, signed by whom.

That is why the system is still there. It fits how the office works, because it was built from how the office works.

Systems like this rarely fail. They stop keeping up.

The customers moved on. The big accounts now want live tracking, an ETA, and a POD by email within the hour. The board knows where a load should be, not where the truck is, and the POD arrives on paper two days later. So the office keeps a spreadsheet beside the system for the customer portal, and someone updates it by hand.

It lives on one machine. The system runs on the traffic office PC or the server in the cupboard, often on Windows Server 2016 with a SQL Server 2016 database. SQL Server 2016 updates ended in July 2026 and Windows Server 2016 follows in January 2027. Nobody wants to move it, because the last time it moved the printing stopped for a day.

The person who knew it has gone. The contractor who built it retired or moved away, the support contract lapsed, and the firm that looks after the PCs will fix the printer but not the program. Small changes wait. Large ones are not attempted.

It cannot leave the office. The planner cannot see the board from home, the drivers cannot see their jobs on a phone, and the transport manager keeps the defect books on paper because the compliance side never made it into the system.

The same board, in a browser, with the rest of the business connected to it.

Each of these comes from something the system already does.

Live tracking on the board. The vehicle's position from the telematics the fleet already pays for, shown against the load it is on. The planner stops phoning drivers for updates, and the customer gets an ETA without ringing.

PODs on the driver's phone. Signature, photo and time at the point of delivery, in the office before the truck has left the site. The job closes, the invoice raises, and the two-day paper gap disappears.

Invoicing the same day. With the POD in electronically, the weekly Sage batch can become a daily one, and cash arrives sooner.

A customer view. The biggest accounts get a login to see their own loads, which takes the phone calls and the hand-updated spreadsheet out of the office. Same data, one place.

Off the one PC. The database moves to a version that is still supported, on a server that is too, with backups that have been tested. The Cyber Essentials question stops being awkward.

The rules, written down. The rate table, the site restrictions and the invoicing exceptions come out of the code into screens the office can see and change. A new planner learns the board in days.

None of this needs the board switched off. It gets added to.

The hours the office spends retyping what already arrived in writing.

AI earns its place on a dispatch system in the paperwork, not the planning. There are three places to start:

Bookings read from the email. The customer's booking arrives as an email, a PDF or a photo of a delivery note, and a planner retypes it onto the board. AI reads it and drafts the job, with the collection, the delivery, the pallets and the reference filled in, for the planner to check. When a third of 80 to 300 loads a day arrive that way, at a couple of minutes' typing each, the desk typically gets an hour or two a day back.

PODs matched to jobs. The paperwork that comes back is a signature on a crumpled sheet or a photo from the cab. AI reads the reference, matches the POD to the job and flags the ones that do not match. Matching a week of PODs before the invoice run typically shrinks from most of a day to half an hour on the ones that failed.

Queries answered from the board. "Where is my load?" and "Did it deliver?" arrive by email all day. AI drafts the answer from the board's own data, with the job record it came from shown underneath, and the planner checks it and sends. At a query for one load in ten, that is a dozen or more lookups a day, and typically half an hour back.

Not worth doing: AI route planning for a fleet this size. The planner's knowledge of drivers, sites and the low bridge on the back road beats any model, and nobody in the office would trust the result.

All three read from the board or write to it, so they wait until the first stage has made the board safe to change. The assessment maps where AI would pay back on the system as it stands.

Stabilise first, then one process at a time, with the old system as the fallback.

1. Stabilise. Source code found or recovered, the database on a version that is still supported, a backup that has been restored at least once, and a test copy of the system so changes can be tried without touching the live board. This goes first because everything after it depends on being able to change the system safely, and because it takes the January 2027 deadline out of the conversation.
2. PODs and the driver app. The first new piece is the one the customers feel: a phone app for the drivers that writes into the existing database. The board does not change. The office watches PODs arrive during the day.
3. The board in a browser. The planning screen opened in a browser, on the same data, run alongside the old form until the planners choose to stop opening it.
4. Tracking, the customer view, daily invoicing. Each a stage, each priced on its own, each live in weeks.
5. Retire the old program when nothing still depends on it. The last thing to go is usually a report somebody loves.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a dispatch system that means a few days with the planners and the code, finding the rules and the risks, 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, and so does each technology the system is built on: Visual Basic 6, Microsoft Access, SQL Server, Crystal Reports and Sage integrations, and for the newer generation React, Angular and Node and old PHP.