Tracking inbound shipments: a control tower for everything in transit from your suppliers

Short answer. You only truly see what is in transit from your suppliers once you bring every track-and-trace code from emails and portals together in one place, enrich it with the carrier status, and link it to the customer order waiting on that package. That overview is called a control tower for inbound flows, and with just-in-time purchasing it is the difference between delivering on time and a cancelled sale.

I spent years buying cross-border from dozens of suppliers at once and selling through my own webshop, bol, and Amazon. The pain was never in the selling. The pain was in the question I asked myself every morning and could not answer: what is actually in transit right now, and will it reach the customer on time?

Why you never know what is in transit

The information is there. It is just scattered everywhere. One supplier sends a tracking code by email, another puts it in a portal where you have to log in again every time, and a third sends nothing at all until the package is already at the door. The carriers differ too: PostNL, DPD, DHL, GLS, and on imports an Asian carrier whose code is not recognised until three days in.

The result is that having an overview becomes a manual chore. You open inboxes, you paste codes into track-and-trace sites, and you keep it in your head or in a list that is already out of date the moment you save it. It works as long as you have ten orders. At a hundred, it grinds to a halt.

What a control tower for inbound flows does

A control tower is a single screen that does the four things you now do by hand, but automatically and continuously.

Aggregating tracking across carriers. Every code lands in one place, regardless of where it came in or which carrier handles it. Services like Parcel Monitor and 17TRACK already show what that looks like for the consumer: connect your inbox and the codes are pulled out automatically. For an operation you want that as a data source, not as a standalone dashboard.

Estimating arrival times. Not just "in transit", but an expected arrival date per package, so you know whether it fits within the promise you made the customer.

Flagging delays. The system raises the alarm the moment a shipment stalls or misses a planned date, instead of you finding out when the customer emails.

Matching to the outbound customer order. This is the part no track-and-trace app does for you, and exactly the part that counts. The inbound package is linked to the order waiting on it, so you see at a glance which customer you hit if this delivery is delayed.

The three steps: goal, scrutiny, then build

Before I build anything at all, I work through three steps. That order is deliberate.

The goal is not time savings in itself. The goal is control. Numbers that add up, an overview you can rely on in the morning, and less manual work as a result of that, not as an end in itself.

Then I scrutinise the process. Many resellers have steps that once made sense and are now redundant. A supplier you have not used in a year and yet still sit in your tracking routine. A double check a tool already does. Sometimes the smartest thing you can do is to cut a step, not automate it. And I say so when that is the case.

Only then comes the build. And that is where the real trade-off sits: off-the-shelf package or custom build.

Why an off-the-shelf package often falls short here

For the outbound side there is plenty of good software. Sendcloud and MyParcel handle your shipping labels and customer tracking excellently, and stock and order tools like Picqer and ChannelDock keep your warehouse in order. I happily use those where they fit.

The problem is the inbound side. An off-the-shelf package covers the happy path: one type of supplier, tidy tracking, predictable carriers. Your reality is the exception. The supplier without an API. The code that comes in over WhatsApp. The import that has to clear customs and can sit there for days. And above all: the link between that one inbound package and that one customer order waiting on it, including the right cost allocation.

That is build-versus-buy in one sentence. Buy what covers the happy path, build what covers your exceptions and your cost allocation. The moat is not in the off-the-shelf package anyone can buy. The moat is in the system that orders your specific mess.

How I build this in practice

In concrete terms this usually means a combination. A scraper or inbox connection that pulls tracking codes out of emails and portals automatically. A layer that enriches those codes through a multi-carrier tracking API like TrackingMore. A database that links every inbound package to the open customer order. And a dashboard that only shows what needs action: delayed, nearly too late, or blocked.

The result is that the question "what is in transit from my suppliers" is no longer a morning ritual, but a screen that is always current. With just-in-time purchasing, where your margin depends on low stock and fast turnover, that is not a luxury. It is the difference between keeping the sale and watching it cancel.