When I started learning how freight forwarding operations actually work, one detail caught me off guard.
Tracking vessel departures can be someone's entire day job.
Opening shipping line portals. Checking whether a vessel actually departed. Comparing dates and vessel movements against other sources because a single source doesn't always tell the whole story.
My first reaction was surprise.
My second was probably predictable for someone building an AI company: could we automate this?
But the more I thought about it, the more I realized that checking whether a vessel departed is only part of the problem.
The more interesting question is what happens after you find out.
The shipment has a status. So does the work.
Consider a hypothetical import file, IMP-24809.
The vessel has departed. The ETA is recorded. The shipment is marked In Transit.
From a shipment-tracking perspective, everything looks fine.
But the origin agent still hasn't sent a required certificate of origin. Someone requested it last week. There has been no response, and no one is entirely sure whether another follow-up was sent.
The shipment is moving. The work around it isn't.
Both things can be true at the same time.
A TMS is designed to maintain records, milestones, documents, and the information needed to manage shipments. Some platforms also provide task management and exception-handling capabilities.
But having shipment information in a system doesn't necessarily mean that every outstanding piece of work is being tracked.
What is this file waiting for?
Who is responsible for following up?
When was the last time someone checked?
And what should happen if the expected response doesn't arrive?
These questions describe a different kind of status.
Not the status of the shipment, but the status of the work.
The information exists. Someone still has to act on it.
Let's go back to vessel tracking.
A departure date changes. The updated information appears in a shipping line's portal, or perhaps an overseas agent sends an email.
Now imagine that ten import files are affected.
Identifying the change is one task.
Understanding which shipments are affected is another.
The team may then need to verify the new schedule, update shipment records, notify customers, and check whether the change affects other activities.
The exact steps depend on the company and the shipment.
But the distinction matters: detecting an event and dealing with its consequences are not the same job.
The same thing happens with documents.
An overseas agent sends an invoice and packing list, but the required telex release hasn't arrived.
Someone needs to recognize what's missing, determine whether it is already being handled, follow up with the right party, and make sure the issue is resolved before it delays the next step.
If the reply arrives tomorrow, someone must connect it to the original request.
If it doesn't arrive, someone needs to notice.
These are small pieces of work. Individually, none sounds particularly complicated.
Across hundreds of active files, they become a substantial part of the operation.
The problem isn't necessarily the TMS.
It's tempting to look at these examples and conclude that freight software hasn't kept up.
I don't think that's a particularly useful conclusion.
A TMS can do exactly what it was designed to do and still leave part of the operational workload outside its records.
An email application stores the conversation. A carrier portal provides shipment information. A TMS maintains the shipment record.
Each system has a purpose.
The difficulty appears when work moves between them.
A request is sent by email, but the expected reply is not necessarily represented as an outstanding task.
A schedule changes, but somebody still has to connect that change to the relevant files.
A missing document is known to one operator, but another person covering the desk may not know its history.
Of course, some companies have already built effective processes around these situations. They use task queues, exception reports, reminders, and carefully maintained procedures.
Others rely more heavily on experienced employees who know what needs attention.
The important question isn't whether a particular software feature exists.
It's whether the operation can reliably answer what each active file is waiting for, without having to reconstruct the answer from several different places.
What does it actually mean to track the work?
I find it useful to think about four possible states.
Moving: Someone is actively working on the next step.
Waiting on an external party: The next action depends on an agent, carrier, customer, or another organization.
Waiting on us: The information has arrived, but something still needs to be handled internally.
Needs a decision: The next step requires someone to review an exception or make a judgment.
These aren't meant to replace shipment milestones. They describe something different.
A shipment can be In Transit while its documentation is Waiting on an external party.
A document can be received while the associated work is still Waiting on us.
And a file can have all its documents while an unresolved discrepancy means it Needs a decision.
For each outstanding piece of work, I think five questions matter:
- What exactly are we waiting for?
- Who owns the next action?
- How long has it been waiting?
- What event should move the process forward?
- What happens if that event doesn't occur?
None of these questions requires artificial intelligence.
They require the work to be defined clearly enough that somebody — or eventually something — can take responsibility for it.
Before automating the work, understand what people are keeping track of.
This is becoming one of the more important lessons for me while building ONWARD.
When I hear about someone spending most of their day tracking vessels, my instinct is to think about automation.
Could software check the relevant sources? Could it identify schedule changes? Could it connect those changes to affected shipments?
Possibly. Those are concrete problems worth exploring.
But removing the manual lookup would not automatically solve everything that happens afterward.
Someone still needs to know what the change means, which actions are required, and whether those actions were completed.
Otherwise, we've automated one step and left the rest of the work exactly where it was.
And that applies well beyond vessel tracking.
The real opportunity may not be in making each individual check faster. It may be in connecting incoming information to the work that needs to happen next, and making sure that work doesn't disappear between systems, inboxes, and people.
That is a harder problem than reading a document or detecting a changed ETA.
It is also a more interesting one.
A simple test
Pick three active shipment files that haven't progressed as expected.
For each one, ask:
What exactly is this file waiting for?
Who is responsible for the next step?
And how quickly can we find that information?
If the answers are immediately available, that's a useful sign that the process is visible and under control.
If finding them requires opening several emails, checking different systems, and asking the person who usually handles the file, that tells you something too.
Not necessarily that your software is inadequate.
But that part of the operation still lives outside the information your systems readily provide.
And before trying to automate that work, it might be worth making it visible.
We're writing about these questions as we build ONWARD. If your desk solves them differently, we'd genuinely like to hear how.