When Email Is Your TMS: How “Message-Passing Logistics” Creates Constant Firefighting

If you work in logistics, there’s a good chance your “system” looks like this:

Shipment details in one TMS
Rate confirmations in someone’s inbox
Schedule changes as screenshots
Exceptions buried in a chat thread
A “master” Excel that is never quite up to date

Officially, you have systems.
Practically, your real system of record is email, spreadsheets, and forwarded messages.

That’s what we call message-passing logistics: every update is a new message, and “truth” is whatever was sent most recently to the right group of people.

It kind of works—until something breaks. Then every disruption becomes a fire drill, not because people are bad at their jobs, but because no one can see the same reality at the same time.

In this post, we’ll look at:

What message-passing logistics looks like day to day
Why it guarantees firefighting, even with good teams
What a real system of record looks like in logistics
Practical steps to move away from email-as-TMS
What an event backbone looks like — and what to look for if you’re evaluating one

1. Message-Passing Logistics: What It Looks Like Day to Day

If any of this sounds familiar, you’re in message-passing mode:

Quotes and bookings arrive as free-form emails.
Schedule changes come in as screenshots or PDF attachments.
Local stations update status in their own files and send them upstream.
Customers forward “what the carrier told us” and ask if it’s true.
Finance gets invoice PDFs and hunts for the matching rate email.

For every shipment, there might be:

A line in a TMS
Two or three email threads
A local spreadsheet
A handful of screenshots or chat messages

No single place clearly says: “This is what’s happening right now.”

Symptoms show up quickly:

Three versions of the ETA for the same container
Ops, sales, and finance each working from different information
Multiple people chasing the same update in parallel
Confusion about which spreadsheet, file, or thread is “the latest”

It’s not that people aren’t trying. It’s that the architecture is built on messages, not records.

2. Why Message-Passing Guarantees Firefighting

From an engineering point of view, message-passing logistics is a distributed system with no clear source of truth:

Each person stores their own partial copy of reality (their inbox or spreadsheet).
Every forwarded email or copied file is a new fork of that reality.
Nothing automatically reconciles those copies back into one agreed state.

That leads to three predictable failure modes:

2.1 Inconsistency

Different people are looking at different values for the same shipment:

Ops sees ETA 12 March in the TMS.
Sales has ETA 10 March in a quote attachment.
Customer has ETA 8 March from a carrier email.

When an issue arises, the first task isn’t solving the problem—it’s spending 30 minutes figuring out which value is “real.”

2.2 Staleness

By the time a message is read, it may already be out of date:

A vessel delay is reported in a portal at 09:00.
A screenshot is shared internally at 11:00.
A local spreadsheet is updated at 15:00.
Regional management reviews the spreadsheet next morning.

The information has “moved,” but the world has moved faster.

2.3 Loss

Important information gets buried:

A critical exception note is in the 15th reply of a long thread.
A rate waiver is documented in someone’s personal mailbox.
A customer’s special instruction is in a PDF that never made it into any system.

When something goes wrong, you end up doing forensic work instead of ops work.

Put those together and you get the everyday reality many teams describe:

“We’re not managing the plan; we’re constantly reconstructing what’s actually happening.”

That reconstruction step is the hidden tax that turns every disruption into a fire drill.

3. What a Real System of Record Looks Like in Logistics

You don’t need perfect digital transformation to improve. But you do need one place where “current truth” lives.

A real logistics system of record has a few key characteristics:

3.1 Object-centric

The core objects are things like:

Shipments
B/Ls
Containers
Purchase orders

Each has its own record. Messages and documents are attached to that record, not the other way around.

3.2 Event-based

Status changes are stored as events:

Gate-in
Loaded on vessel
Departed
Arrived
Discharged
Available
Gate-out
Delivered
Returned empty

Each event has a timestamp and source. The sequence of events is the story of the shipment.

3.3 Single identifier

Everyone uses the same ID to talk about the same thing:

B/L or shipment ID is the primary key.
Container numbers and customer references link back to that.

No more one team saying “PO 1234” and another saying “B/L ABCD” as if they’re unrelated.

3.4 Shared access (with permissions)

Ops, sales, and customers can all see status and history from the same underlying data:

Ops sees operational detail and exceptions.
Customers see a simpler view, but based on the same events.
Finance can trace charges back to the underlying shipment record.

That doesn’t mean one giant monolithic system. It means one backbone of events that everything else can read from.

4. Fragmented Visibility vs “Bad Planning”

It’s easy to say “we need to plan better.” It’s more accurate to say:

“We are planning on top of fragmented visibility.”

Some concrete examples:

Sales promises a lead time based on a rate sheet from three months ago, not current performance per lane.
Ops books drayage based on an ETA from yesterday’s export, missing that the vessel slipped 24 hours overnight.
Finance disputes invoices using a rate PDF from someone’s inbox, while procurement has a newer version saved elsewhere.

In each case:

The people are doing what they can with what they see.
The problem is not intent or competence—it’s that everyone sees a different slice of truth.

When you centralise the underlying events and give everyone a way to see them, planning improves without telling anyone to “plan harder.”

5. Design Principles for Getting Out of Message-Passing Mode

Before talking about tools, it helps to agree on a few design principles.

Principle 1: Events, not threads

Status should change via structured events attached to shipments, not via longer and longer email chains.

A delay is an event on a shipment, not a “Re: Re: Re: status?” message.

Principle 2: One current truth per shipment

For any given B/L or container:

There should be one canonical view of the latest status and ETA.
Spreadsheets and reports are views of that truth, not separate sources.

Principle 3: Reference, don’t copy

Emails and chats should:

Link back to the shipment or rate record where the data lives
Avoid copying the entire state into the message itself

That way, when data changes, the link still points to the latest version.

Principle 4: Shared visibility across roles

Different teams can have different interfaces, but they should:

Read from the same underlying events
Use the same definitions (e.g., what “on time” means for a shipment)

Without this, you’re not just splitting visibility—you’re splitting reality.

6. Practical Steps to Move Away from Email-As-TMS

You don’t need a full rebuild to improve. You can make incremental changes that gradually move truth out of inboxes and into systems.

6.1 Decide what must live in the system, not email

Start by drawing a hard line for a few things:

Confirmed routings and bookings
Final rates and surcharges
Official shipment status and ETAs

These should always be recorded in your TMS or visibility platform, not only in email threads.

Emails become:

Notifications about changes
Context and commentary

…but the actual data lives in one place.

6.2 Make the shipment timeline the starting point

For each shipment/B-L:

Make sure there is a clear timeline of events (gate-in, loaded, departed, arrived, etc.).
Make that timeline easy to access for anyone who needs it.

Create a habit:

Before asking “What’s going on with this shipment?”, people check the timeline.
The question “What did the last email say?” becomes less important.

A timeline that earns this role is one that:

Is B/L- or container-based (not buried in a separate spreadsheet)
Is fed automatically by carrier and terminal events, not by manual updates
Can be embedded in your TMS, ERP, or customer portal — so other teams aren’t asked to log into yet another tool

6.3 Reduce parallel spreadsheets for the same shipments

Pick a particularly messy area—like “VIP customer shipments” or “urgent containers.”

Inventory the spreadsheets that track those flows.
Ask: can this be a saved view or report in the system of record instead?

If a spreadsheet is still needed:

Generate it as an export from the system, not as a manually maintained version.
Treat it as a snapshot, not the live source of truth.

6.4 Move status reporting to shared views

Instead of:

Weekly email with an Excel file attached

Try:

Weekly reminder pointing to a shared shipment view or dashboard
Live filters for “late,” “at risk,” or “approaching last free day”

This way:

Stakeholders see the latest data whenever they open it.
No one has to ask, “Is this the newest file?”

6.5 Tackle one interface at a time

You don’t have to fix everything in one go.

Examples of phased improvements:

Internal ops: move internal status updates from spreadsheets to a shared view.
Local ↔ central: standardise how local stations update status into the system rather than via email.
Customer-facing: give strategic customers access to a portal view instead of sending them static files.
Finance: connect rate and invoice data back to shipments in the system, not just to PDF threads.

Each step takes one category of messages and turns them into references to a shared record.

7. What an Event Backbone Looks Like in Practice

The phrase “event backbone” is doing a lot of work in this post. Worth being concrete about what it actually means — and what to look for if you’re evaluating tools that claim to provide one.

An event backbone for ocean logistics is the layer that:

Captures the container and B/L events that most of those forwarded emails and screenshots were trying to communicate in the first place — and exposes them in a consistent shape that other systems can read from.

Concretely, that usually means:

End-to-end container event coverage — gate-in, loaded on vessel, departed, transshipment events, arrived, discharged, available, gate-out, delivered, returned empty.
B/L-centric timelines that unify multiple containers and legs under one shipment record — not a flat list of container events with no parent.
Frequent refreshes from carriers, ports, and other sources — and a consistent event schema across them, so an MSC discharge event and a Hapag-Lloyd discharge event look the same to downstream systems.
APIs and embeddable components so your TMS, ERP, or customer portal can show the same events without forcing users into yet another login.

The right tool category for this is usually called a real-time transportation visibility platform (RTTVP) or an ocean visibility platform. It is not a TMS. It does not replace your TMS. It sits alongside the TMS and feeds it (or your ERP, or your portal) with normalized event data from carriers and terminals.

If you’re evaluating options, a few practical questions worth asking:

Carrier coverage: how many carriers, and is the coverage deep (full event lifecycle) or shallow (just basic milestones)?
Event taxonomy: are events normalized to a standard schema (e.g., DCSA-aligned), or do you get raw carrier-specific event names you have to map yourself?
Integration depth: is the platform truly headless (API-first, embeddable) or is it a UI-only product that creates yet another login for your team?
Update frequency and latency: how often does the platform poll carriers, and what’s the typical lag between a carrier event firing and your team seeing it?

For a fuller evaluation framework, see our walkthrough of how ops teams approach the move from email-as-TMS to a real event backbone — most of the early decisions are about which problems to fix first, not which vendor to pick.

8. Cultural Shifts: From “Forward This” to “Link That”

Tools matter, but habits decide whether they are used.

A few small shifts go a long way:

In email and chat, replace “see below” with “see this shipment link.”
In meetings, when there’s confusion, ask “What does the system say?” first.
When someone pastes a screenshot, gently follow up with the system reference so others can click through.

You won’t change everything overnight. But each time you point back to the system of record, you:

Reduce the importance of message threads as “truth”
Increase trust in the shared data
Make it a bit easier for the next person to do the same

That’s how message-passing logistics slowly becomes record-based logistics, without a big announcement.

Conclusion: Less Hero Mode, More Designed Reliability

Logistics will never be smooth or predictable all the time. There will always be delayed vessels, equipment issues, and last-minute customer changes.

But it doesn’t have to feel like permanent hero mode.

When email is your TMS, every small disruption becomes a big firefight because no one can see the same thing at the same time. The work isn’t just solving problems—it’s rebuilding reality from scattered messages.

Moving toward a real system of record, with shipments and events at the centre, doesn’t remove problems. It changes the work:

From reconstructing what happened to deciding what to do
From arguing over whose spreadsheet is right to acting from the same picture
From individual heroics to designed reliability

If you want to start, you don’t need a grand programme. Pick one flow, one customer, or one type of exception and ask:

Where does truth live for this today—in the system, or in someone’s inbox?
What would it look like if that truth lived in one place, and everything else pointed at it?

Answer that, and you’re already on your way out of message-passing mode.

Leave a ReplyCancel reply

New Report: The Future of SCM, and Why Visibility Alone Is No Longer Enough

[TRADLINX Report] 2026 Shipping Market Outlook: Falling Rates, Rising Risks