Harbour and port operations are usually run on a combination of a whiteboard, a spreadsheet, a card index and somebody's knowledge. It works, and it does not scale, and it does not survive that person retiring.

Here is what a system has to handle.

The central record is the vessel, not the customer

The first place generic software fails.

A vessel has an owner, and it may also have an operator, a manager, a skipper and an agent — each a different party, any of whom might be the one you invoice or the one you telephone.

The vessel also has characteristics that determine everything: length overall, beam, draught, tonnage, and its type. Those drive what berths it can use, what dues it pays and what rules apply.

A system built around customers with vessels attached gets this backwards. The vessel is the thing that occupies the berth and generates the charge.

Berths, and why booking software does not fit

A berth is not a hotel room. Whether a particular vessel can occupy a particular berth at a particular time depends on:

  • Length and beam against the berth's dimensions
  • Draught against charted depth and the state of the tide
  • What is already alongside, and whether rafting is permitted
  • Weather and forecast conditions
  • Priority — commercial and fishing traffic ahead of visitors
  • Any operational restriction in force

A useful system encodes the physical constraints so that an impossible allocation is prevented, while leaving the judgement calls to the harbourmaster. Software that attempts to decide is resented and worked around; software that prevents mistakes and shows the picture is used.

Movements

Arrivals and departures, recorded with time, berth and any pilotage or towage involved.

This is the record that feeds dues, that answers questions afterwards, and that constitutes part of the authority's operational record. It needs to be quick to enter — frequently by somebody on a pontoon with a phone in the rain — and complete.

AIS data can support this usefully, showing what is approaching and helping populate movement records. It should be treated as supporting information rather than as the authoritative record: not every vessel transmits, coverage varies, and data quality is inconsistent.

Dues, which are where the manual work is

Harbour dues follow a published tariff applied to vessel characteristics, and every harbour's tariff is its own.

Charges by length or tonnage, per visit or per day or per season. Different rates by vessel category. Annual agreements, resident concessions, minimum charges, discounts for particular arrangements. Passenger dues, cargo dues, and charges for services provided.

The rules are not complicated individually. Collectively they take real time to apply by hand, and they are applied inconsistently when several people are doing it from memory.

Encoding the tariff so charges are calculated from the movement record is usually the change that produces the clearest return — both in time and in revenue that was being missed. The pattern is the same as any pricing system, covered in quoting and invoicing.

Moorings and agreements

Annual and seasonal moorings, waiting lists, transfers, and the perennial question of who is next when a berth becomes available.

Waiting lists in particular benefit from being systematised. Where they are held informally, disputes arise about position and precedence, and there is no record to settle them.

Agreements need renewal dates, terms, and a link to billing so that annual invoices are raised without anybody remembering.

Compliance and safety records

Harbour authorities have statutory duties, and the associated records need to be findable rather than filed.

Depending on the authority that may include: safety management documentation, incident and near-miss records, inspection records for infrastructure, pilotage records, port marine safety compliance evidence, dredging and survey records, and environmental monitoring.

The requirement is usually not sophisticated processing — it is that the record exists, is dated, is attributable, and can be produced when asked. Audit trail matters here for exactly the reasons in why audit logging matters.

Practical requirements

It must work on a phone, outdoors. Movements are recorded on the quay, not at a desk. Large targets, few taps, and it must work with poor signal.

It must work offline. Signal around a harbour is patchy, particularly among structures and inside buildings.

It must be quick for the common case. Recording a routine visitor arrival should take seconds. If it takes two minutes, it will be written on paper and entered later, or not at all.

It must connect to accounting. Dues raised in the operations system should reach the accounts without retyping — see connecting accounting to operations.

Buy or build

Products exist for marina and harbour management, and for a marina with a standard commercial model they can suit well.

Building becomes worth considering where the tariff, the mix of commercial and leisure traffic, or the statutory duties do not fit — which is common for trust ports and municipal harbours whose arrangements are genuinely their own. Work through the decision properly first, using build versus buy.

Our team combines maritime background with business systems work. Start a conversation if your harbour is run on a spreadsheet and one person's memory.