AI in a transport company

Why AI in transport starts in the forwarding office, not in the cab

AI is sold to transport companies from the fleet side: route optimisation, delay prediction, driving-style analysis. Those projects can be valuable, but they share a precondition the offers stay silent about — months of telematics history joined to the orders, which most fleets simply do not have in that form. The project then starts with building data collection, and the first result arrives after a year, not a quarter.

Meanwhile, in the same company, a stream of work flows every day that AI can take over now: transport orders arriving by email and from freight exchanges in a dozen formats, retyped into the TMS by hand; CMR scans and delivery documents collected from drivers and attached to orders before invoicing; delivery notifications and status queries answered by hand from the same templates; subcontractor invoices checked against rates one by one. These are document- and text-based processes — the data exists, the rules can be written down, and a mistake is detectable and reversible.

That is why a good first AI project in a transport company looks unspectacular: it does not touch the vehicles, it touches the flow of information around them. In return, it pays off in weeks and funds the next steps.

What we actually automate in transport companies

• Transport order handling. Reading orders arriving by email, as PDFs and from freight exchanges — in layouts nobody has described before — and preparing the TMS entry for a forwarder to approve. This is the most common first process: it recurs daily, and any mistake would be caught at order confirmation anyway.
• Consignment documents and CMR. Attaching CMR scans and photos, pallet notes and delivery documents to the right orders, checking completeness before invoicing, and a list of gaps with reminders drafted. It shortens the stretch where today the longest wait is not for the haul but for the paperwork after it.
• Delivery notifications and status queries. Drafting notifications and replies to status questions from the order data — for a forwarder to approve before anything goes out to the customer. Repetitive work that today interrupts dispatchers doing more important work.
• Subcontractor settlements. Checking carriers’ invoices against orders and agreed rates, with a list of discrepancies to explain — instead of comparing two lists by hand. Ambiguous cases go to a person, not straight to posting.
• Driver communication. Consolidating reports and documents sent in by drivers into one register, with reminders for what is missing — and an assistant that answers recurring procedural questions from the internal instructions, citing its source.

The common denominator: a person approves the output, the system prepares it. Which processes qualify for this kind of automation at all — the five conditions a good candidate must meet — is set out on our AI automation page; in a forwarding office those conditions are checked in exactly the same way.

What we do not promise

• Route optimisation without a data history. A model learns from journeys that have already happened. If the fleet does not record times, routes and stops in a form that can be joined to the orders, an honest offer starts with data collection — and says plainly that the optimisation result comes later.
• Delay prediction “on the side”. Credible ETAs need telematics integration and months of journey history. It can be done well, but as a separate project with its own budget — not as an add-on to document automation.
• Unattended handling from day one. Everything that goes out to customers and subcontractors passes through an approval mode first. The decision to loosen oversight is made on pilot data, not by assumption.

How we work

The same way as in any implementation: one process, a number measured before the start — for example, minutes from an order arriving to its TMS entry — the narrowest possible pilot, and parallel running before the switch. The system prepares, a person approves every output. The full course — four phases and what you receive at the end of each — is set out in our implementation methodology, and the full scope of the service, from process audit through to upkeep, on our AI implementation page.

A separate subject that comes up in every transport conversation is data: rates, customer data, driver data — including location data where telematics is involved. Where data goes in a model integration, and what to ask any supplier, is set out on our security and GDPR page.

What it costs

Three things drive the cost: the number of systems to connect, the state of the data, and the level of certainty required. Fleet size barely matters — what matters is whether the orders live in one TMS or in the dispatchers’ mailboxes and spreadsheets beside it. All the components, upkeep included, are broken down in our note on what an AI implementation costs.

Frequently asked questions

Where should a transport company start with AI?

In the office, not in the fleet. Handling transport orders, assembling consignment documents, delivery notifications and subcontractor settlements are document- and text-based processes — the data already exists in mailboxes and the TMS, a mistake is reversible, and results show in weeks. Projects on vehicle data — route optimisation, delay prediction — need a telematics data history and separate integration, so they cost more and take longer. Starting with them is the most common way transport companies spend their budget before seeing a first result.

Will AI optimise our routes and predict delays?

Only once there is something to learn from. Route optimisation and delay prediction need months of telematics history — mileage, journey times, stops — joined to the orders. If the fleet does not collect such data, or collects it in a system the data cannot be exported from, an honest offer starts with putting data collection in order and says plainly that the predictive result comes later. An offer that promises optimisation without asking about your data history is promising a data-collection project under another name.

Will this work with our TMS?

That is a question the audit at the start of a project settles, but the principle is simple: if the system has an API or file import, integration is a matter of scope, not possibility. The TMS systems in use vary widely here, and that difference affects the cost, not the point of the project. More important than the system itself is how orders reach it: email, freight exchanges, customer portals — because that stretch of manual retyping is what we automate first.

What does an AI implementation cost in a transport company?

Cost is driven by the number of systems to connect — TMS, email, freight exchanges, customer systems — the state of the data, and the level of certainty required. Fleet size barely matters: a forwarding office with one TMS and orders arriving through one channel is a matter of weeks; the same work scattered across dispatchers’ mailboxes and spreadsheets is a different project and a different quote. Upkeep is a separate line: per-operation fees and periodic retesting after model version changes. We break the components down in our note on what an AI implementation costs.

What about driver and customer data?

Orders and consignment documents contain personal data — of drivers and of contact people at customers and consignees — and on-board systems additionally produce employee location data, which is subject to stricter rules of its own. That has to be settled before the integration, not after it: which data leaves the company at all, where it goes and on what basis — from the choice of provider and processing region to limiting the data to the minimum the step needs. The principles, and the questions worth asking any supplier, are set out on our security and GDPR page.