A departure date moved. How to sync every channel once

Moving a departure date looks like sending one message. In practice it touches five things: itinerary dates on paid orders, travellers who were quoted but have not paid, selectable dates on the website and booking page, inventory and holds for that date, and supplier-side rooms and vehicles. Miss any one and it surfaces three days before departure.

One: decide whether you are editing a departure or an order. If a whole route departure slips, edit the departure. If a single traveller needs another date, edit the order. Confusing the two is the most common mistake, because editing the departure date moves every paid traveller with it.

Two: let inventory follow the departure; do not create a new one. Creating a new departure and moving people by hand leaves a zero-inventory record published on your site. Edit the date on the existing departure so inventory and holds carry over.

Three: re-check the price calendar. A moved date may cross from weekday into holiday pricing. The calendar is configured by date, and moving a date does not re-rate it. Confirm this manually; it is not a decision the system should make for you.

Four: notifications have three audiences. Paid, quoted-but-unpaid, and people who merely asked in a chat. The first two exist as records (orders, leads and enquiries); the third only exists in a person head. Hand the first two to the system and the list you chase manually usually halves.

Five: run the pre-publish check. After editing, run it once. Missing rates, missing inventory and untranslated fields get listed, which is better than a customer finding them.

In one line: treat the departure record as the single source of truth and stop maintaining copies of it. The only two judgements left to you are whether pricing should move with the date, and how to chase the people who only ever asked in a chat.