Solution
Port Terminal & Container Tracking Automation
Freight forwarders check the same terminal portals every morning: has it discharged, is there a customs hold, has the pin been released. Multiply that by a few hundred containers and it becomes somebody's entire job. This is the workflow our studio project automates end to end.
The morning portal round
A container moving through Rotterdam touches several systems that do not talk to each other. The terminal knows the discharge status. Customs knows whether there is a hold. The carrier knows the release pin. Your ERP knows the booking, and none of them know about the others.
So an operator opens each portal in turn, searches for the container, reads the status, and types it into a spreadsheet. Then does it again tomorrow, because the answer changes. The work is not difficult, but it is unbounded — it scales linearly with volume and produces nothing except an up-to-date spreadsheet.
The cost is not only the hours. It is that a status which changed at 06:00 is not noticed until someone works down to that row, and by then a truck may already have been dispatched against stale information.
What the engine tracks
The tracking engine logs into the relevant terminal and carrier portals on a schedule, looks up every container on your active list, and writes the current state into one place.
- Discharge status and timestamp
- Whether the box is still on the vessel, discharged to the stack, or gated out — with the time it changed, so you can measure dwell rather than guess at it.
- Customs holds
- The status that most often stops a collection. Surfaced the moment it appears rather than when a driver is turned away at the gate.
- Pin and release status
- Whether the release pin has been issued, so transport is only booked against containers that can actually be collected.
- ETA changes
- Vessel schedules move. A changed arrival that is picked up automatically is a planning adjustment; one that is noticed late is a wasted slot.
- Demurrage and detention clocks
- Free time runs from discharge. Knowing exactly when it started, per container, is what makes the charges avoidable rather than merely explicable.
Terminals and carriers
The engine was built against the Rotterdam terminals first — ECT Delta, RWG, and APM Terminals — because that is where the original workflow lived. The pattern generalises: each portal is a login, a search, and a status page, and adding another is a bounded piece of work rather than a new architecture.
Carrier portals follow the same shape for release pins and booking status. Where a carrier offers a real API, we use it — it is more stable than any scraper and there is no reason to automate a browser against a system that will simply answer a request.
If your operation runs through Antwerp, Hamburg, or elsewhere, the same approach applies. The specific terminals are a configuration question, not a redesign.
Delivered where your team already works
The output goes into whatever your operators already have open. For most forwarders that is Excel — a sheet that refreshes itself instead of being retyped, with the same columns the team already recognises.
For teams with an internal system or TMS, the engine writes directly into it, so container status appears next to the booking without anyone opening a portal at all. Where the system has no API, the same portal automation approach works in the other direction.
Alerts cover the changes that need a decision: a customs hold appearing, a pin being released, free time about to expire. Those go to the channel your team already watches, so the exceptions find people rather than waiting to be discovered.
An incubated studio project
This began as an internal project to prove out the pattern on a workflow we could see clearly, and it remains the most developed example of what the studio builds. It is not a product with a price list — it is a working system we adapt to the terminals, carriers, and back-office each forwarder actually uses.
If your operation looks like this, the fastest way to find out whether it fits is to send us one container and the portals you check for it. That is enough to demonstrate the whole loop.
Common questions
Frequently asked
Which terminals do you support?
The engine was built against ECT Delta Rotterdam, RWG, and APM Terminals. Adding a terminal is a bounded piece of work rather than a rebuild, so other ports are a matter of configuration and a connector, not a new project.
How often does the tracking refresh?
Typically several times a day, timed around when statuses actually change rather than polling constantly. The right interval depends on the portal's tolerance and how quickly your operation needs to react — hourly is achievable where it is warranted.
Do we need to replace our existing system?
No. The engine feeds whatever you already use. For most forwarders that means an Excel sheet that updates itself; for teams with a TMS or internal system, it writes directly into that. Nothing about how your team works has to change.
Can it help us avoid demurrage charges?
It gives you the information in time to act — free time starting, the clock running, the deadline approaching — surfaced as an alert rather than discovered on an invoice. Whether a charge is avoidable still depends on your operation, but you stop losing to ones nobody saw coming.
Is our container and customer data kept private?
Yes. The engine runs against your own portal accounts and writes only into your systems. Nothing is pooled across clients and nothing is shared with third parties.
Have a workflow like this to automate?
Send us the portal, the document, or the spreadsheet you are tired of filling in by hand. We will tell you within a day whether it is automatable — and what it takes.