Yacht charter availability: from open to confirmed

A useful availability request identifies the yacht, requested charter dates, intended embarkation and disembarkation areas, party size and any important operating context. Asking only whether a yacht is 'free in July' produces an answer too broad to support a proposal.

This is why availability should not be stored as a simple yes/no field on a yacht profile. It is a relationship between a request and a response. If the dates, route or party changes, the broker should treat the new situation as requiring confirmation even when the earlier answer was positive.

Different companies may use slightly different terminology, so the meaning supplied by the central agent or manager controls. A structured workflow can still preserve a practical set of states without pretending they are universal legal definitions.

Calendars can lag behind conversations. Owner use, maintenance, positioning, pending contracts and off-market discussions may be known to the manager before they appear in a shared system. Conversely, a visible block may include buffer or travel time that could change for the right enquiry.

The broker should preserve both the discovery signal and the authoritative answer. A marketplace calendar can justify asking; it should not be cited to the client as proof once the yacht's authorised representative has supplied newer or more specific information.

An option is valuable only when the record shows who granted it, what dates and terms it covers, when it expires, the applicable time zone and what action is needed to maintain or convert it. A status label without those details creates operational risk for both broker and yacht side.

Second-option handling deserves equal care. The broker needs to know whether the first option can be challenged, how much response time the first holder receives and what happens if that deadline passes. Those rules should be communicated by the authorised representative rather than inferred from a previous charter.

A green badge in software cannot replace the confirmation steps agreed by the parties. Under common industry practice reflected in the MYBA Charter Agreement, the negotiated particulars, signatures and required payment process matter. The actual contract and current communications should determine whether the charter is binding.

Software should therefore show evidence rather than overstate legal effect: response source, timestamp, expiry, agreement state and payment milestones. It should also retain the history so a team can understand why a yacht appeared available when a proposal was sent.

Before presenting a yacht as available, capture the exact date window, embarkation context, responding person and organisation, response time, status, expiry and conditions. Link the answer to the relevant client brief. If any of those elements changes materially, confirm again.

This disciplined record improves the client conversation. The broker can distinguish 'we have asked', 'the yacht is holding our dates until 17:00 CET' and 'the signed charter is confirmed' instead of compressing three very different states into the word available.