Keeping a shared itinerary in sync when plans keep changing

• Itineraries
• Collaboration
• Group travel

Three weeks out, someone asks the group chat what time the Thursday train leaves. Four people answer, two of them are right, and the two right answers contradict each other — the train was rebooked in a side thread nobody read.

The itinerary isn't wrong, exactly. It's plural. Several partially-updated copies are in circulation, and the group runs on whichever one the answerer happened to open.

The plan lives in three places at once

Nobody decides to keep three versions. It happens because each version was reasonable when it was created.

• The chat thread, where every decision is technically present, buried under 900 other messages.
• Someone's notes app — the organizer's working copy. Usually the most accurate version, and always the least visible.
• A screenshot of a booking email, posted in March, still scrolled back to in June, showing a departure time that changed in April.

Each is a partial answer, and none of them knows about the others. Drift is the default state, not a failure mode.

One source of truth, and what enforcing it actually costs

The rule is easy to state: exactly one place is authoritative. If it isn't there, it isn't real, and every other copy is permitted to be wrong.

The cost is the part groups skip. Enforcement means:

• Somebody transcribes. Bookings that arrive as email get typed into the plan by hand. Ten minutes each, forever.
• Answering with a pointer, not an answer. "It's 9:40" ends the exchange in four seconds. "It's in the plan, under Thursday" feels obstructive, and you will say it fifteen times before it takes.
• Saying "that isn't in the plan, so it isn't booked." Mildly rude. Saves a day.

Groups abandon the rule not because they disagree with it but because each enforcement costs thirty seconds and the payoff is a disaster that never happens.

Chat is for the conversation. The plan is for the answer.

The usual overcorrection is moving everything into the shared document, discussion included. That fails: arguing about whether the boat trip is Tuesday or Wednesday genuinely is a conversation, with tone and replies and a joke halfway through.

The distinction worth internalizing is that chat is the log of how the group reached an answer; the itinerary is the answer. A log is append-only and read chronologically; a plan is overwritten and read as of now. Asking a thread "what's the plan" means reading backwards until you hit something that hasn't been superseded, which you cannot confirm without reading forwards again.

Discuss in chat, record the outcome in the plan, link back.

Write access should not be uniform

Two tiers cover almost every group: everyone can add candidates, comment and flag problems, and a smaller set edits confirmed bookings — the entries with money and reference numbers attached.

Within that set, one rule does most of the work: the person holding the booking reference owns that entry. Not the organizer, not whoever is loudest — the person whose inbox the confirmation landed in. They are the only one who can verify the detail and the only one who can change it with the airline. When somebody else edits a flight time from a screenshot, you have an unverified number in your authoritative document, which is worse than a blank field, because a blank field prompts a question. When a booking is transferred, ownership transfers with it.

An edit nobody notices is the same as no edit

Silently correct is a real failure state. Change the train from 09:40 to 07:15, tell nobody, and three people arrive at 09:10 having read the plan last Tuesday.

The fix is cheap: every material change gets a one-line note in chat, phrased as a delta rather than a new value. "Thursday train moved 09:40 → 07:15, so checkout is now 06:30." The arrow is what makes people re-check whatever sits downstream. A bare "the train is at 07:15" reads as information; "moved from 09:40" reads as an alarm.

Material means anything that changes what a person does or pays: times, dates, addresses, who is on which booking, money. A restaurant added to a shortlist is not.

The calendar problem

Eventually someone puts the itinerary into calendars, which is right: the calendar is where people actually look. There are two ways to do it, and only one survives a change.

A static export is a snapshot: everyone downloads the file and imports it, and it is accurate at that moment and never again. Move a flight and every phone keeps the old time, silently and permanently — worse than no calendar at all, because the wrong time has been laundered through a surface people trust.

A subscribed feed is a URL the calendar app re-fetches on its own schedule, so an edit propagates without anyone re-importing anything. Two caveats: refresh is not instant — providers poll on their own timetable, sometimes hours — so same-day changes still need the chat message, and the URL is the credential, so treat it as shareable-but-not-public, keep booking references out of it, and revoke it afterwards.

The last 48 hours: stop editing

Freeze the plan two days out. Changes still happen after the freeze, but as announcements rather than quiet edits, so the group works from a stable artifact everyone has read.

Then distribute it in a form that survives a dead phone, no signal and roaming switched off:

1. Offline access on every phone — an app that works without a connection, or the plan saved locally.
2. A screenshot of the first-day essentials on each person's device: address, check-in window, arrival times, one phone number that works locally.
3. One printed copy in one bag. It costs nothing and has rescued more first days than any app.

The rules, compressed

1. One place is authoritative. Everything else is a copy and may be wrong.
2. Discuss in chat, record the outcome in the plan, link back.
3. Whoever holds the booking reference owns that entry.
4. Everyone can add candidates; fewer people edit confirmed bookings.
5. Announce every material change as a delta, not a new value.
6. Subscribe calendars to a feed, never a static export you will need to change.
7. Freeze 48 hours out, and hand out something that works offline.

Caravan is built around this shape: one shared itinerary of destinations, stays, flights and key dates; host, manager and member roles, so the people holding the bookings are the ones who can edit them; and a revocable calendar subscription feed rather than a one-off download, so a moved flight reaches everyone's calendar instead of sitting in a file imported in March. Edits made offline queue on the device and replay on reconnect. Flights and stays are typed in by hand — Caravan does not read your inbox. The FAQ covers roles and sharing.

None of this needs software, though. It needs one place, a short list of people allowed to change it, and the discipline to say when something moved.