In this weekly FAQ series, Ink experts will explore how airlines transition to Modern Airline Retailing, sharing what it means for service delivery, the changes involved, and the practical steps that make the shift smooth.
In Issue 1, we talked about the move from PNR and ticket-based fulfilment to Orders.
In this FAQ, Victor Alzate, Chief Product Officer, and Ben Waymark, VP of Product Architecture, cover how your operational systems talk to your Order system. Who tells you that a customer is ready to fly, how that status comes back into the Order, and what happens to baggage in that process.
We focus on five questions:
- How will “Ready to Fly” work across carriers; is it DCS or Order driven?
- Does “checked in and did not show” differ from “did not check in and did not show” for refunds?
- What does “multiple delivery management systems per service” mean in practice?
- How are services delivered from Orders into DCS and other operational systems?
What about baggage; is it ready for modern platforms like BIX?
Q. How will “Ready to Fly” work across carriers; is it DCS or Order driven?
First, terms:
- DCS - Departure Control System, the system that runs check-in, boarding, seat assignment at the airport.
- DMS - Delivery Management System, the system that includes lounge gates, departure control, where you manage minimum connection times and baggage retrieval as well as all the functions of a DCS.
- DC - Departure Control module within DMS system, which executes legacy DCS functions
- OrMS - Order Management System, the system that stores the Order, services and their status.
- Retailer - the airline or partner that sells the offer to the customer and owns the Order.
- Supplier - the airline that operates the flight.
In a retailer and supplier set up, the retailer owns the Order, but the supplier runs the flight. Supplier’s DCS or DMS is the system that knows:
- Who has checked in
- Who has cleared required checks
- Who has been accepted for travel and boarded
However, “Ready to Fly” must also be visible in the retailer’s OrMS, because it drives:
- What the customer sees in the app or portal
- Whether a service is treated as delivered for refund and revenue rules
- What is reported to partners and in settlement
So the split is:
- Supplier DCS / DC is the source of operational truth at the airport
- Supplier OrMS is the supplier’s record of the Order
- Retailer OrMS is the retailer’s record of the same Order
A workable model looks like this:
So the answer to “DCS or OrMS” is:
- The event starts in the supplier DCS / DC
- The “source of truth” for the airline’s products and services is OrMS
- “Ready to Fly” should not be a Departure Control only concept that never reaches the Order
When a supplier does not yet have a proper OrMS, you can put a small integration layer in between, which listens to Departure Control events and turns them into Order updates for the retailer. Long term, though, you want DC talking to OrMS, and OrMS talking to OrMS between airlines.
Q. Does “checked in and did not show” differ from “did not check in and did not show” for refunds?
Yes, it should. If your process does not distinguish them today, your policy is blunt.
There are two basic situations:
Scenario 1. The customer checked in, but did not board.
- The airline held the seat
- Operational work started: bags might be checked, catering loaded, security lists updated
- Late changes can disrupt the flight
Scenario 2. The customer never checked in, and did not show.
- There is less operational work
- The seat might be released earlier
- You have less cost and disruption
In an Order-based model, you can track per service:
- Check-in status
- Boarding status
- Whether related services like baggage or seats were actually delivered
- When these events happened
That means refund and voucher rules can look at:
- “Did they check in”
- “Did they board”
- “Which services were actually delivered”
Instead of a blunt “ticket used or not used”, you have more precise options:
- No check in and no show - permit partial credits on some services.
- Checked in and no show - stricter rules, because you have actually delivered part of the service.
So if your refund tool still ignores check-in and delivery status, that is now a conscious choice, not a hard system limit of Orders.
Q. What does “multiple delivery management systems per service” mean in practice?
In plain language: one service can be delivered by several systems.
Take a simple case:
A passenger flies from A to B. They have one cabin bag, one checked bag, one paid seat, and lounge access.
Even for that trip, several operational systems are involved:
- Departure Control handles check-in and boarding
- A baggage system or DMS module manages the checked bag
- A seat management or DMS module manages seat assignments
- A lounge system validates access
- Catering or a pre-order meal system may prepare special meals
In the PNR (Passenger Name Record) world, you glue this together with:
- PNR elements and SSRs (Special Service Requests)
- Tickets and EMDs (Electronic Miscellaneous Documents)
- Many custom point-to-point integrations
In an Order world, the idea is different:
- OrMS holds the full picture of the Order and its services
- Each delivery system only needs to see the parts that it has to deliver
So “multiple delivery management systems per service” means:
- A single service in the Order, for example, “checked bag for passenger 1 on flight 123”, can be seen and updated by several systems.
- They all talk to OrMS, not directly to each other.
- OrMS is the place that keeps the history and current status.
That stops every system from inventing its own partial truth about what was delivered.
Q. How are services delivered from Orders into Departure Control and other operational systems?
Today, for many airlines, tickets and coupons drive delivery. Departure Control and baggage systems look at ticket status and PNR remarks.
In an Order-based setup, delivery is driven from the Order. OrMS knows:
- Who the travellers are
- Which flights and services they have bought
- What the rules are for change, refund and delivery
The flow then looks like this.
- Order created and stored in OrMS. OrMS has the passengers, flights, seats, baggage, ancillaries, conditions and payments.
- Operational systems ask what to deliver, or are told. There are two patterns:
- Pull - DCS/DMS asks OrMS, “what do I need to deliver for this passenger or this flight”
- Push - OrMS sends “here is what you must deliver” to DCS/DMS or another system when certain triggers occur, for example, when check-in opens
- Operational systems report back on what happened.
Examples:- DCS/DC sends “passenger checked in”, “passenger boarded”, “seat changed”.
- Baggage system sends “bag tagged with number X”, “bag loaded”, “bag missed connection”.
- Lounge system sends “customer used lounge at time Y”.
- OrMS updates the Order and shares that state. OrMS takes those events, updates the Order, and then:
- Updates the customer app or website.
- Feeds revenue and accounting.
- Drives rebooking, disruption handling and later analytics.
Instead of operational events being locked inside each local system, they are tied back to the Order. That is what “delivery with Orders” means in practice.
Q. What about baggage; is it ready for modern platforms like BIX?
Baggage is messy today mainly because:
- Baggage systems often work on their own databases and messages
- The link between a bag and the product that was sold is weak
- Partners struggle to share a clear picture across airlines
In an Order-based world, the data model already supports what baggage needs:
- It can describe baggage allowances, both by piece and by weight
- It can handle baggage for several passengers on one trip
- It can store services such as extra bags or special items as clear products.
- It can link bags to specific passengers and flights
For a platform like BIX (Baggage Information Exchange), the advantage is:
- Instead of guessing from tickets and PNRs, it can read from Orders which bags are permitted, paid and expected
- It can send events, for example, “bag loaded” or “bag delayed”, back into OrMS
- OrMS can then show accurate baggage status to customers and partners
The main limitation now is not the standard itself. It is adoption:
- Airlines need to wire baggage platforms into the same event flow as Departure Control
- Vendors need to accept Orders and services as inputs, not only legacy baggage messages
If your baggage upgrade plan does not consider Orders and OrMS at all, you are just refreshing the user interface of a silo, not fixing the integration problem.
Why Departure Control and baggage systems need to talk to Orders
This is the unglamorous part of Offers and Orders, but it is where risk and value sit.
If you ignore it and just “wrap” your old flows:
- Refund rules will stay blunt, because they cannot see what really happened per service
- Arguments with partners will continue, because nobody shares a clean record of delivery
- Your teams will keep doing manual work, reading DCS screens and PNRs, then keying decisions into an “Order” front end
If you do the hard work:
- “Ready to Fly” has a clear meaning, shared between DCS/DMS and OrMS across carriers
- Refund and revenue logic can use real service status instead of guesses
- Baggage, lounge, and partner systems can talk to Orders without waiting for a full system replacement
Your choice: either Orders become the place where the truth of delivery lives, or they become a thin skin on top of the same old fragmentation.
Author
