.png)
MD Freighting expanded data capture from 12 to between 150 - 300 datapoints datapoints per consignment - and in doing so, changed what their network could see about itself.
That shift is worth pausing on, because it points at a bigger question every carrier running a transport management system (TMS) for freight carriers in New Zealand should be asking right now: are you building visibility, or just building a better filing cabinet?
There's a lot of industry chatter at the moment about digital twins - software models that simulate a freight network and predict what's likely to break next. Congestion on a corridor. A depot approaching capacity. A driver roster stretched too thin on a Friday before a long weekend.
It's an appealing idea. But a digital twin is only as good as what it's fed. You can't model a corridor's behaviour if the system underneath it only knows the start and end of a job, not the states in between.
Most TMS platforms report history well. Job created. Job invoiced. POD received, eventually. That's reporting, not visibility. Reporting tells you what already happened. Visibility tells you what's happening now, and gives you enough structured signal to reason about what happens next.
The difference sits entirely in the data layer.
Take a run pattern that's genuinely common - a metro delivery route through East Auckland with a 10am cut-off for a retail customer. A carrier operating on end-state data alone knows two things: the job was allocated, and the job was completed (or wasn't).
A carrier capturing transition states - scan at pickup, geofence entry at depot, handover confirmation, exception flagged in real time if a gate is closed or a dock is full - knows considerably more. They know at 8:40am that three jobs on that run are trending late, before the cut-off is even missed. That's the operational difference between reacting to a customer complaint at 11am and rebalancing the run at 8:45am.
This is what MD Freighting's expansion from 12 to over 150 datapoints per consignment actually represents in practice. Not more dashboards for the sake of it - more machine-readable moments captured as freight physically moves, which is the only raw material any predictive model, digital twin or otherwise, can work from.
If you're weighing up whether your current system is closer to reporting or visibility, the test is simple. Ask what your platform captures between job creation and job completion. Was the freight scanned at pickup? Was the handover captured, or assumed? Is an exception logged the moment it happens, or reconstructed later from a phone call and a shrug?
Architecture enables data capture. Data enables intelligence. Intelligence enables automation. It's a chain, and it only runs in that order - you can't skip the first link and expect the third to work.
Digital twins, predictive alerts, automated exception handling - these are all downstream of one decision: how much operational truth does your system actually encode as freight moves through it?
What would your dispatch team need to see two days out, rather than two days late - and does your current system give it to them?
Book a demo
