Weather Contingency Planning: A Framework for Resilient Operations
It is 18:00 the night before. The skipper is at the kitchen table with a tablet, a coffee, and three forecast models open. One says the wind will swing south at 04:00 and ease by sunrise. Another holds the front offshore until 09:00. The third hedges. The 07:30 sailing has 142 passengers booked, four of them with international flights out that evening, twelve on a non-refundable package that includes a tour at the other end. The skipper starts the calculation an operator on a weather-exposed run does maybe forty times a year: cancel now, wait until 04:00, or make the call at the wharf at 06:30 and risk the customers who left the hotel at 05:30 to make the sailing?
This article is about the work that should happen long before that 18:00 moment so the calculation isn't fresh every time. The comms side — what happens once the decision is made — is covered in Weather Cancellation Comms: From Panic to Push-Button. This article is the upstream half: how to design the operation, the policies, and the team protocols so the decision arrives faster, cleaner, and with less customer damage when the weather turns.
Contingency planning isn't a document that lives in a drawer. It's a set of pre-made decisions that turn a 30-minute judgement call at 06:00 into a 30-second confirmation. The operators who handle disruption well aren't the ones with better forecasts. They're the ones who already decided what they were going to do.
Why thresholds beat real-time judgement (and where judgement still owns the call)
Real-time judgement under pressure is expensive. The operator deciding each cancellation morning from scratch is making the same decision over and over with subtly different inputs. The decisions drift. The skipper who calls a marginal sailing on goes the following weekend, second-guesses the call, runs the next marginal one against advice, and finds out at sea that the swell built earlier than forecast.
Threshold rules — pre-defined wind, swell, visibility, wave-height triggers per service per vessel — codify the decision once, in a calm room, with the right people in it. The skipper at 06:00 isn't deciding whether to cancel; they're checking whether the forecast crosses the threshold. The cognitive load drops by an order of magnitude.
The trap is treating thresholds as a substitute for judgement rather than a scaffold for it. Local knowledge — how a particular bay handles a south-easterly when the tide is running out, how a vessel sits in 1.5m short-period chop versus 2.0m long-period swell — still belongs to the skipper. The threshold defines the conservative envelope; the skipper retains authority to cancel inside the envelope when local conditions warrant. Thresholds narrow the decision space; they don't replace the human.
The expectation across the major maritime regulators is that the envelope exists on paper before the morning arrives. UK guidance for small-passenger-vessel operators recommends documented operating-limit envelopes per vessel per route, calibrated jointly by the master and the operator and reviewed annually (UK Maritime and Coastguard Agency, MGN 280). The US Coast Guard's small-passenger-vessel inspection regime makes documented weather-decision criteria a routine inspection item under 46 CFR Subchapter T (US Coast Guard, Subchapter T regulations).
The same logic applies to non-marine operations. A coach operator running a mountain pass route has a snowfall threshold and a road-closure trigger. A tour operator running a canyon walk has a flash-flood watch threshold. An accommodated cruise has multi-day weather windows that drive both the go/no-go on departure and route deviation on day three.
The four-layer planning framework
A working contingency plan has four layers. Each is independent — an operator can implement layer one without layer four and still be better off — but the value compounds when all four exist together:
Threshold rules — pre-defined triggers per service per vessel
Substitution playbooks — what runs in place of what, when the primary can't
Customer-protection defaults — what the customer is offered, set before the day-of
After-action review — what each event teaches the operation
Layer one: threshold rules
The threshold is a per-vessel, per-service, per-condition number that, if forecast to exceed during the planned operating window, triggers a defined response. The response isn't always cancellation. The realistic ladder:
Watch — forecast within 20% of threshold. Re-check at the next forecast update.
Conditional — forecast at threshold but uncertain. Decision deferred to a defined later checkpoint with a hard deadline.
Cancel — forecast exceeds threshold, or at threshold with high confidence. Cancellation triggered, comms fired.
Substitute — primary cancelled, but a substitute is viable. Substitution triggered, comms fired with new service detail.
The thresholds themselves are operator-and-master decisions, not vendor-defined. For a marine operator they typically include wind speed (sustained and gust), wave height, swell period, visibility, and tide-window safety margins. For a road operator they include road-surface conditions, ice forecast, visibility, and authority closure status. For an accommodated multi-day product the threshold is multi-day weather-window viability — the whole itinerary, not just departure conditions.
Two practical rules. First, write thresholds per vessel and per route, not generically. A 14-metre catamaran handles a southerly chop differently than an 8-metre RIB on the same crossing. Second, write them with the master, not for them. The skipper who didn't sign off on the threshold will second-guess it on the day; the skipper who co-wrote it will trust it.
The document doesn't need to be long. Operators with the cleanest cancellation operations typically have a one-page-per-vessel envelope: conditions and triggers, the named authority for the call, the checkpoint times for the day-of review, and the date of last annual review. Anything longer gets ignored on the morning it's needed.
Layer two: service substitution playbooks
If the primary service can't run, what runs instead? The playbook is the answer, written down before the day-of. The categories:
Different vessel. The 25-metre can't take the harbour bar in the forecast swell; the 14-metre can. Lower capacity, longer crossing — but the customer gets there.
Different route. The exposed outer-route sailing is cancelled; the sheltered inner-route runs.
Different departure time. The 07:30 is cancelled; the 14:00 runs because the front has cleared.
Different day, with held capacity. The whole day is cancelled; capacity is pre-reserved on the next operating day for same-week rebooks.
Different mode. The ferry crossing is cancelled; the operator has a coach contract for the road route. A combined ferry + tour package can sometimes substitute the tour leg with a different activity at the same destination.
Each substitution carries its own commercial implications. The smaller-vessel substitution means manifest splits and partial refunds for customers who can't be re-accommodated. The route substitution means an itinerary that doesn't match what was sold. The departure-time shift means customers with onward commitments need a refund option, not just a rebook. The playbook should name these consequences explicitly so the duty manager doesn't invent the customer offer in real time.
A working playbook also defines the cost-of-substitution policy. Some substitutions are at the operator's cost (a vessel swap that delivers the same outcome). Some are at the customer's option (a route change that downgrades the experience, refund-eligible). The policy gets written once, applied consistently. Substitutions that aren't in the playbook won't be offered on the morning. The playbook is permission to act.
Layer three: customer-protection defaults
The third layer is the set of policies that determine what the customer is offered when a service can't run. These should be set before the operating season, codified in the booking platform, and applied automatically when a cancellation is processed.
Refund-default versus credit-default. When a service is cancelled by the operator for weather, what does the customer receive by default? Refund to original payment? Credit toward a future booking? A choice between the two? The right answer depends on the operator's downstream cash flow. Operators with cash-flow constraints often lean credit-default with refund-on-request; operators with stronger liquidity lean refund-default. There is no universal right answer — but there is a universal wrong answer, which is making the decision differently for each customer based on who is loudest. Codify it.
Auto-rebook rules. The platform should know which alternatives qualify as auto-offered rebook targets (same product, same party size, within a defined window) and offer them in the cancellation comms. The rules to set: rebook-window length, price treatment, and partial-refund handling for re-accommodation to a different-priced product.
Variations with weather-cancellation protection built in. A more sophisticated pattern: sell two variations of the same product — a standard fare and a "weather-flex" fare at a small premium that includes guaranteed full-refund or no-fee rebook on weather cancellation. The customer self-selects at booking. This pattern is supported by configurable cancellation policies and product variations and reduces the cancellation-day workload meaningfully — protected-fare customers are on auto-rails, standard-fare customers get the operator's standard policy without negotiation.
Re-accommodation across services. Can the customer be moved to a different service at no charge? A ferry customer to a ferry + tour package? A coach customer to a later coach on a different route? Define the policy per substitution type so the duty manager picks from a list rather than invents on the spot.
Refund-processing speed commitment. Research on customer-review velocity suggests refunds processed within 24 hours correlate with materially lower negative-review rates than refunds processed within 7 days (Trustpilot review velocity analysis, 2022). The commitment should be honest — if the payment processor takes 5 business days to settle, the commitment is 5 business days. But the commitment should exist.
These defaults are downstream cash-flow strategy expressed as customer-facing policy. Not a marketing decision — a finance decision. Get the finance team in the room when they are set.
Layer four: after-action review
Every cancellation event teaches the operation something. The fourth layer is the discipline of capturing it. The review is not a long meeting — it is a 15-minute conversation, ideally within 48 hours, with the master, the duty manager, and someone from reservations. Four questions:
Was the threshold right? Was the forecast borderline? If significantly off, the threshold or the decision rule needs adjustment.
Was the substitution chosen the right one? If a substitution was offered, did it work? If none was offered, was one available that wasn't considered?
Were the customer-protection defaults right? Did the policy generate complaints, escalations, refund disputes? Was anything decided on the morning that should have been pre-decided?
What didn't we know at decision time that we know now? Conditions that diverged from forecast, customer reactions that surprised the team, operational dependencies closer to the edge than expected.
The output is one of three things: an update to the threshold document, an update to the substitution playbook, or a confirmation that the system worked. The reviews go in a logbook. Over a season the logbook becomes the evidence base for the annual framework review.
This is the layer that compounds. Operators who run after-action reviews build a contingency plan that gets better every year. Operators who don't repeat the same surprise every season for a decade.
Forecast integration and lead-time discipline
Threshold rules only work if the operator is looking at the right forecasts on a defined cadence. The most common failure mode is waiting for "final" forecast confidence that never arrives, then making a panicked call at 04:30 with customers already half-way to the wharf.
The lead-time discipline experienced operators settle into:
24-hour forecast informs operator decision — monitor closely, prepare a substitution, or pre-emptively cancel a marginal sailing.
12-hour forecast informs operational decision — the go/no-go on the first service of the day, including the decision to switch vessels or routes.
6-hour forecast informs customer comms decision — by 06:00 at the latest for an 07:30 sailing, the customer-facing decision must be made. Customers cannot be told at 07:15 that the 07:30 isn't running.
The discipline is to make the call at the defined checkpoint, not to wait. Forecast confidence on a marginal day rarely improves between the 12-hour and the 6-hour window — it just gets closer to the event. Operators who hold the decision waiting for certainty find the certainty arrives at the same time as the customers.
The operators who handle weather best typically watch two or three independent forecasts and treat divergence between them as itself a signal — when the models disagree, the day is probably the marginal day, and the threshold rules should be applied more conservatively.
The team-side playbook
The technical decisions above are useless without a defined team protocol for executing them. The playbook answers a small set of questions:
Who decides? Named role, with named escalation. Typically: master for operational go/no-go inside the threshold envelope, operator for commercial decisions about substitution and customer offers, duty manager for execution.
What's the trigger? The defined checkpoint times and the defined threshold-crossing event.
Who comms what to whom? The internal chain (master to duty manager to reservations) and the customer-facing comms (duty manager fires the platform's automated cancellation comms with the pre-set templates).
Who reports up? Closing summary to the operator: what was the decision, what was the customer outcome, what does the after-action review need to cover.
Solo operators should treat this as a personal SOP rather than a team protocol. The role-naming exercise is still valuable: the same person plays multiple roles, but the protocol clarifies which role is active at which moment. The skipper-and-owner running a 12-pax operation still benefits from writing down "at 06:00, as master, I check threshold; at 06:15, as duty manager, I fire the comms; tonight, as operator, I record the after-action notes against my logbook."
Crew safety is the load-bearing layer
The framework above is presented in commercial terms because the commercial cost of contingency-by-improvisation is what gets operators to engage with the work. The load-bearing reason to build a contingency plan isn't commercial — it's safety.
Threshold rules exist primarily so the marginal-day decision is made with a calm head, against pre-defined criteria, by a master who has authority to apply them. The decision a skipper makes at 06:00 under pressure, with passengers waiting and reservations chasing refund numbers, is a worse decision than the one made the evening before against documented criteria. The same logic applies to a coach operator running an icy mountain pass, a tour operator running a flood-prone canyon trail, or an accommodated cruise running into a multi-day weather window.
The contingency plan is a safety document with commercial consequences. Treat it that way. Have the master sign it. Have the operator sign it. Review it annually with the same seriousness applied to vessel survey or coach roadworthiness inspection. If a commercial pressure ever pushes against the threshold, the threshold wins.
Three takeaways an operator can act on this week
Write the one-page envelope per vessel. Block out two hours with the master. List the conditions that matter (wind, swell, visibility, whatever applies). Write the threshold numbers. Define the checkpoint times. Sign both names at the bottom. The document doesn't have to be perfect — it has to exist. Refinement happens through after-action reviews over the next season.
Codify the most common substitution. Pick the single most common service-disruption substitution the operation already informally performs. Write it down: when it applies, who decides, what the customer gets offered, what the cost-of-substitution policy is. One playbook entry is better than zero. The rest can be added across the off-season.
Decide refund-default versus credit-default before the season starts. Get the finance team and the duty manager in a room. Decide. Codify in the booking platform. Communicate to the customer-facing team. The decision made calmly in advance is dramatically less expensive than the same decision made on a Saturday morning under pressure.
Where this is heading
Contingency planning was historically an artisan craft — the master's local knowledge plus the operator's commercial judgement applied case-by-case. The direction of travel is toward more structured frameworks.
Climate volatility is widening the disruption pattern. Marginal days are becoming more common, predictability is becoming harder, and the historical baseline is shifting season by season (IPCC AR6 Working Group I report, regional climate change, 2021). Documented frameworks adapt faster than habits.
Insurance carriers are tightening documentation requirements. Marine and tourism insurers are increasingly asking for evidence of documented weather-decision criteria, customer-comms protocols, and after-action review records as part of policy renewal. The operator with the documented framework gets the better rate.
Customer expectations are rising. A customer who books a service and has it cancelled expects the cancellation handled professionally — clear comms, a defined refund-or-rebook offer, a quick resolution.
Forecast technology continues to improve. Higher-resolution regional models, ensemble forecasting, machine-learning-augmented nowcasting — the inputs are getting better. Operators who codified their decision criteria benefit from forecast improvements directly.
The trajectory points the same direction as most other operational disciplines in transport and tourism: from artisan craft toward documented framework, with artisan judgement preserved as the layer of authority over the framework, not the substitute for it.
Want to discuss
What threshold decision has caused the most disagreement between master and operator over the last twelve months? What substitution does the operation already informally run that has never been written down? What did the last marginal-day cancellation teach the team that didn't get captured anywhere? The conversations operators have about these questions are the conversations that produce the documents. The documents are the work.
JetSetGo's multi-modal booking platform supports configurable cancellation policies and product variations — weather-flex fare options, refund-default versus credit-default rules, auto-rebook logic — so the customer-protection defaults from this article can be set once and applied consistently. The companion article Weather Cancellation Comms: From Panic to Push-Button covers the downstream half, once the decision is made.
Book a demo to see how the platform handles the policies that turn a contingency plan into operational discipline.