How to Choose Dispatch Software for a Marine Pilots Association: A Buyer's Guide

Buying dispatch software for a pilots association is not a normal SaaS purchase. You are not picking a CRM that a sales team can swap out next year. You are choosing the system that sits between an inbound deep-draft ship, a pilot turning out at 0300, and a pilot boat launching into a running ebb — and that then becomes your billing record and your monthly ops report. Pick wrong and you either fight the tool every watch or, worse, you buy fleet software in a pilotage wrapper and quietly lose the things that actually matter on a dispatch desk.

This guide is the checklist a managing pilot, executive director, or senior dispatcher should run a vendor through before signing anything. It is deliberately concrete. If a demo can't answer these questions on screen, that is your answer.

Start with the data model, because everything hangs off it

The single most important question is one most demos never raise: is this software organized around a coverage zone, or around a list of vessels you register?

A fleet platform assumes you own a defined set of boats. You enter each MMSI, it subscribes to those targets, and the map shows your assets. That is exactly right for a tug company or an OSV operator — and exactly wrong for an association that pilots other people's ships through a defined body of water and never sees them again.

Your real question at the desk is geographic: what is inbound to my district right now, when does each ship reach the boarding area, and who do I assign? That demands a system whose home screen is a bounding box over your pilotage grounds, auto-surfacing every AIS-broadcasting vessel inside it — not a registration list you have to populate before you can see anything. If the vendor's onboarding step is "add your vessels," you are looking at fleet software. We unpack this fork in detail in why fleet-tracking software doesn't fit a pilots association, and it is the first thing to verify.

Questions to ask

• Does the board show inbound traffic with no vessel pre-registration?
• Can I draw or configure my own coverage polygon and boarding point?
• Is the tracked record a transit (assigned → pilot aboard → underway → complete) or a vessel?

AIS source: area coverage, not just a pretty map

Every vendor will show you boats on a map in the demo. The questions that separate a real tool from a skin are about coverage and freshness:

• What feed is underneath, and does it cover my water? A busy harbor with dense terrestrial receivers is easy. A commercially-dark district — most of Alaska, stretches of the Pacific Northwest — is not. If you serve water like that, the only authoritative source may be the Coast Guard's Nationwide AIS (NAIS), and the vendor should be able to consume it and help you assemble the data-sharing application. See how this plays out in Cook Inlet pilotage dispatch, where commercial AIS is effectively absent.
• How stale is each report? Every contact should carry an age. A position from twelve minutes ago is not the same as a live one, and the dispatcher needs to know which is which at a glance.
• What fields come through? MMSI, name, call sign, AIS ship type, SOG, COG, and draft should all be present, because draft and tonnage drive both safety and the invoice.

ETA accuracy is the product, not a feature

Raw position is not actionable; time to the boarding area is. A dispatcher launches a boat on an ETA, so the quality of that number is the quality of the whole system.

The naïve version divides great-circle distance by speed over ground. That is fine in slack water and badly wrong where current runs. In a district with a strong tidal stream, an ETA that ignores the along-track current component can be off by enough to send a pilot boat out early or late — both expensive, one dangerous. Ask the vendor directly: does the ETA fold in predicted current (NOAA CO-OPS, for US waters), and does it subtract your configured pilot-boat transit time so the board tells you when to launch, not just when the ship arrives?

For tide-and-current-bound transits, the desk also needs to know the workable window, not just an arrival minute. A good system surfaces flood/ebb state and slack at the boarding area; you can sanity-check the concept against our free tide-window calculator before you judge whether a vendor's version is real or decorative.

The safety stack: ladder, MPX, fatigue, UKC

Dispatch software for pilots is a safety system, not just a scheduler. Four pieces should be first-class, not afterthoughts bolted onto a generic product:

1. Pilot ladder compliance. SOLAS V/23 and the IMO rigging requirements are where boardings go wrong. The board should capture ladder condition and any non-compliance as a logged, time-stamped field — not a free-text note that disappears.
2. Master/Pilot Exchange (MPX). The MPX is the pilot's record of the conduct of the passage plan and any limitations. The system should prompt and store it as structured data tied to the transit, so it is retrievable if anything is ever questioned.
3. Fatigue and rest. Turn-out at all hours is the nature of the work, and 46 USC 8104-style rest thinking plus your own association's rotation rules need to be enforceable by the system, not tracked on a whiteboard. The board should flag when an assignment would put a pilot over a configured limit.
4. Under-keel clearance. For deep-draft transits, squat and UKC are the difference between a clean passage and a grounding. The system should compute it honestly; test the math against our squat calculator so you know what "honest" looks like.

If a vendor treats any of these as a "custom field you can add," they have not built for pilots.

Rotation equity: the thing that keeps the membership whole

Outsiders underestimate this. Inside an association, fair rotation is a governance issue, not a convenience. Who gets the next job, how big jobs and small jobs balance over a month, how turns are counted when someone is on leave or training — these decisions affect every member's income and the association's internal peace.

Software that handles dispatch but not equity solves half the problem. Ask: does the system track turns and balance the rotation according to our rules, produce a rotation report the membership can audit, and handle the edge cases (no-shows, swaps, comp time) without a spreadsheet on the side? A board that quietly drifts the rotation out of balance will cost you more in member trust than the license fee ever saved.

Tariff billing and data ownership

The transit record should flow straight into billing. Pilotage invoices on gross tonnage and a per-GT tariff, draft, and the surcharges your tariff defines — not vessel-hours of an owned asset, which is all a fleet tool knows how to bill. If the dispatcher is re-keying tonnage into a separate invoicing system, the vendor hasn't closed the loop. Pressure-test the concept with our pilotage tariff calculator and our pilotage tariff billing guide, then ask the vendor to invoice a sample transit live in the demo.

Then ask the question vendors hate: who owns the data, and how do I get it out? Your transit history, your billing records, and your ops reports are association property. You should be able to export everything in an open format on demand and on exit. A vendor who can't answer cleanly is a vendor you'll be hostage to.

Onboarding and support

A pilots association does not have an IT department. The implementation should be measured in days, not a quarter: configure the coverage zone and boarding point, wire the AIS feed, set the tariff and rotation rules, train the dispatchers. Ask for a named contact who understands pilotage, a realistic timeline, and what happens at 0300 when the board hiccups and a ship is inbound. Migration from a whiteboard or a legacy tool is its own project — we cover that path in taking a pilots association digital.

Red flags — walk away if you see these

• Vessel-count pricing. You don't have a fleet; you have a zone full of strangers. Any pricing tied to "number of vessels tracked" proves the vendor doesn't understand the model and will punish you for a busy month.
• Fleet software with a pilotage label. If onboarding starts with "register your vessels," it's a tracker in disguise.
• A flat SOG ETA in a tidal district. Decorative, and occasionally dangerous.
• Safety items as free-text notes. Ladder, MPX, and fatigue must be structured and logged.
• No clean data export. Your records, your property — non-negotiable.
• No equity reporting. Dispatch without rotation fairness only solves half the job.

A simple comparison framework

Score each candidate across seven axes, weighted to how your district actually operates: (1) zone-based data model, (2) AIS coverage and freshness for your water, (3) current-aware ETA, (4) the safety stack, (5) rotation equity, (6) tariff billing and data ownership, (7) onboarding and support. A tool that aces tracking but can't bill, or shows boats but can't keep the rotation fair, is not a partial fit — it's a tool you'll outgrow in the first month.

Binnacle Passage was built from this checklist outward: a coverage zone rather than a vessel list, current-aware ETA to the boarding point, ladder/MPX/fatigue and UKC as first-class records, rotation equity reporting, per-GT tariff billing off the transit, and full data export. It is dispatch software designed for an association, not a fleet tool wearing a pilot's coat.

The honest test is to put it in front of your own water and your own watch. Walk the Binnacle Passage capabilities against the seven axes above, then see a live pilot board running against real inbound traffic and judge the ETA, the safety logging, and the billing flow for yourself. If a vendor's demo can answer this guide on screen, you've found your shortlist.

This article is general information for evaluating dispatch software. Pilotage is governed by state law and the licensed association serving each district.