Real-Time Freight Visibility: Build, Buy, Or Neither

Somebody's largest customer asked for a tracking link. Not a phone call, not an emailed spreadsheet at 6pm, a link. And the honest answer was that the company knows where about 40 percent of its freight is, most of the time, if the carrier remembered to send a status message.

That conversation is where almost every real time freight visibility project starts. It rarely starts with a technology gap. The satellites work. The trucks have hardware in them, because the FMCSA electronic logging device rule has been fully enforced since 16 December 2019 and a compliant unit already knows where it is. The gap sits between a truck that knows and a shipper who is allowed to ask.

Which means the question in front of you is not which platform to shortlist. It is whether to buy a visibility platform, build the integration layer yourself, or consume a handful of carrier APIs directly and skip the category. All 3 are correct answers for different businesses, and the third one is real even though nobody selling software will tell you so. The rest of this article gives you enough about where the data comes from to work out which one you are, then prices the build.

What real time freight visibility actually means

Strip the marketing off and it is one sentence. You have a shipment record in your own system, and you want a position and a predicted arrival attached to it, refreshed often enough to act on.

Three separate things have to be true. You need a feed that reports position. You need a reliable way to say that this position belongs to that shipment. And you need somebody to convert a raw latitude and longitude into something an operations coordinator can act on before the appointment window closes.

Most projects fund the first, assume the second, and discover the third in week nine.

The distinction that saves money is between an execution system and an aggregation layer. Your transport management system tenders loads, prices them and pays them. A visibility platform such as project44, FourKites, Shippeo or Descartes MacroPoint does none of that. It sits over carrier and telematics feeds, normalises them, and hands back a timeline. Buying one does not replace a TMS, and building one does not either.

The four feeds, and why none of them cover everything

Position data reaches you through four channels, and they behave nothing like each other.

1. Carrier EDI. The ANSI X12 214 transaction, the Transportation Carrier Shipment Status Message, has carried freight status since long before anyone said visibility. It arrives over AS2, SFTP or a value added network, usually in batches rather than continuously. What you get is a status code and a timestamp: AF when the shipment departs pickup, X6 en route, X1 arrived at delivery, D1 completed. It is dependable, it is standardised, and it is not real time in any sense a customer would recognise. A carrier sending 4 status messages a day is meeting its obligation.

2. Telematics. Samsara, Geotab, Motive and Webfleet sit in the tractor and report position on an interval, commonly every 5 to 15 minutes when moving. This is the closest thing to live. The catch is consent: the data belongs to the carrier, not to you, and every carrier has to switch it on for your account individually.

3. Mobile. Driver phone apps fill the gap for small carriers and owner operators who have no fleet telematics contract. Coverage is excellent when the app is open and zero when it is not.

4. Ocean, rail and parcel. Different world again. Vessel positions come from AIS, which SOLAS Chapter V requires on ships of 300 gross tonnage and above on international voyages, so a container's ocean leg is genuinely well covered. Position was never the ocean problem. The gap is the 2 to 5 days of silence at either end while a box sits in a terminal, and the ocean carrier's own 315 status message fills that rather than any satellite. Rail runs on its own EDI set, with the 322 terminal operations message doing much of the work. Parcel is solved and has been for years, which is why parcel-grade expectations keep arriving in truckload requirements documents where they do not belong.

Here is the number nobody puts on a slide. Coverage on a mixed domestic truckload network typically lands somewhere between 60 and 85 percent of loads, and the variable is not technology. It is how many of your carriers have completed onboarding. A shipper using 300 carriers, where 40 move 80 percent of the volume, can reach useful coverage in about 8 weeks by onboarding those 40 and then spend a year on the tail without moving the headline much.

Identity resolution is the hard half

This is the section vendors skip, and it is the one that decides whether the project works.

A telematics feed gives you a vehicle. Your system has a shipment. Nothing in either record links them. The truck does not know your load number and your load record does not know the truck's serial.

The join has to be constructed, and the keys available are all imperfect. The carrier is identified by a SCAC, the Standard Carrier Alpha Code issued by the NMFTA, which is 2 to 4 letters and identifies a company rather than a vehicle. A load tender goes out as an X12 204 and comes back as a 990 acceptance, which establishes who is carrying it but not what is carrying it. Container moves at least have ISO 6346 identification stencilled on the box itself. A pallet-level GS1 SSCC is 18 digits and identifies the freight rather than the vehicle.

In practice the match runs on a combination: carrier SCAC, plus the pickup location geofence, plus a time window around the appointment. A truck belonging to carrier XYZC that enters a 500 metre geofence around your dock between 08:00 and 10:00 on the day a load tendered to XYZC is due out is almost certainly that load. Almost. Two loads to the same carrier from the same dock in the same 2 hour window will resolve wrongly, and the failure is silent.

Geofence radius is its own argument. Set it at 200 metres and a truck parked across the road never triggers arrival, so dwell starts late and your detention evidence is worthless. Set it at 2 kilometres and a truck on the adjacent motorway triggers arrival for a facility it never visited. Most operations settle between 500 and 1,000 metres and then carve out exceptions for the handful of sites where a shared industrial estate makes any radius wrong.

The other thing worth designing early is what happens when the match is uncertain rather than wrong. A confidence score attached to every match, with anything under a set threshold routed to a queue a human clears each morning, costs perhaps 40 hours to build and removes the entire class of silent errors. Systems that emit only a boolean match never surface the 3 to 8 percent of loads that were guesses.

Budget this properly. On our own scoping, a real time tracking capability runs 120 to 240 hours and each carrier or telematics integration runs 60 to 160 hours depending on whether there is a documented API at one end or a reverse engineered file drop at the other. Underneath both sits the carrier and location master that makes any match possible at all, and that line gets forgotten in almost every estimate we are asked to review.

An ETA is a prediction, not a lookup

Operations teams treat the arrival time on the screen as a fact retrieved from somewhere. It is a model output, and it decays.

A prediction 400 miles from the delivery point is a function of distance, speed, hours of service remaining and historical dwell at that facility. Inside 50 miles it is mostly a function of what happens at the gate. The two are not equally trustworthy and showing them in the same font is a design decision with consequences: a coordinator who has been burned by a confident wrong ETA twice stops looking at the screen.

Judge accuracy against the appointment window rather than against the clock. A load predicted for 14:20 that arrives at 14:50 against a 14:00 to 16:00 window is a success. The same 30 minute error against a 30 minute window is a missed appointment, a driver waiting, and detention charges that usually begin after 2 hours of free time.

That is also the honest business case. Visibility does not make freight faster. It buys the 90 minutes of warning in which somebody can move an appointment, reassign a dock door, or tell the customer before the customer tells them.

What the build costs, with the hours shown

Published rates, published hours, and arithmetic you can argue with.

Component	Hours	Note
Feed normalisation layer	200 to 380	Four source types into one shipment timeline
Each carrier or telematics integration	60 to 160	Documented API at the low end, file drop at the high end
Identity resolution and reference data	160 to 300	The match logic plus the carrier and location master
Real time tracking surface	120 to 240	Sockets, presence and the reconnect path
ETA model and confidence display	140 to 260	Starts as a heuristic and earns its way to a model
Customer facing tracking portal	180 to 340	The thing that started the conversation

At our published band of $40 to $100 per hour by role, mixed teams blend to $60 to $70. A first phase covering normalisation, 6 carrier integrations, identity resolution and a customer portal lands near 1,100 to 1,900 hours, so roughly $71,000 to $124,000 at a $65 blend, before a stated 15 to 20 percent contingency. We do not quote firm before discovery, and anyone who does on a first call has either padded it or plans to reprice at change request time.

Buy the aggregator, build the layer, or do neither

Three options, and the third is real.

Buy the aggregator when your carrier base is large, fragmented and mostly North American or European. You are paying for a carrier network somebody else already onboarded, and that network is the actual product. Recreating 200 carrier relationships to save a subscription is a poor trade.

Build the layer when your freight is concentrated in a few carriers you already have commercial weight with, when your operation is in a region the aggregators cover thinly, or when visibility has to sit inside a workflow rather than beside it. Fleets operating in Saudi Arabia already stream to the national WASL platform under TGA rules, which changes the arithmetic there considerably.

Do neither when 5 carriers move 90 percent of your volume and every one of them already publishes a tracking API. Consume those 5 directly, put a normalisation layer in front, and skip the platform entirely. This is more common than the market admits and it is the recommendation nobody selling software will give you.

What goes wrong, and it is rarely the tracking

Six failure modes, all of which we have either hit or inherited.

1] Carrier onboarding scoped as a technical task. It is a commercial project on the carrier's calendar, not yours. Test cycles of 4 to 12 weeks are normal, which is the same shape as retailer EDI onboarding and slips for the same reasons.

2] Coverage measured without a denominator. 85 percent of what? Loads, lanes, or spend? Three different numbers, and the flattering one always ends up in the steering pack.

3] Silent match failures. A load matched to the wrong truck looks exactly like a load matched to the right one. Without a reconciliation report that flags improbable moves, the wrong data is trusted for months.

4] Alert fatigue. Ship a system that emails on every deviation and it will be filtered to a folder inside three weeks. Alert on the exception a human can still act on, not on the event.

5] One ETA number, no confidence. Covered above, and it is the fastest way to lose the operations team.

6] Historical data treated as exhaust. The position history is the asset. It is what lets you compute real dwell by facility, argue detention with evidence, and eventually predict rather than report. Retention of 12 to 24 months costs very little and is close to impossible to recreate later.

7] The portal shipped before the coverage. A customer given a tracking link that works for 2 shipments out of 5 will stop using it and will remember that it did not work. Coverage on the lanes that customer actually ships is the gate, not coverage overall.

The year of history is worth more than the live map

The live view is what gets the project funded. The stored position history is what pays for it afterwards, and almost nobody scopes it deliberately.

Once you hold 12 months of arrivals, departures and gate events, three things become possible that were guesswork before. Real dwell by facility, computed rather than estimated, which turns a detention dispute from an argument into an invoice with evidence attached. A carrier scorecard built on your own observed on-time performance instead of the carrier's self-reported number. And a facility scorecard, which is the uncomfortable one, because it frequently shows that the site blaming carriers for late deliveries is holding trucks for 3 hours at the gate.

That history is also the training data for any ETA model worth the name. A heuristic based on distance and average speed will get you to a usable prediction in a few weeks. Getting materially better than that requires knowing how this lane behaves on a Friday afternoon in this season into this specific dock, and there is no way to know that except to have watched it happen a few hundred times. Plan the storage and the event schema at the start, because retrofitting a clean event history onto 18 months of accumulated position rows is a data migration nobody enjoys.

A ninety day sequence that works

Order matters more than speed here.

Days 1 to 20, reference data. Carrier master with SCACs, location master with geofences, and appointment windows. Nothing tracks correctly until this is right, and it is unglamorous enough that it gets deferred, which is exactly why projects stall in month three.

Days 20 to 45, one feed end to end. Pick the single carrier with the best API and take one lane from tender to proof of delivery. Resist adding a second until the first is genuinely clean.

Days 45 to 70, normalisation and the match. Add 3 to 5 more carriers, build the identity resolution properly, and ship the reconciliation report as a deliverable rather than a nice to have.

Days 70 to 90, the surface. Now build the map, the portal and the alerts. Building this first is the single most common sequencing mistake, because a map with 40 percent coverage on it damages trust faster than no map at all.

The question worth asking before any of it: if the tracking link existed tomorrow, who would act on it, and what would they do differently? If nobody can answer that in a sentence, the project is a dashboard, and dashboards do not survive their first budget review.

Real time freight visibility earns its keep when it changes a decision. Everything else is a map.