Before we jump into this, I want to give you some context on why we wrote this. As a technology consulting business, we understand that every logistics business is different. This is the story of how we brought decades of technology experience in Data and AI to the port logistics industry.
One of our clients, a bulk and breakbulk terminal operator running 24 terminals across five regions, came to us with what looked like a labor problem: their productivity numbers never matched what the terminal superintendents were seeing in real time. Within four months, we replaced three disconnected reporting systems with one integrated analytics layer, without stopping a single shift from doing it.
What Does Terminal Visibility Actually Mean in Day-to-Day Operations?
As a technology consulting company, this was one of the first questions we had to ask our client because everyone answered it differently. What we found out led us down this rabbit hole.
Ask five people at a terminal what "visibility" means, and you'll get five different answers, and all five will be partially right:
| Role | What "Visibility" Means to Them |
|---|---|
| Superintendent | Knowing right now whether a gang is on pace. |
| Planner | Knowing what cargo is sitting in the yard. |
| Finance | Knowing what a shift costs, not what it was budgeted to cost. |
| Customer | Knowing when their cargo will move and why they got charged extra for a job. |
The reason visibility was hard for our client wasn't a lack of data. They were drowning in it.
The problem was that none of it was connected properly. A gang's hours lived in one system, the tonnage they moved lived on paper, and the two were rarely compared on the same day. This is what we realized we were dealing with before we were asked to fix the reporting that sat on top of it.
Why Do Terminals Still Run Vessel Operations on Spreadsheets?
Spreadsheets survive at terminals for the same reason they survive everywhere else: they're flexible, and nobody has to ask permission to build one. A superintendent needs a way to track tonnage by commodity for a bulk vessel; IT doesn't have a system that does it cleanly, and by Thursday, there's a workbook.
Building the real system always looked more expensive than the workbook, right up until the gap between reported and actual performance started costing real money.
Many terminals meant, in practice, different versions of the same tracking problem, none of them talking to each other.
We learned this the hard way, terminal by terminal. Understanding how deep the spreadsheet dependency ran wasn't easy, and replacing it was even harder, but the reason we shared this story is because we built the experience to handle it.
How many versions of the same tracking problem do you have?
We'll help you find out how many workbooks are quietly disagreeing with each other.
What Does "Integrate Data" Mean When Operations, Labor, and Cargo Data Sit in Separate Systems?
Initially we weren't sure why the client's three systems kept producing different productivity numbers for the same shift, but the more we traced it, the more we understood where the disagreement started. "Integrated" gets used loosely enough that it's worth being precise about what it requires. It doesn't mean one company built every system or that one screen shows everything.
It means the systems agree on what a vessel's call is, what a shift is, and what a unit of cargo is, and every record ties back to those same identifiers.
Without that agreement, integration is just export and import. Someone pulls out a labor report, someone else pulls a tonnage report, and a third person matches them by vessel name and date, hoping the spelling is consistent across both.
That's not an integration. That's translation, done by hand, on a schedule that guarantees it happens after the numbers are already needed.
Which Performance Metrics Tell You Whether a Terminal Is Actually Productive?
Productivity gets reduced tons per hour more often than it should, and that single number hides more than it reveals. A terminal can post a strong ton-per-hour figure on a shift that ran over budget on labor or one that only looked productive because a delay got logged incorrectly. When discussing this with the operations and finance departments of the business, this is where we found the real value in getting the metrics right.
| Metric | What It Measures |
|---|---|
| Berth productivity | Tonnage moved per hour of berth occupancy, reflecting the vessel's total time cost, not just the hours worked. |
| Gang productivity | Output per labor hour, broken out by commodity and equipment, since a bulk gang and a breakbulk gang aren't comparable on a single line. |
| Delay ratio | Time lost to delay as a share of total shift time, with a cause attached rather than left blank. |
| Guarantee exposure | Hours paid against hours actually worked, which shows where labor cost is going even when tonnage looks fine. |
| Turnaround time | Total vessel time in port against plan, usually the number the customer cares about most. |
No single figure here means much on its own. The value is in looking at all five together, for the same vessel call, pulled from the same underlying record.
How Should Activity and Delay Data Be Structured So It Rolls Up Cleanly?
The rollup fails when the raw data was never built to support one. If delay causes are typed freely, two clerks describing the identical problem produce two different strings of text, and a report totaling "crane mechanical delay" across a month will quietly miss half of them.
Four Requirements for a Clean Rollup
- A fixed, hierarchical cause list. Top-level categories like equipment, weather, or labor, with specific sub-causes underneath, so a report can total at whatever level of detail it needs.
- Every activity record is tied to a vessel call, shift, and gang, not just a date, so it rolls up correctly no matter which dimension someone reports on.
- Consistent units at the point of entry, not converted later, which is where rounding errors quietly creep in.
- A closed record after the shift, with an auditable correction process, so a rollup run today matches the same rollup run in six months.
Why Do Scale Tonnage and Survey Tonnage Disagree, and What Should a System Do About It?
This is one of the most persistent arguments in bulk terminal operations, and it's rarely anyone's fault. Both are legitimate measurements of different things, taken at different points, with different sources of error.
| Measurement | How It's Derived |
|---|---|
| Scale tonnage | Weighing cargo as it moves, truck by truck, or belt scale reading by reading. |
| Survey tonnage | Measuring the vessel's draft before and after loading and calculating weight from displacement. |
A small disagreement between scale and survey tonnage is normal. What a system should do is stop treating that gap as an error to hide and start treating it as a data point worth tracking, recording both figures against the same vessel call and flagging the variance rather than silently picking one number.
Forcing them to match erases the signal that would otherwise tell you when something is genuinely wrong: a miscalibrated scale, a bad draft reading, or actual cargo loss.
How Do You Track Cargo Inventory by Location with a Historical Value?
Tracking where cargo sits right now is the easy half of this question. The harder half is answering where it sat and how much of it, at any point in the past, which is exactly what finance, customers, and auditors ask for when a dispute comes up.
That requires treating inventory as a series of dated events rather than a single running total.
When it is received, relocated, shipped, blended, or adjusted, it is important to track:
Current inventory is then just the sum of events up to now, and inventory as of any past date is the same calculation run against an earlier cutoff.
Can an Off-the-Shelf Terminal Operating System Deliver This for Bulk and Breakbulk?
Mostly, not without real customization. Most terminal operating systems on the market were built on containers first, where cargo is discrete, uniquely identified, and easy to track unit by unit. Bulk and breakbulk cargo doesn't behave that way; tonnage is continuous, commodities blend, and a single vessel call can involve multiple grades of the same product moving into the same stockpile.
Off-the-shelf systems generally handle vessel scheduling and berth planning well, because that part of the problem looks similar across cargo types. Where they fall short is everything this piece has covered flexible tonnage reconciliation, commodity-specific activity structures, and inventory tracked as a historical ledger rather than a snapshot.
For our client, the right answer wasn't replacing the terminal operating system. It was building the analytics layer that system was never designed to provide and connect the two.
What Does It Take to Build an Integrated Analytics Layer Without Stopping Operations?
Once you know that the paper documents, Excel workbooks, and the new system you build reconcile, you know you've done it right. That's when you can focus on actual reporting. Ensuring that the data from your application is feeding a data warehouse and is documented properly is a part of the challenge.
The reason we share our experience is that we can give other clients the confidence that we know what we are doing. If you've gotten this far, I urge you to reach out to us and discuss what exactly you are looking for. We are a boutique consulting firm that focuses on port logistics. Reach out to us at Saranga@beetlerim.com or through our website at www.beetlerim.com.
Back to all articles