The reservation system of record: which system may change a booking
In short
A reservation system of record is the single system permitted to change the state of a booking. Every other system may read that state, display it and act on it, but none may set it. The test is blunt: if 2 systems can both move a booking from provisional to confirmed, you do not have a system of record, you have a race between them.
Key takeaways
- The system of record is defined by write authority, not by which system holds the most data.
- One test settles it: if 2 systems can both confirm a booking, neither of them is the system of record.
- Ownership is assigned per object, not per system — the enquiry and the booking state can legitimately live apart.
- A system with an open write path from 3 tools is not a candidate, however good its data model looks.
The reservation system of record is the single system permitted to change the state of a booking. Not the system with the most fields, not the one the sales team likes, not the one finance exports from. The one allowed to write. Every other system reads that state, renders it and asks for changes, but none sets it.
State it that plainly because the common alternative — the system of record is where the data lives — cannot be applied. Booking data lives everywhere: the website, the CRM, the ledger, a consultant's spreadsheet, the voucher PDF in a traveller's inbox. Location tells you nothing; write authority tells you everything.
The test that applies the definition
Take 1 booking and list every route by which its state could change today, including the human ones: a consultant editing a record, a payment webhook, a supplier confirmation being actioned, a nightly import, someone correcting a status because a report looked wrong. Then ask which routes write directly and which raise a request.
One owner per row, everything else a reader
Ownership is assigned per object rather than per system. A trip business has roughly 5 objects that matter, and they may sit in different systems provided each has exactly 1 owner.
| Object | Owner writes | Everyone else | Symptom of a second owner |
|---|---|---|---|
| Enquiry and its qualification | The sales system | Reads for context | Two consultants working the same client |
| Itinerary and proposal versions | The trip builder | Renders the approved version | The client-facing document disagrees with the quote |
| Booking state and supplier references | The reservation system | Reads and requests changes | A confirmed booking with no supplier holding it |
| Financial postings and balances | The finance ledger | Reads balances, never edits them | A paid-in-full trip still in the chase sequence |
| Traveller documents and vouchers | The document service | Links to the issued version | A traveller holding a superseded voucher |
Note what the table does not do: it names no products. Naming systems first is how operators argue about vendors when the disagreement is really about who may change a booking on a Friday afternoon.
What breaks when three systems each believe they hold it
- The website confirms, the back office does not know. The traveller holds a confirmation, operations has no departure line, and nobody notices until the manifest is built.
- The CRM marks a booking cancelled to stop the follow-up emails. The reservation record stays live, the allotment stays consumed, and the supplier is never released.
- Two systems both hold a balance. One says paid, one says outstanding, and the traveller is chased for money already taken — a failure with its own diagnosis in the chase sequence keeps emailing clients who booked.
- Identifiers drift. The property inside the booking is identified 3 ways across supplier, content feed and your database — a separate ownership question, in hotel mapping and the five ids one property has.
Two systems that agree most of the time are more dangerous than two that visibly disagree. You find the exception at the airport.
The system of record is not the system people use
These are different questions, and conflating them causes bad architecture. Consultants can spend the whole day in a tool that owns nothing, provided every change it makes goes through the reservation system's API and is confirmed before the screen updates. One authority, many surfaces.
It has one hard prerequisite: the system you nominate must expose a write path everything else can be made to go through. A platform you can read but not write cannot be the authority for a layer built on top, which is the test in building around the platform you already pay for. Where that write path exists, wrapping a retained platform in better surfaces is ordinary product build scope. Where it does not, no interface work will save you.
The one period when two systems legitimately hold it
A replatform breaks the rule on purpose, and that is fine inside a defined window. During dual-running, 1 system is authoritative per cohort of bookings and the other mirrors it — never both for the same booking. Departures already sold usually stay with the old system until they have travelled, which is why migrating bookings that have not travelled yet is its own problem, and why cutovers are staged against the booking curve in cutting over between seasons without losing departures.
Two things this page leaves alone: the statuses themselves, and whether you need a travel CRM alongside a reservation system, answered in one system or a CRM plus a reservation system. Both sit in build, buy or replatform, with the rest of our travel and tourism work.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Can a CRM be the reservation system of record?
Yes, if it is the only system permitted to change booking state and can hold supplier references and service dates without abusing free-text fields. It usually is not, because a CRM's model is built around a person and a pipeline, so a booking with 4 travellers, 9 services and 2 suppliers ends up spread across custom fields nothing downstream can reliably read.
What is the difference between a system of record and a master data source?
A system of record holds authority over an object's state; master data is the reference data that object points at, such as properties, room types and suppliers. They are often different systems and both need naming, because a booking can be authoritative while the property inside it is identified inconsistently.
How do we choose between two systems that both look like candidates?
Pick the one that can be closed to direct writes from everything else. Authority is enforced by removing write paths, not by policy, so the question is which system you can put behind a single API and which has 4 people with a login and a habit of correcting records by hand. The second is not a candidate, however good its data model.
- system of record
- booking data
- travel architecture
- data ownership
The work behind this page
Builds from our portfolio that this page draws on.
QuoteForge
An AI CPQ and proposal platform that builds enterprise quotes from your catalog, guards every discount against the margin floor, routes approvals, and generates the proposal.
Sales AIAI Lease Management
AI-powered commercial real estate lease management for multi-brand operators — automates lease data extraction, obligation tracking, and portfolio intelligence.
Real EstateRead next
- Bookings confirm on your site and the supplier has no recordA confirmation email proves the checkout finished, not that a supplier accepted anything. Here is the timed comparison that shows whether your booking script reads live availability or a copy.diagnostic
- Enquiry-to-booking conversion: the metric that lies at six monthsGroup enquiries by the month they arrived and follow them until they close. The calendar-month ratio moves when volume moves, so a growing month looks like a bad one.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation