The problem a handover should solve
A small boat departure can involve several people who each hold a different part of the truth. Reservations knows the latest sale, a driver knows a guest missed pickup, the pier team has counted arrivals and the captain has counted people aboard. A busy group chat can contain all of that information without giving anyone a reliable departure picture.
The aim is to turn scattered updates into a clear operational record. It should answer which departure this is, which guests are expected, who is present, what changed and who is dealing with an exception. It must also make clear when a previous version has been superseded.
This guide proposes an administrative workflow for tour operators. Vessel certification, passenger capacity, crewing, weather decisions, required safety equipment and emergency procedures must follow the applicable rules and the operator's approved arrangements. A booking-system total cannot establish permission to sail.
Start with an unambiguous departure identity
Create one identifier for each actual departure. Combine a stable booking-system departure ID with a human-readable label containing the date, local departure time, product and vessel assignment. Avoid names such as morning boat or tomorrow's group, which become unclear when a message is forwarded or read later.
For example, an internal record might read: departure BT-20261024-01, 24 October, 09:00 local time, island day tour, assigned vessel confirmed separately. The exact format is less important than using the same identifier across reservations, transport and pier communications.
Keep the product name separate from the vessel name. A vessel change should trigger an updated assignment and the appropriate operational review, without creating the false impression that guests have booked a different tour. Record who confirmed the new assignment and when the captain acknowledged it.
Assign responsibilities before the busy period
Name a shore lead who maintains the current record. Identify the reservations contact authorised to resolve booking changes, the transport contact handling missing arrivals and the person authorised to approve commercial exceptions. These can be the same person in a small business, but the responsibilities still need to be explicit.
The captain needs a reachable shore contact, not an instruction to message whichever office account happens to be online. Give that contact a backup for the period when they may be assisting a guest or away from the phone. Test that the channel works before using it for a live departure.
Write down who communicates with the traveller. Otherwise a driver, reservation agent and pier assistant may each send a different instruction. One person should own the guest-facing update while the relevant teams work from the same operational decision.
Keep three passenger states separate
An expected booking is not a checked-in guest, and a checked-in guest is not necessarily aboard. Use distinct states so the team can reconcile them deliberately:
- Expected: the current reservation includes this traveller on this departure.
- Checked in: the agreed identity and booking checks have been completed at the relevant meeting point.
- Aboard: the crew's boarding process has accounted for this person on the assigned vessel.
Track cancellations, transfers and unresolved arrivals separately. A guest moved to another departure must not remain silently in both lists. A cancellation after the initial printout should produce a visible revision rather than an unexplained difference in the final count.
Record children and infants according to the booking and applicable operating requirements. Never let a price category such as free infant make a person disappear from operational accounting. The crew must apply the vessel's actual rules for people aboard; the marketing price is a separate subject.
Build a useful handover record
The record should be short enough to use at the pier but complete enough to prevent the team searching several conversations. A practical structure includes the departure identity, version and update time, captain and shore contacts, vessel assignment, current passenger list, booking references and unresolved exceptions.
For each booking, show the lead traveller's name, party composition, relevant meeting arrangement and current arrival state. Keep payment or voucher issues as clear operational notes with an owner. Do not expose unnecessary financial information to every person who receives the departure list.
Separate information required by the vessel's approved procedures from optional service preferences. The former must be collected and handled through the proper process. The latter should be limited to what the receiving team actually needs to deliver the booked experience.
Do not put passport photographs, full card details or unrelated personal conversations into a widely shared chat attachment. Use controlled access to the information required for the operation, and follow your retention and privacy arrangements after the departure.
Reconcile the departure before release
Choose a reconciliation point that fits the real operation. The shore lead compares the latest reservations with transport and pier information, resolves duplicate entries and identifies anyone still missing. The captain and crew then use their own approved boarding and passenger-accounting process.
If the numbers differ, investigate the specific person or booking rather than altering a total to make it match. Typical administrative causes include a guest transferred to another boat, a late cancellation left on the printout or a child recorded under an adult's name without a separate visible entry.
A handover is complete only when the receiving person has acknowledged the relevant version. Sent is a communication event, not proof that the captain received, understood or accepted an update. Record the acknowledgement in a simple way that can be checked later.
Do not let a commercial desire to depart on time override the captain's responsibilities or the operation's required checks. The handover should make those checks easier, not create a new shortcut around them.
Handle late changes as revisions
After the first handover, every material change needs a controlled update. State the departure ID, new version, exact change, affected traveller or booking and who must act. Mark the prior version as superseded so nobody boards from an obsolete list.
For example: version 3 replaces version 2; booking BQ-184 now has two adults and one infant rather than two adults; shore lead has corrected the reservation; captain acknowledgement required before the departure is treated as reconciled. The appropriate crew member must still apply the actual passenger-accounting and operating requirements.
Avoid messages that say only one more guest or family changed. Those descriptions force the receiver to infer whether a person was added, substituted or moved. If an update arrives by phone, the record owner should write the change back into the controlled record and obtain the necessary acknowledgement.
Commercial changes also need an owner. If a guest asks to switch a paid extra at the pier, record whether the change was accepted, declined or left pending, and who will handle any payment or refund. Do not make the captain reconstruct an office conversation while managing boarding.
Give every exception a next action
An exception list is useful only when it tells the team what happens next. Missing guest is a description; transport coordinator calling the lead traveller, next update to shore lead before the decision point is an action with an owner.
For a late arrival, capture the traveller's known location, the verified transport information and the person communicating the outcome. Do not promise that the boat will wait until the responsible operational decision has been made. Likewise, do not label someone a no-show merely because one office message went unanswered.
For a booking mismatch, identify which record is authoritative and who can correct it. For a language issue, assign a person able to communicate the relevant information. For a changed meeting point, confirm the actual pin and the acknowledgement rather than assuming that a forwarded map was read.
Keep unresolved issues visible. Hiding a note because it makes the list look untidy removes the very information the handover is intended to carry.
Keep weather information in its proper role
Use official information such as the Thai Meteorological Department as an input to your established operating process. A shore assistant should not invent a weather threshold from a general forecast, and a booking agent should not declare a route safe because it operated yesterday.
Record the operational decision made by the authorised person and communicate the resulting itinerary or cancellation accurately. Distinguish a route under review from a confirmed replacement. Guests should not receive a definite promise while the captain and operator are still deciding.
If the programme changes, update what the traveller is actually buying: meeting place, departure time, included activities and any commercial remedy determined by the applicable terms. The handover's job is to keep teams aligned on that decision, not to create a new policy at the pier.
A worked example: one family, two corrections
Imagine a fictional departure with twelve expected travellers. Reservations receives a correction that one family includes an infant omitted from the original entry. Separately, a driver reports that another guest has chosen not to travel. Simply adding one and subtracting one leaves the total unchanged, but the manifest is still wrong unless both individual records are corrected.
The shore lead creates a revised list showing the family composition and the separate cancellation. The reservations contact updates the underlying bookings. The pier team checks the people who actually arrive, and the crew completes its boarding accounting under the vessel's procedures.
The captain acknowledges the revised departure record. The office handles any cancellation follow-up through the normal commercial process. The example illustrates why a matching total is insufficient: the identity and state of each traveller matter as well.
If the infant correction changes any operational requirement, the authorised crew and operator must resolve it before departure. The administrative form cannot decide that question on their behalf.
Use a template the team can complete quickly
Copy these field labels into your own system and adapt them to the approved operation:
- Departure ID, date and local time; product; assigned vessel; record version and update time.
- Captain; shore lead; backup shore contact; reservations and transport contacts.
- Expected booking list; party composition; booking references; required operational information.
- Checked-in state; crew-confirmed boarding state; cancellations and transfers.
- Exceptions; named owner; next action; decision point; guest communication owner.
- Changes since the previous version; acknowledgement by the receiving person.
- Return arrangements and the person responsible for reconciling the completed departure.
Avoid adding a field solely because it might be useful someday. If the team cannot explain who uses it and why, it may create clutter or unnecessary personal-data collection. Review the form after real departures and remove duplicate entry wherever the booking system can provide the information reliably.
Close the loop after the boat returns
The handover continues to matter after departure. Record relevant changes to the return arrangements, unresolved guest-service matters and any follow-up assigned to the office. Use the approved operational reporting process for incidents rather than hiding them in a sales note.
Review recurring discrepancies weekly: duplicated travellers, missing infant entries, unclear pickup ownership or late product changes. Fix the source of the problem, such as an ambiguous booking field, instead of repeatedly asking the pier team to work harder around it.
For related processes, explore Tripnatic partner resources and the operator programme. A useful booking workflow gives the crew reliable information while keeping qualified operational decisions with the people responsible for them.
Sources and scope
The Australian Maritime Safety Authority's safety management system guidelines provide a primary-source example of documented responsibilities and passenger management. They apply in their stated Australian context and are not presented here as Thai law. Official Thai weather information is available from the Thai Meteorological Department. Reviewed in October 2026. The handover template and fictional example are original editorial workflow suggestions, subordinate to applicable requirements and the vessel's approved procedures.
