Lesson 1: water level and lock data are rarely machine-readable
The first instinct when automating charter planning in inland waterway transport is to link travel times to live water levels and lock data. Logical. The problem is that in practice this data is rarely in a format a planning algorithm can use directly. Rijkswaterstaat publishes water levels through multiple channels, but the formats, measurement points, and timestamps differ per waterway. Lock schedules arrive sometimes as a PDF, sometimes by email, sometimes through a portal with its own export structure. Before you can run any calculation, you need to normalise: one data model, one timezone, one unit. That is unglamorous work, but it accounts for half the effort. Anyone who skips that step builds a system that calculates attractive routes based on outdated or incorrect input. In inland waterway transport, where a few centimetres of water depth determines the difference between a full load and a partial one, that is not a theoretical risk.
Lesson 2: the soft planning rules are not written down anywhere
Charter planners work with rules that exist outside any system. Regular client A always wants skipper B on their cargo, because that skipper knows the berth and the client trusts them. Client C has a verbally agreed departure window that is formally documented nowhere. Certain cargo types always go with a specific vessel, not because it is technically required but because that is simply how things evolved. These soft rules determine a large share of the actual planning. An algorithm with no awareness of them generates a plan that looks optimal on paper but is immediately overridden by the planner in practice. The solution is not technical: you need to make those rules explicit first. That means having conversations, shadowing the planner, and documenting every exception. Only once those rules sit inside the system as configurable parameters does automation have a grip on reality. This costs time before the build, but it is the investment that determines whether a system gets used or stays sitting next to the spreadsheet.
Lesson 3: a system without an escalation route loses buy-in
Planners in inland waterway transport work with uncertainty. A vessel departs late, a lock is out of service longer than scheduled, a client calls with an urgent change. An automated planning system that cannot handle this and simply keeps calculating makes the wrong decisions. Worse: planners lose confidence in the system and start working around it. What works is a clear escalation structure: the system flags the exception, prepares the relevant information, and puts the decision with the human. Not every deviation needs to be handled manually, but the planner must know which decisions the system takes on its own and which ones it presents for approval. That boundary needs to be agreed in advance and built into the system. Human in the loop is not just a phrase here; it is the prerequisite for adoption. Once planners experience that they retain control over exceptions, confidence in the automated baseline decisions grows.
When does automating charter planning fit, and when does it not?
Automating charter planning in inland waterway transport works well when you have a repeatable pattern: fixed routes, fixed clients, multiple vessels that you need to allocate to demand week after week. The more structure there is on the demand side, the more a system can take over. It fits less well when every charter is a one-off puzzle with constantly changing variables, clients, and vessels. In that case, the overhead of maintaining the configuration outweighs the time saved. An honest question to ask upfront: what percentage of your current plans share the same basic structure? If the answer is above half, automation is worth exploring seriously. If the answer is low, start by capturing your planning data in a more structured way. That is the groundwork that makes automation possible later, even if you are not ready for it yet. At Bonsai we build these kinds of planning systems as custom software, either as part of a new core system via the Bonsai AI Digital Twin, or as an AI Worker running on top of an existing system.