Why is it still easier to buy a phone online in one click than to change a flight online after a booking, without having to phone a contact center, trigger a ticket reissue, or see systems fight each other about what you actually ordered? Anyone who’s ever had to integrate airline retail and servicing systems knows that, when you scratch beneath the surface of a smooth customer experience, you find a reality where customer data is often represented across multiple records, and multiple system lifecycles. This makes something as simple as “add one bag, keep one seat” surprisingly hard to get right. multiple records multiple system lifecycles The push to 100% Offers and Orders is a bet that airlines, and eventually all transportation providers, are now able to think and act like retailers, making Offers, taking Orders, and servicing those Orders across distribution, delivery, and accounting systems alike. 100% Offers and Orders Offers Orders This is a practical, engineering-led introduction to implementing an Offer & ONE Order ‘happy path’ airline reservation system, which can be extended to rail and ground transportation too. Offer & ONE Order We'll look at: What’s hard for airlines today, and how Offer & Order, and ONE Order, address those challenges A practical reference architecture, rather than a nice idea How to implement a first vertical slice, including one Offer, one Order How to chunk a large change program into more digestible pieces, and retire legacy systems safely The hardest problems (performance, servicing, interline, finance) and patterns to solve them What’s hard for airlines today, and how Offer & Order, and ONE Order, address those challenges A practical reference architecture, rather than a nice idea How to implement a first vertical slice, including one Offer, one Order one Offer, one Order How to chunk a large change program into more digestible pieces, and retire legacy systems safely The hardest problems (performance, servicing, interline, finance) and patterns to solve them (To keep this realistic, I will use a “composite airline” example based on general industry patterns and publicly available standards documentation, rather than specific implementations.) To keep this realistic, I will use a “composite airline” example based on general industry patterns and publicly available standards documentation, rather than specific implementations. The uncomfortable truth: airlines are not “retailing” yet; they are reconciling The uncomfortable truth: airlines are not “retailing” yet; they are reconciling Airline IT infrastructure was built to perform best in a world where: A fare is filed, not computed Distribution happens through legacy channels with payload constraints A booking record is not the purchase record Ancillaries are added after the fact A fare is filed, not computed Distribution happens through legacy channels with payload constraints A booking record is not the purchase record Ancillaries are added after the fact Airlines have traditionally had different IT infrastructure evolution paths. Instead of having a single purchase record, there are multiple artifacts and concepts that were introduced during the era of process design. Even today, in 2026, the industry still has to live with constructs that were introduced during the paper era. According to IATA’s ONE Order Factsheet, the vision for ONE Order is to “simplify the industry by consolidating PNRs, e-tickets, and EMDs into a single unified record - the Order - removing inefficiencies inherited from paper-based processes to ensure improved communication between order management, revenue accounting, and delivery.” consolidating PNRs, e-tickets, and EMDs into a single unified record - the Order From an engineering perspective, this is not a “format change.” This is a domain model change. domain model change And this is a contentious issue for good reasons: From an engineering perspective: “Is this a big rewrite?” “Will we be locked in?” From a distribution perspective: “Are we ready?” “Is the ecosystem ready?” From a finance perspective: “Settlement?” “Auditability?” “Revenue recognition?” From an operations perspective: "How will disruptions be handled?" “Airport delivery?” From an engineering perspective: “Is this a big rewrite?” “Will we be locked in?” From a distribution perspective: “Are we ready?” “Is the ecosystem ready?” From a finance perspective: “Settlement?” “Auditability?” “Revenue recognition?” From an operations perspective: "How will disruptions be handled?" “Airport delivery?” These are legitimate concerns - Offer/Order is not a system; it is a process transformation. Offer/Order is not a system process transformation This is evident from IATA’s definition of ONE Order: The objective of ONE Order is to facilitate a simplified reservation, delivery, and accounting process by progressively replacing existing booking, delivery, and accounting records such as PNRs, e-tickets, and EMDs with a single record for retail and customers. progressively replacing PNRs, e-tickets, EMDs That’s important because duplication is not just ‘messy’; it’s costly and risky: Servicing is reconciliation. You don’t ‘change an order’; you ‘synchronize multiple documents.’ Customer support is archaeology. Agents and systems search for references across systems. Finance is brittle. Ticket/EMD-based systems aren’t naturally aligned with modern retail bundles, non-air content, or dynamic changes. Servicing is reconciliation. You don’t ‘change an order’; you ‘synchronize multiple documents.’ Servicing is reconciliation Customer support is archaeology. Agents and systems search for references across systems. Customer support is archaeology Finance is brittle. Ticket/EMD-based systems aren’t naturally aligned with modern retail bundles, non-air content, or dynamic changes. Finance is brittle That’s why airline ecommerce can appear like ‘a front-end rewrite over a legacy truth.’ It may look modern, but still function like a document processing system. What IATA means by Offer/Order (and where NDC and ONE Order fit) What IATA means by Offer/Order (and where NDC and ONE Order fit) There’s a lot of jargon in the airline ecommerce space, so let’s clarify the important bits: Offer Offer An Offer is a priced, sellable offer created for the customer in the context of route, dates, availability, customer attributes, loyalty, channel, etc. Offer It’s similar to an ecommerce cart offer: It includes items (flight, seat, bag, bundle, lounge, carbon offset, etc.). It includes pricing, conditions, and an expiry/validity window. It’s transient; you should expect an Offer to expire or change. It includes items (flight, seat, bag, bundle, lounge, carbon offset, etc.). It includes pricing, conditions, and an expiry/validity window. It’s transient; you should expect an Offer to expire or change. Order Order An Order is the single source of truth for what the customer bought, what they’re entitled to consume, over the lifecycle of the trip. Order ONE Order’s central idea is exactly that: take the ‘legacy booking/ticketing’ elements and merge them into one Order. NDC (distribution with Offers and Orders) NDC (distribution with Offers and Orders) The IATA NDC standard defines the distribution protocol that enables Offer/Order to be used throughout the distribution chain via an API. According to the NDC Factsheet: “…the NDC standard enables sellers to shop, order, pay, and service using Offer and Order processes.” NDC shop, order, pay, and service Modern Airline Retailing (the larger narrative) Modern Airline Retailing (the larger narrative) IATA defines the larger narrative of Modern Airline Retailing as follows: “Modern Airline Retailing is the larger narrative of the journey to modern retailing, supported by NDC, ONE Order, and other standards… to move away from legacy artifacts to a world of ‘100% Offers and Orders.’” A reference architecture for an Offer/Order-based reservation system A reference architecture for an Offer/Order-based reservation system Here’s a simple architecture that should work for airlines and can be extrapolated to rail/ground transport as well. Core Domains (Bounded Contexts) Core Domains (Bounded Contexts) Product Catalog & Merchandising Defines products (fare families, bundles, seats, bags, WiFi, upgrades, etc.) Owns content, eligibility rules, sellability constraints Pricing Computes prices, promotions, taxes/fees Supports continuous/dynamic pricing strategies (even if filed fares are used) Availability & Inventory Seat inventory, O&D controls, capacity management, waitlists “Reserve” vs “commit” semantics Offer Management Combines products + prices + availability to create Offers Issues Offer IDs, TTLs, terms/conditions references Order Management (ONE Order-aligned) Stores Orders, Order Items, services/entitlements, Order States Owns servicing (change, cancel, refund, split/merge scenarios) Payments & Risk Auth/capture/refund Fraud detection, 3DS, wallet support Delivery/Fulfillment Check-in/DCS integration, vouchers/credentials Accounting & Settlement Revenue accounting, invoicing Settlement mechanisms (eventually aligned to Orders) Product Catalog & Merchandising Defines products (fare families, bundles, seats, bags, WiFi, upgrades, etc.) Owns content, eligibility rules, sellability constraints Product Catalog & Merchandising Product Catalog & Merchandising Defines products (fare families, bundles, seats, bags, WiFi, upgrades, etc.) Owns content, eligibility rules, sellability constraints Defines products (fare families, bundles, seats, bags, WiFi, upgrades, etc.) Owns content, eligibility rules, sellability constraints Pricing Computes prices, promotions, taxes/fees Supports continuous/dynamic pricing strategies (even if filed fares are used) Pricing Pricing Computes prices, promotions, taxes/fees Supports continuous/dynamic pricing strategies (even if filed fares are used) Computes prices, promotions, taxes/fees Supports continuous/dynamic pricing strategies (even if filed fares are used) Availability & Inventory Seat inventory, O&D controls, capacity management, waitlists “Reserve” vs “commit” semantics Availability & Inventory Availability & Inventory Seat inventory, O&D controls, capacity management, waitlists “Reserve” vs “commit” semantics Seat inventory, O&D controls, capacity management, waitlists “Reserve” vs “commit” semantics Offer Management Combines products + prices + availability to create Offers Issues Offer IDs, TTLs, terms/conditions references Offer Management Offer Management Combines products + prices + availability to create Offers Issues Offer IDs, TTLs, terms/conditions references Combines products + prices + availability to create Offers Issues Offer IDs, TTLs, terms/conditions references Order Management (ONE Order-aligned) Stores Orders, Order Items, services/entitlements, Order States Owns servicing (change, cancel, refund, split/merge scenarios) Order Management (ONE Order-aligned) Order Management (ONE Order-aligned) Stores Orders, Order Items, services/entitlements, Order States Owns servicing (change, cancel, refund, split/merge scenarios) Stores Orders, Order Items, services/entitlements, Order States Owns servicing (change, cancel, refund, split/merge scenarios) Payments & Risk Auth/capture/refund Fraud detection, 3DS, wallet support Payments & Risk Payments & Risk Auth/capture/refund Fraud detection, 3DS, wallet support Auth/capture/refund Fraud detection, 3DS, wallet support Delivery/Fulfillment Check-in/DCS integration, vouchers/credentials Delivery/Fulfillment Delivery/Fulfillment Check-in/DCS integration, vouchers/credentials Check-in/DCS integration, vouchers/credentials Accounting & Settlement Revenue accounting, invoicing Settlement mechanisms (eventually aligned to Orders) Accounting & Settlement Accounting & Settlement Revenue accounting, invoicing Settlement mechanisms (eventually aligned to Orders) Revenue accounting, invoicing Settlement mechanisms (eventually aligned to Orders) Cross-cutting capabilities to design early Cross-cutting capabilities to design early Identity/customer context (loyalty, corp policy, digital identity alignment to follow) Observability & audit (very important for finance and servicing teams) Eventing (OrderCreated, OrderPaid, OrderChanged, etc.) Identity/customer context (loyalty, corp policy, digital identity alignment to follow) Observability & audit (very important for finance and servicing teams) Eventing (OrderCreated, OrderPaid, OrderChanged, etc.) Integration principle Integration principle The “retail layer” should remain decoupled You can implement Offers/Orders as a retailing layer around the original PSS components, at least initially, using adapters. This is how you avoid the “catastrophic replacement of everything at once” scenario. Reason why the architecture is applicable to rail, ground transport, etc. Reason why the architecture is applicable to rail, ground transport, etc. Rail, ground transport, etc. are also inventory + entitlement businesses. Inventory could be seat inventory, zone inventory, capacity inventory, etc. Entitlement could be QR code, gate, driver, etc. However, the overall “Offer -> Order -> Deliver -> Service -> Refund” process is the same. Inventory could be seat inventory, zone inventory, capacity inventory, etc. Entitlement could be QR code, gate, driver, etc. However, the overall “Offer -> Order -> Deliver -> Service -> Refund” process is the same. The difference is operational delivery, not the model. Implementing the first vertical slice: one Offer -> one Order Implementing the first vertical slice: one Offer -> one Order You can’t possibly “do ONE Order” across all the scenarios. It’s not possible. The way to win is to deliver a thin but complete way through the system. thin but complete Step 0: pick a narrow “happy path” Pick something boring. Single airline, no interline/codeshare. One way One passenger, ADT Card payment No exchanges, Cancellation allowed Minimal ancillaries e.g., one bag Single airline, no interline/codeshare. One way One passenger, ADT Card payment No exchanges, Cancellation allowed Minimal ancillaries e.g., one bag It’s not that you’re compromising. It’s that you’re building the extensibility. Step 1: define your internal domain model (don’t start with XML) NDC is based on XML. Which means your internal systems don’t have to be. A good way forward: You can model your Offers, Orders using a language-native domain model. JSON, protobuf, POJOs. You can provide mappers from/to NDC messages. You can model your Offers, Orders using a language-native domain model. JSON, protobuf, POJOs. language-native domain model You can provide mappers from/to NDC messages. mappers You’re optimizing for evolvability, not a schema tree. Step 2: implement Offer creation Offer creation flow Offer creation flow POST /offers/search with origin, destination, dates, pax, cabin preferences. Offer service calls: Availability: “what can I sell?” Pricing: “what price should I quote?” Catalog: “what products/bundles are eligible?” Return one or more Offers with: offerId expiresAt list of offerItems total price + breakdown POST /offers/search with origin, destination, dates, pax, cabin preferences. POST /offers/search with origin, destination, dates, pax, cabin preferences. Offer service calls: Availability: “what can I sell?” Pricing: “what price should I quote?” Catalog: “what products/bundles are eligible?” Offer service calls: Availability: “what can I sell?” Pricing: “what price should I quote?” Catalog: “what products/bundles are eligible?” Availability: “what can I sell?” Pricing: “what price should I quote?” Catalog: “what products/bundles are eligible?” Return one or more Offers with: offerId expiresAt list of offerItems total price + breakdown Return one or more Offers with: offerId expiresAt list of offerItems total price + breakdown offerId offerId expiresAt expiresAt list of offerItems list of offerItems total price + breakdown total price + breakdown Example internal Offer (simplified) Example internal Offer (simplified) { "offerId": "OFF-7F3A9C", "expiresAt": "2026-01-02T12:05:00Z", "passengers": [{ "paxId": "P1", "ptc": "ADT" }], "items": [ { "offerItemId": "OI-1", "type": "AIR", "segments": [{ "from": "FRA", "to": "BCN", "dep": "2026-02-12T09:10:00Z" }], "termsRef": "TNC-BASE-ECO", "price": { "currency": "EUR", "total": "189.90" } }, { "offerItemId": "OI-2", "type": "ANCILLARY", "service": "CHECKED_BAG_1", "price": { "currency": "EUR", "total": "25.00" } } ], "total": { "currency": "EUR", "total": "214.90" } } { "offerId": "OFF-7F3A9C", "expiresAt": "2026-01-02T12:05:00Z", "passengers": [{ "paxId": "P1", "ptc": "ADT" }], "items": [ { "offerItemId": "OI-1", "type": "AIR", "segments": [{ "from": "FRA", "to": "BCN", "dep": "2026-02-12T09:10:00Z" }], "termsRef": "TNC-BASE-ECO", "price": { "currency": "EUR", "total": "189.90" } }, { "offerItemId": "OI-2", "type": "ANCILLARY", "service": "CHECKED_BAG_1", "price": { "currency": "EUR", "total": "25.00" } } ], "total": { "currency": "EUR", "total": "214.90" } } Key engineering decisions you should make early: Offer TTLs: treat Offers as quotes with expiry. Idempotency: every offer search should be idempotent-friendly (especially for retried requests). Offer “fingerprint”: store enough context to revalidate quickly. Offer TTLs: treat Offers as quotes with expiry. Offer TTLs: treat Offers as quotes with expiry. Offer TTLs: Idempotency: every offer search should be idempotent-friendly (especially for retried requests). Idempotency: every offer search should be idempotent-friendly (especially for retried requests). Idempotency: Offer “fingerprint”: store enough context to revalidate quickly. Offer “fingerprint”: store enough context to revalidate quickly. Offer “fingerprint”: Step 3: implement Order creation (ONE Order-style “single record”) Order creation flow Order creation flow Client submits selected Offer Items: POST /orders with offerId + offerItemIds + passenger details + payment method. Order service runs a saga: Revalidate Offer (TTL, price, eligibility) Reserve inventory (temporary hold) Authorize payment Commit order Confirm inventory Trigger fulfillment (during migration this may mean “issue ticket/EMD downstream”) Client submits selected Offer Items: POST /orders with offerId + offerItemIds + passenger details + payment method. Client submits selected Offer Items: POST /orders with offerId + offerItemIds + passenger details + payment method. POST /orders with offerId + offerItemIds + passenger details + payment method. Order service runs a saga: Revalidate Offer (TTL, price, eligibility) Reserve inventory (temporary hold) Authorize payment Commit order Confirm inventory Trigger fulfillment (during migration this may mean “issue ticket/EMD downstream”) Order service runs a saga: Revalidate Offer (TTL, price, eligibility) Reserve inventory (temporary hold) Authorize payment Commit order Confirm inventory Trigger fulfillment (during migration this may mean “issue ticket/EMD downstream”) Revalidate Offer (TTL, price, eligibility) Reserve inventory (temporary hold) Authorize payment Commit order Confirm inventory Trigger fulfillment (during migration this may mean “issue ticket/EMD downstream”) Example internal Order (simplified) Example internal Order (simplified) { "orderId": "ORD-91B2E1", "status": "CONFIRMED", "customer": { "name": "A. Traveler", "email": "a@example.com" }, "orderItems": [ { "orderItemId": "IT-1", "fromOfferItemId": "OI-1", "status": "ACTIVE" }, { "orderItemId": "IT-2", "fromOfferItemId": "OI-2", "status": "ACTIVE" } ], "payments": [ { "paymentId": "PAY-77", "status": "AUTHORIZED", "amount": { "currency": "EUR", "total": "214.90" } } ], "entitlements": [ { "type": "FLIGHT", "segmentRef": "S1" }, { "type": "SERVICE", "code": "CHECKED_BAG_1" } ] } { "orderId": "ORD-91B2E1", "status": "CONFIRMED", "customer": { "name": "A. Traveler", "email": "a@example.com" }, "orderItems": [ { "orderItemId": "IT-1", "fromOfferItemId": "OI-1", "status": "ACTIVE" }, { "orderItemId": "IT-2", "fromOfferItemId": "OI-2", "status": "ACTIVE" } ], "payments": [ { "paymentId": "PAY-77", "status": "AUTHORIZED", "amount": { "currency": "EUR", "total": "214.90" } } ], "entitlements": [ { "type": "FLIGHT", "segmentRef": "S1" }, { "type": "SERVICE", "code": "CHECKED_BAG_1" } ] } This matches the ONE Order intent – one record of entitlements, eliminating duplication. Step 4: bridge to legacy (without letting legacy own your model) The not-negotiable truth is that most airlines can’t switch off legacy operational delivery and accounting in one go. So, what does this mean? The migration pattern that works is: Order is the source of truth Legacy records (PNR/ticket/EMD or equivalents) are derived artifacts, created only when required by downstream systems Order is the source of truth Order is the source of truth Legacy records (PNR/ticket/EMD or equivalents) are derived artifacts, created only when required by downstream systems This is consistent with IATA’s goal to phase out legacy records in favor of a single order record. In other words, create an Order to Legacy Adapter: Order to Legacy Adapter Translate Order Items into downstream issuance steps Store these mappings (orderId to legacy references) Make it replayable (what if downstream fails?) Translate Order Items into downstream issuance steps Store these mappings (orderId to legacy references) Make it replayable (what if downstream fails?) Over time, shrink this adapter as more issuance and accounting become native to Orders. Step 5: implement minimal servicing First, implement these minimum servicing APIs: GET /orders/{orderId} POST /orders/{orderId}/cancel (with refund rules) POST /orders/{orderId}/add-service (add bag/seat) GET /orders/{orderId} POST /orders/{orderId}/cancel (with refund rules) POST /orders/{orderId}/add-service (add bag/seat) Servicing is where all the complexity will come – so start with one or two to prove the flow. Making “the big bang” into tangible projects Making “the big bang” into tangible projects What does a transformation plan look like? It’s a sequence of individually valuable projects: Domain model + API façade Define Offer/Order canonical model and API contracts. Map to NDC at the edge. Offer creation for one channel Start with direct web/mobile. Add basic ancillaries. Order store as the source of truth Create/read Orders. Start emitting events (OrderCreated, OrderPaid, OrderCancelled). Payments + refund automation Move refunds from manual queues into deterministic workflows. Order servicing expansion Add change flows, partial cancels, split orders. Operational integration DCS delivery hooks, disruption workflows. Finance integration Revenue accounting and settlement processes aligned to Orders. Partner distribution and interline Expand to agencies and interline/codeshare once the core is stable. Domain model + API façade Define Offer/Order canonical model and API contracts. Map to NDC at the edge. Domain model + API façade Domain model + API façade Define Offer/Order canonical model and API contracts. Map to NDC at the edge. Define Offer/Order canonical model and API contracts. Map to NDC at the edge. Offer creation for one channel Start with direct web/mobile. Add basic ancillaries. Offer creation for one channel Offer creation for one channel Start with direct web/mobile. Add basic ancillaries. Start with direct web/mobile. Add basic ancillaries. Order store as the source of truth Create/read Orders. Start emitting events (OrderCreated, OrderPaid, OrderCancelled). Order store as the source of truth Order store as the source of truth Create/read Orders. Start emitting events (OrderCreated, OrderPaid, OrderCancelled). Create/read Orders. Start emitting events (OrderCreated, OrderPaid, OrderCancelled). Payments + refund automation Move refunds from manual queues into deterministic workflows. Payments + refund automation Payments + refund automation Move refunds from manual queues into deterministic workflows. Move refunds from manual queues into deterministic workflows. Order servicing expansion Add change flows, partial cancels, split orders. Order servicing expansion Order servicing expansion Add change flows, partial cancels, split orders. Add change flows, partial cancels, split orders. Operational integration DCS delivery hooks, disruption workflows. Operational integration Operational integration DCS delivery hooks, disruption workflows. DCS delivery hooks, disruption workflows. Finance integration Revenue accounting and settlement processes aligned to Orders. Finance integration Finance integration Revenue accounting and settlement processes aligned to Orders. Revenue accounting and settlement processes aligned to Orders. Partner distribution and interline Expand to agencies and interline/codeshare once the core is stable. Partner distribution and interline Partner distribution and interline Expand to agencies and interline/codeshare once the core is stable. Expand to agencies and interline/codeshare once the core is stable. This is the “strangler” approach: new capabilities grow around legacy until legacy becomes a small compatibility layer. Key challenges airlines hit (and how to solve them) Key challenges airlines hit (and how to solve them) 1) Look-to-book and performance: Offers are expensive to compute Dynamic offer generation can trigger huge search volumes and strain systems. IATA’s Look-to-Book white paper explicitly calls out a surge in search volumes that drives up LTB ratios and strains systems, costs, and customer experience. Patterns to use: Two-tier caching: cache “market” availability/pricing, then personalize at the edge Offer-to-order metrics: measure CPU-to-order, offer-to-order, not just requests/sec Rate limits with graceful degradation: don’t fail; return fewer offers, longer TTLs, or precomputed bundles Two-tier caching: cache “market” availability/pricing, then personalize at the edge Two-tier caching: Offer-to-order metrics: measure CPU-to-order, offer-to-order, not just requests/sec Offer-to-order metrics: Rate limits with graceful degradation: don’t fail; return fewer offers, longer TTLs, or precomputed bundles Rate limits with graceful degradation: 2) Consistency between offer pricing and order creation Problem: your Offer is computed at time t, but at time t+30s inventory, taxes, or promotions change. Problem: Solutions: Solutions: Put a validity window on Offers. Reprice on order creation with explicit rules: “Honor price if within TTL and inventory unchanged” vs “always reprice.” Use inventory holds with clear expiration and idempotent commit. Put a validity window on Offers. Reprice on order creation with explicit rules: “Honor price if within TTL and inventory unchanged” vs “always reprice.” “Honor price if within TTL and inventory unchanged” vs “always reprice.” “Honor price if within TTL and inventory unchanged” vs “always reprice.” Use inventory holds with clear expiration and idempotent commit. 3) Servicing complexity replaces ticketing complexity - if you don’t design it Problem: If you model Orders like “a PNR, but renamed,” servicing ends up being a nightmare. Problem: Solutions: Solutions: Servicing should be state changes on Order Items (ACTIVE, CHANGED, CANCELLED, REFUNDED). Immutable financial data (payments, refunds) and deltas from events. Sagas for servicing changes: reserve, price, pay delta, commit. Servicing should be state changes on Order Items (ACTIVE, CHANGED, CANCELLED, REFUNDED). Immutable financial data (payments, refunds) and deltas from events. Sagas for servicing changes: reserve, price, pay delta, commit. 4) Transition pain: you still need legacy artifacts Problem: You can’t change airports, interline partners, and accounting practices in an instant. Problem: Solutions: Solutions: Legacy issuance should be downstream and replaceable: “Order first, then derive ticket/EMD where required.” Build a reconciliation dashboard early on: Order vs PNR vs ticket vs EMD mapping Status and failure replays Legacy issuance should be downstream and replaceable: “Order first, then derive ticket/EMD where required.” “Order first, then derive ticket/EMD where required.” “Order first, then derive ticket/EMD where required.” Build a reconciliation dashboard early on: Order vs PNR vs ticket vs EMD mapping Status and failure replays Order vs PNR vs ticket vs EMD mapping Status and failure replays Order vs PNR vs ticket vs EMD mapping Status and failure replays 5) Ecosystem interoperability Problem: Even after you agree on a profile, you may not know how your trading partners will implement it. And the whole industry ecosystem is affected by the rollout of ONE Order (PSS suppliers, travel agents, GDSs, and even non-air players like rail, hotel, car rental). Problem: Solutions: Solutions: Choose a profile and commit to it (what you support, and what you don’t). Versioning of your APIs. Provide “capabilities discovery” endpoints to support your trading partners. Choose a profile and commit to it (what you support, and what you don’t). Versioning of your APIs. Provide “capabilities discovery” endpoints to support your trading partners. 6) Organizational design becomes a technical dependency Problem: Offers/Orders span distribution, revenue management, servicing, and financials. Problem: Solutions: Solutions: Think of this as a product transformation, not an API project. Own the Offer/Order within a single organizational structure (business and technology). How to measure success: conversion rate, attach rate, change cost, refund cycle, call deflection Think of this as a product transformation, not an API project. Own the Offer/Order within a single organizational structure (business and technology). How to measure success: conversion rate, attach rate, change cost, refund cycle, call deflection Why this approach extends beyond airlines (rail, ground, and multimodal) Why this approach extends beyond airlines (rail, ground, and multimodal) The Offer/Order model is not “airline-only.” It’s retailing applied to transport: Rail: seat + fare families + onboard services = Offer; ticket + seat + meal entitlement = Order. Ground transport: route + baggage + priority boarding = Offer; QR credential + entitlement list = Order. Multimodal: a single Order can represent entitlements across operators - if you design Order Items and fulfillment boundaries cleanly. Rail: seat + fare families + onboard services = Offer; ticket + seat + meal entitlement = Order. Rail: Ground transport: route + baggage + priority boarding = Offer; QR credential + entitlement list = Order. Ground transport: Multimodal: a single Order can represent entitlements across operators - if you design Order Items and fulfillment boundaries cleanly. Multimodal: And as a side note, IATA itself points out that “modern retailing with Offers and Orders” has a “broader industry implication” that “extends beyond airlines to include rail and other non-air services.” The takeaway here should be that you shouldn’t “implement IATA.” Instead, you should “implement commerce” with IATA as a guiding star The takeaway here should be that you shouldn’t “implement IATA.” Instead, you should “implement commerce” with IATA as a guiding star The pitfall here is that people think that Offer/Order is a standards-compliance exercise. The opportunity here is that Offer/Order can be a way for you to achieve: One Offer engine that can personalize and bundle. One Order record that can eliminate record-sync failures and make servicing sane. One way to achieve ecommerce-grade experiences across channels and partners. One Offer engine that can personalize and bundle. Offer One Order record that can eliminate record-sync failures and make servicing sane. Order One way to achieve ecommerce-grade experiences across channels and partners. ecommerce-grade experiences So yes, start with one Offer and one Order. Make that real. Then grow from there Because once you achieve that one Order that can be the truth, all other “modernization initiatives” such as payments, disruption handling, interline, finance, etc. finally have “something” to orbit Note that this article only scratches the surface of implementing IATA Offer/Order and ONE Order. In a real-life airline, there can be many differences in architecture, data model, process, and migration depending on many factors such as detailed business needs, regulatory requirements, commercial models, partner ecosystems (such as interline/codeshare), and airline-specific operational realities. Note that this article only scratches the surface of implementing IATA Offer/Order and ONE Order. In a real-life airline, there can be many differences in architecture, data model, process, and migration depending on many factors such as detailed business needs, regulatory requirements, commercial models, partner ecosystems (such as interline/codeshare), and airline-specific operational realities. Note
