Ask a yacht operator where their bookings live and you rarely get one answer. The calendar is in a spreadsheet, the guest details are in WhatsApp, the crew plan is on a whiteboard, and the money is in a notebook. Each of those is a reasonable tool. Together they are five copies of the same operation.
The copy problem
The trouble is not that people use spreadsheets. It is that the same fact — “Aurora is out on Saturday with eight guests” — is written down in five places. Change one and the other four are quietly wrong. Nobody notices until the crew turns up for a tour that moved, or two bookings land on the same boat.
One record, many views
A connected operation starts from a different premise: the booking is a single record, and everything else attaches to it rather than copying from it.
- The crew assignment points at the booking, so a date change moves the crew too.
- The preparation checklist belongs to the booking, so nobody asks “was this boat cleaned?”
- Payments and APA movements post against the booking, so profitability is a query, not an exercise.
- The post-tour feedback invitation is triggered by the booking’s end date.
None of this is exotic. It is what happens when you stop treating each department as its own system.
What changes in practice
Three things tend to change in the first season.
Fewer status meetings. “Which booking is where?” is answered on a screen instead of in a group chat.
Fewer collisions. Slot control refuses the double booking rather than discovering it on the day.
Reports that build themselves. Because the operation was recorded correctly, occupancy and revenue reports are a by-product, not a separate data-entry job.
Where to start
You do not need to move everything at once. Most operators start with booking and calendar, add fleet and crew once the season rhythm is established, and bring finance in last. What matters is that each module you add reads the same record rather than starting a new one.