How freight tracking and visibility works for forwarders
Tracking is the work a forwarding company does most often and thinks about least. A booking happens once. A quote happens once. The question “where is my cargo?” is asked again and again, by the same customer, about the same shipment, until delivery.
This guide is about that work: where shipment status comes from, what your team has to do with it, what shipment tracking software changes and what it leaves alone, and how to judge a supplier. It is not about looking up a parcel by its number.
Freight tracking for a forwarder is not parcel tracking. Status arrives from many places: carrier portals and APIs, airline and liner milestones, agents, drivers and terminals. The work is turning that into one answer on the customer’s thread, spotting the exception early, and telling the customer before they ask.
What does tracking and visibility mean for a forwarder?
Start with the difference between two things that share a word.
Consumer parcel tracking answers one question for one person. You type a number, you read a status, you close the tab. It is a lookup. The person asking is the person waiting for the goods, and one screen finishes the job.
Forwarder visibility is an operation. You are holding shipments for many customers, on many carriers, in several modes, at the same time. Nobody types a number. Status arrives from a dozen directions, in a dozen shapes, at times you do not control. Your team has to turn all of it into three things. An answer when a customer asks. A warning when something has gone wrong. A message that goes out before the customer notices.
That is why “container tracking software” means something different to a forwarder than to an importer. The importer wants one container found. You want every container watched, and you want to know which one needs a person today.
This guide is about forwarder visibility operations. It is not about looking up a parcel by its tracking number.
Where does shipment status actually come from?
From more places than any one screen shows.
Ocean, air and road each publish status differently, and the parties publishing it do not work for you.
- The Digital Container Shipping Association, a non-profit supported by the ten largest global carriers, puts it bluntly. The ways container data is exchanged today are “antiquated, manual, unaligned and unpredictable”, and “data is often exchanged inconsistently, with delays or not at all”.
- DCSA’s Track and Trace standard gives the industry one vocabulary for the events along a container journey: load and discharge, gate in and gate out, transhipment, pick up and drop off.
- The ONE Record community’s good practice for shipment tracking opens on “the myriad of non-standardized tracking systems, each requiring unique integration and understanding”, which “not only complicates operations but also escalates costs and reduces efficiency”. It maps around thirty standard milestones, from booked through departed and arrived to delivered, published usually by the operating carrier.
- Cargo iQ, an IATA interest group, describes its members as jointly mapping the air freight process in a Master Operating Plan, and generating and sharing one route map containing process indicators and KPIs.
The pairing a forwarder cares about is already in the ONE Record milestones above. Every event carries a code, a time, a place and a flag saying whether that time is actual or planned, and the gap between the two is what is worth watching.
- Every live shipment, every customer, every mode.
- Nothing arrives on your schedule.
Seven publishers, seven shapes, none of them yours.
| Where a status comes from | What it is good for | What it costs you |
|---|---|---|
| Carrier API | Structured events, on the carrier’s schedule | Setup per carrier, your own credentials, different fields from every one |
| Carrier or line portal | Everything shown, including the note an API omits | Somebody has to open it, per carrier, per shipment |
| Airline milestone messages | A common set of checkpoints across airlines | A way to receive them, and something that reads them |
| Terminal and port events | Gate in, gate out, discharge, and why a box is not moving | Local systems, local formats, sometimes a local language |
| Your origin or destination agent | The truth when no system has it yet | An email and a wait. It lives in a person’s head |
| The driver or transporter | The last mile, where the surprises live | A WhatsApp message or a phone call, not a feed |
| The customer | Their own references and their own deadlines | It arrives as the question, not as the status |
- Carrier API
- What it is good for
- Structured events, on the carrier’s schedule
- What it costs you
- Setup per carrier, your own credentials, different fields from every one
- Carrier or line portal
- What it is good for
- Everything shown, including the note an API omits
- What it costs you
- Somebody has to open it, per carrier, per shipment
- Airline milestone messages
- What it is good for
- A common set of checkpoints across airlines
- What it costs you
- A way to receive them, and something that reads them
- Terminal and port events
- What it is good for
- Gate in, gate out, discharge, and why a box is not moving
- What it costs you
- Local systems, local formats, sometimes a local language
- Your origin or destination agent
- What it is good for
- The truth when no system has it yet
- What it costs you
- An email and a wait. It lives in a person’s head
- The driver or transporter
- What it is good for
- The last mile, where the surprises live
- What it costs you
- A WhatsApp message or a phone call, not a feed
- The customer
- What it is good for
- Their own references and their own deadlines
- What it costs you
- It arrives as the question, not as the status
Two things follow. No single feed is complete, so a product that reads only carrier APIs still leaves your team opening portals and emailing agents. And the most valuable status on a bad day came from a person, which no standard covers.
What does the forwarder actually have to do with the status?
Three jobs. They are different jobs, and most teams only staff the first one.
1. Answer “where is my cargo?”
The customer asks on a thread they already have open, often with no booking number and a subject line from three weeks ago. Somebody has to work out which shipment they mean, find the current status, decide what is safe to say, and write it in a sentence the customer can use. A small task, done many times a day. It is also the one that pulls a coordinator out of everything else.
2. Spot the exception
Most shipments need no attention at all. A few need it today. The skill is separating them. The box that did not load. The flight that went without the cargo. The container held at a terminal for a missing document. The truck that has not moved since yesterday. Each one is visible in the status if somebody looks. Nobody has time to look at all of them.
3. Tell the customer before they ask
This is the job that pays. A delay you announce is a service. A delay the customer discovers is a complaint. The difference is not whether the cargo was late. It is whether your message arrived first.
Notice what the three jobs have in common. None of them is “look at a map”. They are all writing: an answer, a warning, an update. Which is why a dashboard so often changes nothing. It shows your team where the cargo is. They mostly knew. What they did not have was the twenty minutes to tell everybody.
Why does the estimated arrival keep moving?
Because the plan behind it moves.
Sea-Intelligence, which publishes the Global Liner Performance report, put global container schedule reliability at 56.4% in July 2026. That was the lowest level of the year, down 6.1 percentage points on June and 8.8 points on July 2025. For the vessels that did arrive late, the average delay was 6.06 days.
Read those two numbers together. Close to half of container sailings did not arrive when scheduled, and the ones that missed missed by most of a week. That is an ocean measure and does not transfer to air or road, but the shape is familiar in every mode. An arrival date is a forecast, and forecasts move.
So an arrival date is not a fact you publish once. It changes several times per shipment, and every change is a message somebody owes a customer. If your process only sends an update at booking and at delivery, each change in between becomes a phone call you take instead of a message you sent.
It also means the honest answer is often “here is what the carrier is showing today, and here is when I will check again”. Customers accept that. What they do not accept is silence followed by a surprise.
What does shipment tracking software do, and what does it not do?
Be precise about this boundary. It is where budgets are wasted.
What a visibility product genuinely changes:
- it collects status from several carriers into one place, so nobody opens six portals;
- it turns different vocabularies into one set of milestones you can compare;
- it keeps a history, so you can see when a status changed and what it changed from;
- it raises an alert when a milestone is late or has not arrived at all; and
- it gives pricing, operations and accounts the same view of the same shipment.
What it does not change on its own:
- it does not know which of your customers cares about which shipment;
- it does not write the reply, so the answer still costs a person their attention;
- it does not chase the agent whose email is the only source of a status;
- it does not decide what is safe to promise a customer who is already unhappy; and
- it does not make the cargo move.
That second list is why so many forwarders buy visibility and still have a coordinator answering the same question all afternoon. The status arrived. The work after it did not.
So the useful question is not “how many carriers do you read”. It is “what happens in the ten minutes after the status changes”. Ask a supplier to walk through that on a shipment that went wrong.
- 01Status landsAn event arrives, or a portal quietly changes.
- 02MatchedTied to your job, customer and reference.
- 03ReadNormal today, or the one needing attention?
- 04DraftedThe answer, on the customer’s own thread.
- GATEApprovedA person decides what is safe to promise.
- 06SentThe update goes out before the customer asks.
- 07WatchedThe next milestone is due. Absence is a signal.
How should you evaluate freight visibility software?
Ask every supplier the same questions. Score the answers on evidence, not on the demonstration.
| What you are testing | The question to ask | What a good answer looks like |
|---|---|---|
| Coverage you actually need | Can you read status for the carriers in our last fifty shipments? | A per-carrier answer naming the method, including the portal-read ones |
| Modes | How does this behave for air, ocean and road, and for a leg with no feed? | An honest answer for each. Road is usually the weak one |
| Matching | How does a status find its way to our job and our customer? | A named key, plus what happens when the carrier’s reference does not match ours |
| Where the work happens | Does your team still have to open the mailbox to answer “where is my cargo?” | The reply is drafted and assigned before anyone opens the email |
| What runs by itself | Which checks, chasers and customer updates happen without a person remembering? | A list you can watch run for a week, including the quiet days |
| Exceptions | Show us a shipment that went wrong last month and what the product did | One named shipment, one alert, and the person it reached |
| Silence | What happens when a carrier stops publishing status for three days? | The gap is itself an alert, not an empty field |
| The agent-shaped hole | Half our status comes from an agent’s email. What happens to that? | Read the email, ask for the update, record it against the shipment |
| The customer’s words | Can it answer on the customer’s own thread, in our sentence, not a portal link? | A drafted reply on the original conversation |
| Corrections | What happens when a carrier revises an event we have already passed on? | Both versions kept, and everyone told the old one is identified |
| Ownership | Whose credentials are used, and what happens to the history if we leave? | Our own carrier accounts, and an export we can take |
| Proof | Which of these can you demonstrate on our shipments, not on yours? | A run on live references, watched by the people who will use it |
- Coverage you actually need
- The question to ask
- Can you read status for the carriers in our last fifty shipments?
- What a good answer looks like
- A per-carrier answer naming the method, including the portal-read ones
- Modes
- The question to ask
- How does this behave for air, ocean and road, and for a leg with no feed?
- What a good answer looks like
- An honest answer for each. Road is usually the weak one
- Matching
- The question to ask
- How does a status find its way to our job and our customer?
- What a good answer looks like
- A named key, plus what happens when the carrier’s reference does not match ours
- Where the work happens
- The question to ask
- Does your team still have to open the mailbox to answer “where is my cargo?”
- What a good answer looks like
- The reply is drafted and assigned before anyone opens the email
- What runs by itself
- The question to ask
- Which checks, chasers and customer updates happen without a person remembering?
- What a good answer looks like
- A list you can watch run for a week, including the quiet days
- Exceptions
- The question to ask
- Show us a shipment that went wrong last month and what the product did
- What a good answer looks like
- One named shipment, one alert, and the person it reached
- Silence
- The question to ask
- What happens when a carrier stops publishing status for three days?
- What a good answer looks like
- The gap is itself an alert, not an empty field
- The agent-shaped hole
- The question to ask
- Half our status comes from an agent’s email. What happens to that?
- What a good answer looks like
- Read the email, ask for the update, record it against the shipment
- The customer’s words
- The question to ask
- Can it answer on the customer’s own thread, in our sentence, not a portal link?
- What a good answer looks like
- A drafted reply on the original conversation
- Corrections
- The question to ask
- What happens when a carrier revises an event we have already passed on?
- What a good answer looks like
- Both versions kept, and everyone told the old one is identified
- Ownership
- The question to ask
- Whose credentials are used, and what happens to the history if we leave?
- What a good answer looks like
- Our own carrier accounts, and an export we can take
- Proof
- The question to ask
- Which of these can you demonstrate on our shipments, not on yours?
- What a good answer looks like
- A run on live references, watched by the people who will use it
Two rows there are worth more than the rest. “Does your team still have to open the mailbox?” and “What runs by itself?” separate a screen from an operation. A product can pass every coverage question and still hand your team the same afternoon.
One example, so the two questions are not abstract. FreighAI answers them like this. Answers “where is my cargo?” on the customer’s own thread, from carrier status, for approval. Chasing, tracking checks, quote expiry and follow-ups run on their own. Nobody has to remember. Whether that shape suits your operation is your decision. Both questions have a concrete answer, and a supplier who cannot give one is selling a screen.
What should you bring to a tracking evaluation?
Bring the week you actually had, not the one you would like to show.
- your last fifty shipments, with the carriers and modes as they were;
- one tracking thread where the customer had to ask three times;
- one shipment that went wrong, with the emails around it;
- one shipment whose only status all week came from an agent;
- the customers who expect an update without asking;
- the reference your job carries and the one the carrier carries, side by side; and
- the hours a week your team spends answering “where is my cargo?”.
The last item is the one most forwarders have never measured. Count it for one week before any demonstration. Without it you cannot tell whether anything improved, and every supplier sounds convincing.
Common questions
Is freight tracking the same as parcel tracking?
No. Parcel tracking is a lookup by one person for one shipment. Forwarder tracking is an operation across every live shipment at once, on carriers and modes that publish status differently. The output is not a screen. It is an answer, a warning and an update a customer receives.
Do we need a visibility product if our carriers already have portals?
Portals are complete and slow. They answer one shipment at a time, and only when somebody opens them. Ask how many portals your team opens in a day, and what happens to a shipment nobody opened. If the answer is “nothing until the customer calls”, the portals are not enough.
What about the legs where there is no feed at all?
Most forwarders have them: a road leg, a small airline, an agent’s own movement. Ask every supplier what the product does when there is no data. A good answer describes asking a person and recording their reply against the shipment. A weak answer is an empty field.
How often should a shipment be checked?
Tie the frequency to the next expected milestone rather than to the clock. A container three weeks from arrival does not need the attention of one being discharged tomorrow. Ask a supplier how their checking schedule works, whether it tightens as a milestone approaches, and what happens when an expected event does not arrive.
Should we give customers a portal login instead of answering them?
A portal helps the customers who will use it, and many will not. It also moves the work rather than removing it, because the customer who cannot find the answer emails anyway. Treat a portal as an addition to the reply, never a substitute for it.
How do we measure whether visibility improved?
Three numbers, counted before and after. The hours a week spent answering where-is-my-cargo. The share of delays your team told the customer about first. The exceptions found on the day they happened, not the day the customer noticed. Coverage percentages are a supplier’s measure, not yours.
- DCSA — Track & Trace standard (the container event vocabulary)verified 2026-09-03
- DCSA — Standards overview (open, vendor-neutral frameworks)verified 2026-09-03
- DCSA — About us (who DCSA is and who supports it)verified 2026-09-03
- ONE Record good practice — shipment tracking (milestones, actual versus planned)verified 2026-09-03
- Cargo iQ — the IATA interest group for air cargo performance standardsverified 2026-09-03
- Cargo iQ — Our projects (the Master Operating Plan and the route map)verified 2026-09-03
- Sea-Intelligence — July Global Schedule Reliability Drops to Lowest 2026 Levelverified 2026-09-03
Bring one tracking thread from last week
Pick the shipment your team answered on three times. Send the thread and whatever the carrier was showing at the time. We will go through where each status came from, which arrived too late to be useful, and what a drafted reply would have said.