At 21:40 a crew scheduler in Dublin moves a crew of eight from a morning positioning flight to one leaving that night. It is a small change on the roster screen. It is not a small change anywhere else.
The hotel in Lyon now has eight rooms to release before the cancellation deadline. Two vehicles are booked for a 09:30 pickup that will never happen, and two more are needed at 23:50. The caterer has a meal order against the wrong flight. Finance will receive invoices for both sets of bookings, and someone will spend an afternoon working out which to pay.
The crewing system knows who is travelling and when. The airline's distribution channel, whether NDC content or a GDS, knows the seat. The hotel's inventory knows the room, the dispatch software knows the car and driver, the catering system knows the meal, and finance knows what was paid. Each holds a piece. None holds the journey.
Six systems, none of which owns the journey
Each of these systems is the system of record for its own domain. A crew journey cuts across all six, and when the journey changes, six records must change with it. In most operations that work is done by people: a duty travel desk reads the roster change, cancels the hotel by email, phones the transport provider, amends the catering order on a portal and sends a note to finance. Each handover is a chance for the picture to drift. By 02:14, when the diversion comes, nobody is quite sure which version of the plan is live.
A shared record, and who may touch it
The first thing it really takes is a single record that represents the journey itself rather than any of its parts: this crew member, this duty, these legs, this room, this car, this meal, this cost centre.
Every supplier booking then hangs off that record. When a change arrives, it arrives at the journey, and the question becomes "which bookings does this affect?" rather than "who do I need to phone?"
Close behind the shared record comes identity. Crew, schedulers, hotel desks, drivers, caterers and finance all touch the same journey, but each should see and change only its part. A driver needs a pickup time and a name, not a passport number. A hotel needs room nights and a billing entity, not the roster. Permissions set at journey level, rather than per supplier portal, make the record safe to share.
Change propagation is the real product
The hard, unglamorous centre of all this is change. Rosters change constantly, often outside office hours. A platform that can create a hotel booking, a car and a meal order from a roster is useful. One that can reliably amend or cancel all three when the roster moves at 21:40, and tell everyone what it did, is the actual product.
A roster change that does not reach the hotel, the car and the invoice is not a change, it is a discrepancy waiting to be found.
Good propagation is idempotent: a change applied twice has the same effect as once. It is ordered: a cancellation does not overtake the booking it cancels. It is observable: a scheduler can see that the hotel has acknowledged and the car provider has not. And it degrades gracefully: when a supplier cannot be reached by API, the change becomes a task for a person rather than silently disappearing.
Supplier APIs of very different maturity
Anyone who has tried to wire this together learns that "integration" means something different at every supplier. A large hotel group may offer a documented booking API with real-time availability and cancellation. A family-run hotel near a regional airport in Portugal may offer an email address and a willingness to answer the phone. Some private-hire operators run dispatch software with webhooks for job status, driver and vehicle; others take jobs by text message and confirm with a thumbs-up. Catering often sits in between, with a portal that accepts orders but no notion of a change.
The integration layer has to meet each supplier where it is, which means supporting several tiers in one platform:
- A full API tier: real-time availability, booking, amendment, cancellation and status callbacks.
- A structured messaging tier: the platform sends a formatted request and parses a structured reply.
- A human-in-the-loop tier: the platform generates the task, tracks it and records the confirmation when done.
All three tiers write back to the same journey record, and the data trail should look the same whichever tier a supplier sits in.
Settlement from one ledger
Finance is usually the last part to be connected, and the part that decides whether the whole thing pays for itself. When each supplier invoices separately, the travel desk spends days each month matching invoices to journeys and chasing credits for cancelled rooms.
Record every supplier transaction against the journey as it happens and settlement becomes reading a ledger rather than reconstructing one: one statement per period, by journey, crew member, cost centre and supplier, with every amendment visible against the line it affected. Suppliers are paid faster, disputes shrink to the lines where ledger and invoice genuinely disagree, and the operator can finally see what crew travel costs per flight.
Why point-to-point fails and a platform in the middle works
The intuitive way to connect six systems is to connect each pair that needs to talk: roster to hotel, roster to transport, hotel to finance. It works for the first few links, and then it does not. Each new supplier adds several integrations, each change in the roster format breaks several of them, and soon nobody can draw the diagram.
A platform in the middle changes the shape of the problem. Each system integrates once, with the platform, which holds the journey record, the permissions, the propagation logic and the ledger. Adding a hotel in Riyadh means one integration, not five. Changing the roster system means one migration, not a dozen.
We should be honest about the hard parts. The middle layer has to be fast enough that schedulers trust it at 02:14, a stricter test than any office-hours demo. It has to model the edge cases real operations throw up daily: split crews, hotels that confirm by phone and then lose the booking, crew members who live near the destination. And it has to earn adoption from suppliers who have no reason to change. None of that is solved by software alone; it takes people who have done the work and know where it goes wrong.
Key takeaways
- A crew journey cuts across six systems, from roster to finance, and none of them holds the whole picture.
- The foundation is one journey record that every supplier booking hangs off, with permissions set at the journey level.
- Change propagation, not booking creation, is the real test of an integration layer.
- Supplier connectivity ranges from mature APIs to a phone number; every tier has to produce the same data trail.
- Point-to-point integrations collapse under their own weight; a platform in the middle means one integration per system and one ledger.