Freight visibility across carriers

What gets asked for, and what gets used

Almost every visibility conversation opens the same way: we ship on forty carriers, nobody can tell a customer where their order is, and we want one screen. That is a reasonable request. It is also not the thing that will get built, because the screen is the last two weeks of a project whose first three months are spent deciding that the load your planner calls 88214, the carrier calls PRO 043-7719912, the receiver calls PO 4400319, and the driver's phone calls a trip id, are all the same shipment. Get that wrong and the map shows a truck in the right place attached to the wrong order, which is worse than no map.

The second thing that goes wrong is the clock. Freight events arrive late, out of order, in local time, sometimes without an offset, and sometimes twice. A dashboard that renders whatever arrived last will show a delivery before a pickup and a dwell time of negative four hours, and the first time a customer service rep sees that, the tool is done. Nobody says so out loud. They just go back to calling the carrier.

The third is coverage, and it is the number that should be on the first slide and almost never is. A visibility platform can be excellent and still only see 70 percent of your loads, because the other 30 percent move on carriers with three trucks and no integration of any kind. A screen that is right about most loads and silent about the rest teaches people to check everything by phone anyway.

The identifier join is the project

One truckload shipment can carry eight identifiers before it is delivered. Your transportation system assigns a load number. The carrier assigns a pro number or a trip number. There is a bill of lading number, often printed by your warehouse, sometimes by the carrier. Your customer gave you a purchase order number and expects to see it. The receiver's dock scheduling site issued an appointment number. If it moved intermodal there is a container number and a rail waybill. If a broker is involved, the broker has its own load id and the underlying carrier has a different one again.

Carriers send events keyed on whichever identifier they own. Your customers ask questions keyed on the one they own. Nothing in the middle guarantees a match. Pro numbers get reused after a year at some carriers. Purchase orders split across two trucks. A load gets rebilled to a different carrier at 4 a.m. and the original tracking thread keeps sending position updates for a trailer that no longer has your freight on it.

The design that survives is a shipment record you own, with an identifier table hanging off it: every id, its issuer, when it was observed, and what it came from. Matching runs as a set of ranked rules rather than a single key, and every match records which rule fired. When a match is uncertain, say so in the record and show it in the interface as unconfirmed rather than guessing. Teams skip the provenance because it is unglamorous, then spend the next year unable to answer why a load was linked to the wrong order.

Every mode hands you a different quality of feed

Talking about freight visibility as one problem hides the fact that parcel largely works, truckload half works, and the rest is a negotiation. Budget by mode, not in aggregate.

Mode	What you typically get	Usual lag	Where it breaks
Parcel	Mature carrier APIs, scan-level events, consistent schemas	Minutes	Almost nothing. Volume and rate limits
Truckload	Status messages from the carrier, plus position from the telematics unit or a driver app	Minutes to hours	Small carriers with no integration; drivers declining location sharing
LTL	Status at terminal milestones, keyed on the pro number	Hours; some carriers post once nightly	Terminal-level granularity only. You know the city, not the street
Intermodal	Rail event codes at ramps and interchanges, plus the drayage leg separately	Hours	The two drayage legs are usually the blind spots, not the rail move
Ocean	Container milestones, vessel schedule, terminal availability	Hours to a day	Schedule drift, terminal appointment data that lives nowhere useful

An honest architecture treats each of these as a separate ingestion with its own freshness contract, and shows the age of the newest event on every shipment card. A load whose last event is nineteen hours old should look different on screen from one updated four minutes ago, even when both say in transit.

Time zones and geofences decide whether the data is usable

Two boring details cause most of the visible defects. The first is that carriers send event times in the local time of the event, and a meaningful share of feeds omit the offset entirely. If you store what you were given and render it in the viewer's time zone, a pickup in Denver and a delivery in Newark produce dwell figures that are wrong by hours and occasionally negative. Store the instant in a single reference frame, keep the original string and the location that produced it, and render local time with the zone shown. It costs a day and it prevents a class of bug that otherwise never fully goes away.

The second is geofencing. Arrival and departure events are usually derived by drawing a circle around a facility and watching a position cross it. Draw it too small and a truck parked at the far end of a hundred-acre yard never arrives. Draw it too large and the truck stop across the highway triggers arrival forty minutes early, which quietly inflates every detention calculation you run. Typical dock radii land somewhere between about 150 and 400 metres, but the real answer is per site, and for big yards it is a polygon rather than a circle. Whoever owns the facility list has to own the geometry, and that person is normally in operations, not IT.

Then there is the sequencing. Events arrive out of order more often than teams expect: a departure lands before the arrival it followed because two systems relayed them on different paths. Do not overwrite state from whatever arrived last. Keep the event log, derive the current state from the whole log, and let a late arrival reshape the timeline rather than corrupt it.

An ETA that moves twenty times a day is not an ETA

Predicted arrival times are the part everyone wants and the part that generates the most distrust. The mathematics is not the hard part; road-network routing with live traffic and historical dwell gets you a serviceable estimate. The hard part is that a customer service representative has to say something to a customer, and if the number changes every twenty minutes, the representative stops using it and goes back to a promise built out of experience.

Three practices make an estimate usable. Publish a window rather than a minute, and widen it honestly when the inputs are stale. Hold the published value stable unless the new estimate moves outside a threshold, so small jitter never reaches a human. And separate the internal estimate, which can update continuously, from the committed one, which changes only when someone would genuinely act differently. The internal number drives alerts; the committed number goes on the portal.

Measure it the way the business feels it: what fraction of loads arrived inside the window you published four hours out, and eight hours out, and at pickup. A single mean-absolute-error figure across all loads hides the only cases anyone cares about, which are the ones that missed by a lot.

What people use is the exception list, not the map

The map sells the project and the exception list keeps it alive. A planner with four hundred loads moving today does not want to look at four hundred anything. They want the eleven that will miss their appointment window, ranked, with a reason and a phone number. That framing changes the requirements substantially: you are building a queue with an owner and a disposition, not a visualization.

A useful exception has four properties. It fires before the miss, not after, which means it is driven by projected arrival against the appointment, not by an event that already happened. It says why, in a sentence a person can act on: still at origin at 14:00 against a 17:00 appointment three hundred miles away. It has an owner, because an alert that lands in a shared inbox belongs to nobody. And it can be dismissed with a reason, which is how you learn that a third of your alerts are for a receiver who never enforces windows anyway.

Coverage math, and the denominator nobody prints

Ask any platform for tracked-load percentage and you will get a number. Ask how it is computed and the number moves. Loads with any event at all is a generous denominator; carriers who accepted an integration is generous in a different way. The measure that matters is the fraction of loads with at least one position update between pickup and delivery, because that is the set where you can project an arrival. For a mid-market shipper with a long tail of small carriers, that figure commonly lands somewhere in the sixty to eighty-five percent range at the start, and the gap is nearly all in the smallest carriers.

Two things move it. Making tracking a tender condition moves it a lot and costs you capacity in a tight market, so it is a commercial decision rather than a technical one. Connecting through the carrier's telematics provider rather than a driver's phone moves it as well, and holds, because it does not depend on a driver tapping accept on a load he picked up at 3 a.m. Driver-app consent rates are the least durable part of the whole system.

Whatever the number is, print it on the screen. A user who knows the tool sees eight loads in ten will use it for eight loads in ten. A user who thinks it sees everything will lose trust permanently the first time it does not.

Buy the network, build the layer

The visibility networks have spent a decade signing carrier connections. That inventory of relationships is the actual asset and it is not reproducible by an internal team, however good. Anyone proposing to build carrier integrations from scratch across your whole base should be asked how many carriers they intend to onboard and who will chase the ones that go quiet.

What is worth building in-house is everything above the feed. The shipment record and identifier join, because it has to match your order and customer master. The exception logic, because it encodes your commercial rules and no vendor knows which receivers actually enforce windows. The write-back into your order system so a delay updates a promise date. And the measurement layer, so you can tell whether any of it improved on-time performance. That is a real project, usually somewhere in the range of three to six months for a first version that people use daily, and it is the part that turns a subscription into an operating improvement.

When you do not need any of this

If you move thirty loads a week across four carriers, a shared sheet and a fifteen-minute morning call will beat any platform, and it will beat it on cost by two orders of magnitude. The threshold is not really volume; it is whether the number of live shipments exceeds what one attentive person can hold in their head. For most operations that break happens somewhere between one and three hundred loads a week, and it happens sooner if the carrier base is fragmented.

Two other cases genuinely do not need software. If your customers do not ask for status and your receivers do not enforce appointments, visibility buys you very little; fix something that costs money instead. And if your on-time problem is caused by tendering too late rather than by not knowing where trucks are, a tracking system will document the problem beautifully and change nothing. We have told prospective clients both of these and lost the work, which is the correct outcome.

The mistakes we get called in to fix

• State overwritten by whatever event arrived last, producing deliveries that precede pickups
• One geofence radius for every facility, inflating detention on big yards and missing arrivals on small ones
• ETAs republished on every recalculation, so customers watch the promise move all afternoon
• A tracked-load percentage nobody can define, quoted in board slides for two years
• Alerts that fire after the appointment window closed, which is reporting dressed as alerting
• A separate dashboard for a team that already has three screens, abandoned within a quarter
• Identifier matching by a single key with no record of which rule fired or how confident it was
• Local timestamps stored as written, discovered eight months later during a detention dispute

A twelve-week path to something people use

The order matters. Teams that build the screen first spend the back half of the project apologizing for the data underneath it, and the screen is the cheapest part to change once the record beneath it is right.

What to measure after ninety days

• Share of loads with a position update between pickup and delivery, by carrier and by mode
• Median and ninetieth-percentile lag from real-world event to event visible in your system
• Share of arrivals landing inside the window you published four and eight hours out
• Alert lead time: hours between the exception firing and the appointment
• Dismissal reasons, ranked, because the top one is usually a rule that should be deleted
• Calls to carriers per hundred loads, before and after, which is the number the business feels
• Unconfirmed matches as a share of shipments, trending down

Bottom line

Freight visibility is a data-joining and clock-handling problem wearing a map's clothing. Buy the carrier network from someone who already has it; build the shipment record, the exception logic and the write-back yourself, because those encode how your business actually runs. Publish your coverage number where users can see it and hold your promised arrival times still. And if the honest answer for your operation is a spreadsheet and a morning call, that is a good answer and it costs nothing.

Frequently asked questions