On Friday, dockworkers at more than 40 ports across Europe and the Mediterranean are due to stop work for the day. Italy's transport ministry has registered a nationwide 24-hour port workers' strike, with Genoa, Trieste, Livorno, Ravenna, Gioia Tauro, Civitavecchia and Ancona all named (PortsEurope). In France, CGT Ports et Docks called a 24-hour national stoppage covering Le Havre and Marseille-Fos. What nobody can tell you is which terminals will actually stop. Reporting on the action is consistent on the call and inconsistent on the effect: some ports expect full walkouts, others demonstrations that leave the gates running.
That gap, between a confirmed event and a confirmed impact, is where the week goes. Teams spend Thursday trying to establish whether they are exposed, Friday waiting for terminal notices that arrive late or not at all, and the following Tuesday explaining to customers why a container sat. None of that is a knowledge problem. The industry has been through canal restrictions, a port closure at origin, rolled cargo and tariff deadlines in the space of a few months, and most teams handled each one competently. They just handled every one from scratch.
A disruption playbook is what stops the improvising. It is not a forecast and it is not a risk register. It is the small set of decisions that every disruption forces, written down before the disruption arrives, with a name against each one.
A playbook is a set of pre-made decisions
The useful test for a playbook is not whether it exists. It is whether, at 06:00 on the morning of an event, somebody can re-book freight without calling three people first.
Most documents filed as playbooks fail that test. They describe the escalation tree, list contact details and stop. What they do not say is who may authorise a $40,000 air charter, what evidence that person needs to see, and what happens if they are unreachable. Those are the questions the event actually asks. Everything else is reference material.
So write the playbook as a decision log, not a process map. One line per decision: the trigger, the owner, the data they need, the deadline, and the default if nobody acts.
Build it around the four decisions every disruption forces
You cannot enumerate events. Strikes, closures, typhoons, draft restrictions and customs rule changes all arrive differently. You can enumerate the decisions, because there are only about four of them.
Hold or release. Cargo not yet gated in, bookings not yet confirmed, POs not yet shipped. Stopping something is cheap while it is still at origin and expensive afterwards.
Re-book or ride it out. Another service, another port, another mode, or accept the delay. This is the decision with real money attached, and the one most often made too late to be worth making.
Re-date or re-promise. Production plans and customer commitments built on ETAs that are no longer true.
Tell or stay quiet. Which customers, plants and executives hear what, and when.
Build the playbook once around those four. Each new disruption then becomes a matter of which lanes it touches, not what kind of document to write.
Name the data each decision needs before you need it
Every one of those four decisions runs on the same underlying question: which of my orders and shipments are exposed, right now, and what is each one worth?
That question is where playbooks usually stall. The answer sits across an ERP that holds the order, a TMS that holds the booking, a forwarder portal that holds the actual vessel, and a spreadsheet somebody maintains for the lanes the systems miss. Assembling it takes a day, and the decisions that matter expire in hours. It is the same mechanism that lets 62% of supply chain exceptions reach the customer before anyone inside the business detects them.
This is the gap a command center like Orkestra is built to close. It normalizes order, shipment and carrier data out of existing ERP, TMS and WMS systems into one operational view, so "which shipments route through Genoa in the next ten days, and what is on them" is a filter rather than a project. The playbook only works if the exposure list is minutes away, not days.
While you are writing the data down, note where it comes from and how current it is. A playbook that depends on a feed nobody has checked since July will fail quietly, which is worse than failing loudly. Telling a quiet shipment from a broken feed is part of the preparation, not a separate exercise.
Set the thresholds while nothing is on fire
Pre-agree the tiers. Which lanes, customers or product lines get protected first when capacity is short, and which ones absorb the delay. Written in advance, that is an operating policy. Written during the event, it is an argument.
Most teams already have the raw material: the lane risk scoring that says where exposure concentrates, and the ranking logic for prioritizing exceptions when everything is late at once. The playbook's job is to commit to those rankings before the pressure to make exceptions arrives.
Put a number on the thresholds. "Expedite when the delay threatens a line stop" is not a threshold. "Expedite when projected arrival slips past the production date by more than three days and the part has no alternate source" is one.
Decide what you do when the facts are unconfirmed
This is the section most playbooks skip, and the one Friday needs.
A strike where participation varies terminal by terminal gives you no clean signal. Neither does a weather event, a congestion build or a schedule change the carrier has not announced yet. You will have to commit while the picture is still partial, and waiting for certainty is itself a decision, usually a bad one.
So write the default. For each of the four decisions, state what the team does on an unconfirmed disruption: act, hold, or act with a reversal path. Reversible moves are the useful ones here. Pulling a booking forward by a day costs little and can be undone. Chartering cannot. Knowing in advance which of your options are cheap to reverse is most of what good judgment under uncertainty actually is.
Give every step an owner and a clock
A decision with no name against it belongs to everyone, which means it waits. A decision with no deadline waits too.
Owners have to survive the calendar: Friday afternoon in Europe is Friday night in Asia, and a disruption that spans both needs the handover to work across time zones without the thread restarting each morning.
The part worth automating is the firing of the step, not the judgment inside it. Workflow automation that detects the trigger condition, raises the case, attaches the exposure list and routes it to the named owner removes the delay between an event happening and the right person knowing. OIA Global cut exception resolution time by 60% in a quarter working this way. The decisions stayed with people. The waiting came out.
Test it on a disruption you already survived
Before trusting a playbook, run it backwards against something real. Take last quarter's worst event, and walk the playbook against what actually happened: would the trigger have fired, was the data reachable, did the named owner exist, would the threshold have produced the call you now know was right?
That rehearsal finds the broken parts in an hour, at no cost. The alternative is finding them at 06:00 on a Friday.
Friday's action will probably be smaller than the headlines suggest, and the next one may not be. Either way the playbook is the asset, not the event. Write the four decisions down, attach the data, name the owners, and the next disruption becomes a day of execution rather than a week of assembling the picture. If getting to that exposure list is the slow part for your team, that is the part worth fixing first: book a demo and we will show you what the view looks like when the data is already in one place.
