What a transport management system actually needs to do

The system competes with a WhatsApp group

Whatever you buy or build is not replacing a blank slate. It is replacing a working arrangement: a WhatsApp group, a dispatcher's notebook, a shared spreadsheet, and a set of phone numbers. That arrangement is fast, flexible, and understood by everyone using it.

A new system loses to it whenever entering a trip takes longer than sending a message. This is the single most common reason transport software ends up half-used, with the real picture still living in the group chat and the software updated retrospectively, if at all.

The practical test is simple: how many seconds does it take to record a trip that has just been assigned by phone? If the answer is more than about twenty, dispatchers will batch it up for later, and later often never comes.

Someone has to be able to answer 'where is it?' without calling

Almost every operational escalation in transport reduces to a location question — from a customer, from sales, from a branch. If answering it requires a phone call to a driver, the software has not removed the work, it has just added a place to type things.

This is why tracking integration matters more than tracking features. Your vehicles are probably already on a GPS provider your fleet chose years ago. A system that insists on its own tracking hardware is asking you to run two truths. One of them will be wrong.

Proof of delivery is a dispute-settling tool

Digital proof of delivery is usually sold as paperless efficiency. That undersells it. Its real value shows up weeks later, when a consignee claims short delivery or damage and someone has to decide who pays.

For that, a signature is rarely enough. What settles disputes is a photograph, timestamped, with a location, attached to a specific consignment and captured by a named person. Systems that treat PoD as a checkbox produce a tick where you needed evidence.

It must work where there is no signal

Trucks go where connectivity does not. If the driver app requires a live connection to record a delivery, it will fail exactly at the moment the record matters, and the driver will fall back to a phone call.

Offline-first is an architectural decision, not a setting. The app needs a local database and an outbox that queues actions and replays them when signal returns, with each action carrying a client-generated identifier so a replay cannot create a duplicate. Retrofitting this later usually means rewriting the app.

Costing belongs in the same system as the trip

Fuel, tolls, driver advances, detention and damages decide whether a trip made money. When those live in accounting and the trips live in operations, nobody sees profitability per vehicle or per route until month end — and by then the decisions that caused it are three weeks old.

Capturing costs against the trip as it happens is less accurate than the accountant's version and far more useful, because it arrives while you can still act on it.

A shorter checklist

• Recording a trip is faster than sending a WhatsApp message
• Location questions are answered without phoning a driver
• Proof of delivery captures photographic evidence, not just a signature
• The driver app works with no signal and syncs without creating duplicates
• Trip costs are captured against the trip, while it is still running
• It integrates with the GPS provider you already use, rather than replacing it

The uncomfortable part

None of the above is about features, and most of it cannot be assessed from a demo. It is assessed by watching a dispatcher work for an afternoon and asking what would break.

That is also why so much transport software disappoints. It is specified in a meeting room by people who will never use it, and evaluated against a list rather than against the day it has to survive.