FIELD GUIDE 03
Designing Booking Architecture for Operations
A booking is not finished when the success screen appears; it starts a record that people must operate.
The happy path is only the first part of a booking system. Once a customer has committed, support, changes, delivery, source confirmation and history determine whether the product can be operated without guesswork.
FIELD NOTES
Why this matters
A success message is a moment in a longer process. The booking may later need a status check, a supplier reconfirmation, a change, a cancellation or a customer explanation.
When those needs are added after release, the team often has to reconstruct what happened from incomplete data and memories.
Reservation data is an operating record
Order, passenger or customer context, ticket, seat, price snapshot, supplier reference, payment, delivery and history each answer a different operational question. They should be understood as related evidence, not as a loose collection of fields.
What matters is that the record can explain the booking that was made at that point in time.
State management without false certainty
CREATED, PENDING, CONFIRMED, FAILED, CANCELLED and CHANGED are useful conceptual examples, not a fixed SORADA state machine. Every product must map its own source behaviour and customer commitments.
The design question is whether a state has a clear owner, a permitted next action and a customer-facing explanation.
Why snapshots matter
A later product update should not erase the price, conditions, seat or explanation shown when a customer made a choice. A snapshot gives operations a fair basis for explaining what happened.
It also prevents a current catalogue record from being mistaken for the historical booking contract.
Technical view
Model state changes as traceable events and distinguish current source status from the state communicated to the customer. Idempotent handling, durable references and careful payment/delivery boundaries help avoid ambiguous recovery work.
A history is useful only if it can be read in the context of the action that produced it.
Product and UX view
Confirmation should explain what is known now, what will follow and where a customer can find the record. It should not pretend that a pending supplier result is final.
Clear after-sales messages reduce uncertainty because they align the interface with the actual operational state.
Operations view
An admin or operations view should put customer-visible information, source state, change history and the next safe action together. The goal is not a crowded dashboard; it is a reliable starting point for an exception.
Exception paths deserve early design because they are where customer trust and operating cost meet.
SORADA viewpoint
K-Booking and K-Operations meet in the record left after commitment. A good booking architecture keeps the decision, the result and the subsequent work legible to the same team.
PRACTICAL TAKEAWAYS
Questions to carry into the next design.
- Design booking as a durable record.
- Make state meaning and ownership explicit.
- Build exception handling before it becomes urgent.
CHECKPOINTS
- Can the record show the price and conditions accepted at booking time?
- Is source status distinguished from customer-facing status?
- Can an operator see history and the next safe action together?
- Are pending, change and cancellation paths designed before release?
COMMON MISSTEPS
- Making the confirmation screen the end of the design.
- Overwriting historical booking facts with current product data.
- Giving operations only a raw supplier reference with no customer context.
CONTINUE READING
FIELD GUIDE 01
From Global API to a Real Booking Service
Supplier connectivity is the beginning of a booking product, not its finish line.Read insight →
FIELD GUIDE 02