Choosing a terminal operating system (TOS) shapes how a terminal runs its daily operations and prepares for future growth. At multipurpose terminals, where different cargo types share berths, equipment and gate capacity, the consequences of that choice extend across the entire operation.
Feature checklists provide a useful starting point. A sound decision, however, depends on understanding how those features work together under the terminal’s actual operating conditions.
1. Start with the terminal, not the product
A TOS selection process should begin with the way the terminal works. Tracking containers by unit and TEU, bulk cargo by tonnage, and general cargo by package and weight creates different requirements. Shared resources also require coordinated planning, so the specification must capture these relationships alongside cargo types, operational exceptions and future plans.
We have defined the requirements. How can we tell whether the shortlisted systems can actually meet them?
2. A feature checklist tells only part of the story
Two systems may both mark a function as “supported” without offering the same depth of capability. Yard planning, for example, may not account for the storage requirements of different cargo types and the constraints of shared equipment. The assessment must consider how the function behaves in operation, as well as whether it exists.
Those differences are hard to see in a comparison table. They need to be tested through real scenarios.
3. Real scenarios reveal real capability
Ask suppliers to demonstrate the terminal’s own vessel, yard, gate, weighing and commercial workflows from start to finish. Include exceptions, such as how a change to a vessel plan affects shared equipment and yard allocations. Distinguish clearly between functionality available in the standard product, development included in the proposed project, and capabilities that exist only on the roadmap.
We have seen what the system can do. How much should change to make it fit the terminal?
4. Not every difference calls for custom development
Forcing every process into a rigid standard product can be as problematic as turning every existing habit into a custom development requirement. Separate needs that can be met through configuration from those requiring new code. Support differences that create operational value while preserving the ability to maintain and upgrade the product.
Fitting the terminal is only part of the task. The TOS also needs to work with the systems around it.
5. Integration is more than having an API
A TOS exchanges data with ERP and customs systems, electronic data interchange (EDI) platforms, gate automation, weighbridges, equipment and customer portals. An API alone does not establish that the required workflows are supported. Assess whether failed or incomplete transfers can be traced and whether integrations will remain maintainable through product updates.
The systems can work together. Can the people on the ground work comfortably with them?
6. Success depends on everyday use
A technically capable TOS cannot deliver its expected value if routine tasks are slow or difficult to complete. Experienced users should take part in the selection process and try frequently repeated tasks at the gate, weighbridge or on handheld devices. Their involvement should help build a better way of working, rather than simply reproduce existing habits.
Meeting today’s user needs matters. Will the same approach still work as the terminal grows?
7. Plan for growth and change
Volumes may increase, new cargo types may be introduced, additional areas may open, and automation may expand. The existing TOS should be capable of supporting planned growth without requiring wholesale replacement. Assess the additional modules, infrastructure and development needed in advance, so the scope and cost of change can be understood.
That evolution depends on the team interpreting new requirements as much as on the software itself.
8. Software expertise needs operational understanding
Developing a TOS requires an understanding of the relationships between vessels, yards, gates, equipment, cargo and commercial processes. Operational knowledge helps a supplier recognise how a requested change may affect planning, inventory or billing, well beyond the screen where it first appears. A supplier’s value lies both in delivering the function and in understanding its wider consequences.
How do we verify that a supplier’s claimed experience holds up in practice?
9. Look for relevant references, not just a long list
Terminals handling similar cargo types, operating at comparable volumes and actively using the relevant modules provide more useful references. For a multipurpose terminal, experience in container operations alone does not demonstrate coverage of every requirement. Speak with operational and IT teams at reference sites about daily use, implementation and support.
Strong references build confidence. We still need to understand how the project will be delivered at our own terminal.
10. Selecting the right product does not guarantee a successful implementation
Even a good product can fail to deliver the intended results if data migration, integration testing, training and go-live are poorly planned. Responsibilities, acceptance criteria and the process for managing changes should be agreed during selection. Success should be measured by whether agreed operational workflows can be completed correctly, not simply by whether the system has gone live.
Go-live is complete. How will support and development continue over the years ahead?
11. Choose a long-term partner as well as a product
A TOS needs to evolve with the terminal throughout its operational life. Access to support, the response to critical issues, release management and the treatment of custom developments in future versions should all influence the decision. Assess the roadmap against the terminal’s expected needs, rather than broad promises about technology.
Does the initial quotation capture the full cost of that relationship?
12. Compare total cost of ownership
Licence or subscription fees should be assessed alongside implementation, integration, development, data migration, training, maintenance, support and upgrade costs. Essential items excluded from the proposal, or inefficiencies that emerge in daily use, can make an apparently attractive offer more expensive over time. Compare proposals on the same scope and over the same period of use.
We have compared the costs. What future capabilities could this investment make possible?
13. Future capabilities depend on today’s data
Reliable, consistent data with its operational context intact provides the foundation for AI, optimisation and digital twin solutions. Practical uses include comparing plans with actual results, examining the causes of delays and evaluating recommendations for resource allocation. These capabilities do not all have to sit within the TOS: its ability to exchange data with specialist solutions and support the use of their outputs in operations matters too.
Taken together, what do these criteria tell us about the right choice?
Bringing the decision together
The right TOS emerges from assessing these criteria against the terminal’s actual needs. The strength of the decision lies in how the system’s capabilities work together in daily operations. It should support the terminal today and adapt to the way it intends to operate tomorrow.
Take the next step for your terminal
If you would like to discuss how these criteria apply to your terminal’s cargo mix and workflows, get in touch with the SOLONPORT team. We can start with your current operations and the processes you want to improve.