Flights move. Your grid should move with them

Most production documents describe decisions. The schedule is a decision. The rooming list is a decision. You make them, and they stay made until somebody changes them.

A flight grid is different. It describes something happening in the world without your involvement, and the world does not consult you. A flight is delayed in Panama at 3am and your board is wrong before anyone in the office wakes up. This is the only production document that goes out of date on its own.

One flight, one row

Start with the structural decision, because everything else depends on it. When six crew are on the same flight, that is one flight and six passengers — not six flights.

Boards built the other way are the most common failure. A row per passenger looks tidy in a spreadsheet and becomes unreadable at scale: the same flight number repeated eleven times, the same arrival time typed eleven times, and eleven places to make a mistake when the time changes. Worse, it hides the thing a coordinator actually needs to see, which is how many bodies land at once — because that is what determines whether one van is enough.

Group by flight, stack the passengers beneath, and the board starts answering the question that is really being asked. In the printed version the continuation reads as the same flight rather than a new one. It is a small layout mechanic and it is most of what makes a travel board legible.

Seven states, not two

Scheduled, boarding, delayed, in flight, landed, diverted, cancelled. Reducing that to on-time and late throws away exactly the distinctions that change what somebody does.

Diverted and cancelled in particular are operationally different in every way that matters — one means find out where they actually landed, the other means rebook and tell the client the schedule moved. Collapsing them into a red pill saves a column and costs an hour.

The board changes under the reader

Once status updates on its own, a new design problem appears that static documents never have: the screen moves while someone is looking at it. Too subtle and a delay goes unnoticed. Too loud and the board feels unreliable, which is worse — a coordinator who does not trust the board goes back to checking flights manually, and then you have both systems and neither.

Polling has a rhythm to it. A flight three days out does not need checking every minute. A flight landing in forty minutes does. The cadence should tighten as the flight approaches, run silently in the background between sessions, and surface the meaningful transitions — delayed, in flight, landed, cancelled — rather than every refresh.

Airport-local wall clock, always

This is the detail that separates people who have run travel from people who have modelled it.

A flight departs at 06:40. That is 06:40 at the airport it leaves from. It is not a moment in UTC that needs converting for the reader, and it is not relative to a project timezone. Every ticket, every board in every terminal, and every crew member's phone will show the local wall clock. The instant a system starts converting times into a project timezone, it produces numbers that disagree with the boarding pass, and the crew member believes the boarding pass.

So the times are stored as the digits themselves and rendered as the digits themselves. Printed documents say the times are local. There is no timezone concept, deliberately, and adding one would be a regression dressed as a feature.

The quiet failure

Here is the state nobody designs for, and it is the one that actually bites.

A flight is added with a passenger and a flight number but no departure time yet — the itinerary has not come through, or someone was entering it quickly. It sits on the board looking completely normal. It has a row, a name, a route. And nothing is tracking it, because there is no time to track against.

The board says everything is fine. The board is not lying, exactly; it simply has no way to express "this line is not being watched." That asymmetry — visible on screen, invisible to the poller — is the most dangerous state in the tool, and it needs to look different from a flight that is genuinely on schedule.

What comes off the board

Once the flights are correct in one place, the derived documents stop being separate work. Driver call sheets are the same data grouped by driver instead of by flight. Airport pickup signs are one landscape page per arriving flight, with the passengers who share it. A client-facing view is the same board with the controls removed and the status pills frozen.

None of those need maintaining. They are views. That is the whole argument for putting travel in a system rather than a sheet: not that the grid is prettier, but that the four documents downstream of it stop being four documents.