How service delivery actually works when both models are live
We have a new issue for airline teams living in the messy middle. Most carriers still run a traditional booking record (Passenger Name Record, or PNR) while starting to look into selling and delivering with Orders.
“We know Orders are coming, but we still run our operation on PNRs and tickets. What does that actually change in service delivery?”
On the day of operation, both models are in play. Service delivery has to make sense of that reality.
This edition brings three things: answers to some of your questions, concrete builds with partners that show Offers, Orders and Delivery working together, and a few points to add to your roadmap.
Let’s dive into it.
Service delivery FAQ: from PNRs to Orders
We turned the questions we kept hearing from airline teams into a short FAQ. In plain terms, it covers:
- How delivery with Orders differs from delivery with PNRs and tickets
- What it means to pick a “source of truth” for a journey when both models exist
- Where legacy documents still matter, and where they can be produced on demand
- How to measure progress by recovery time and promises kept, rather than by the number of screens
Read: Service Delivery FAQ – from PNRs to Orders
How Offers, Orders and Delivery are working together
IATA’s Airline Retailing Consortium asked a simple question: Can Offers and Orders run across multiple providers in real systems, while airlines are still using PNRs? The ‘Modularity in Action’ programme moved that question from slides to working systems integrations.
Within that initiative, there are a few examples that matter if you are responsible for service delivery.
From Offer to Delivery without PSS – Ink, Datalex, PROS
In this proof-of-concept, Datalex handles offer creation and order management, PROS provides pricing, and Ink runs delivery at the airport.
- Offers are built and priced in the retail layer
- Orders hold what has been sold, with clear entitlements
- Delivery reads that same order, executes check-in and ancillary fulfilment, then writes back status
A traditional Passenger Service System is not driving the flow. That leaves the airline free to add or change components without restarting the whole stack, and it keeps the path open for PNRs and Orders to run side by side during transition.
Direct-channel orders that reach the airport – Ink and FLYR
Proof-of-concept that Ink and FLYR run keeps flows smooth:
- FLYR handles Offer and Order: shopping, pricing, order creation and lifecycle
- Ink handles Delivery: airport processes, ancillary fulfilment and delivery status
How it works. Travellers shop and buy; FLYR creates the order. That order is then available to Ink at the airport. Agents prepare the journey, move seats, add extras, and those actions update the same order record in real time. There is no separate “airport copy” of the truth.
Three points are worth noting:
- Delivery is more than departure control. Do not lock fulfilment behind a single airport system.
- Order management is part of departure control. Both teams need a clear agreement on who updates which states and when.
- Operations will push back until they see work removed, not just moved. The build has to make their day easier.
Read: Direct-channel orders that reach the airport – Ink and FLYR
Riyadh Air: greenfield delivery in a hybrid world
Riyadh Air is a new airline, not a legacy carrier working through a cutover. From day one, its delivery layer has to operate in a world where partners, airports, and regulators still speak legacy “languages” (PNRs, tickets, traditional messages).
Ink Delivery Management is designed to sit in that middle ground: it supports Riyadh Air’s own order-centric model while still communicating cleanly with legacy systems where required. The result is not “an airline in transition”, but a greenfield operation designed to work across both sides of the industry for as long as that hybrid reality lasts.
Read: Offer and Order enablement through modularity
What this means for your roadmap
You do not need another concept piece. You need a few clear choices.
- Start from the journeys, not the systems. For each flow, decide which record is the operational reference. If an order exists, let it be the primary source for entitlements and status.
- Keep both identifiers usable. Staff should be able to retrieve by PNR-style reference or Order ID without running two separate processes.
- Treat legacy documents as outputs. Many partners and authorities still need them, but they do not have to dictate how you run your delivery.*
- Design for more than one provider. Assume that Offer, Order, and Delivery may not all reside on the same platform. Use clear interfaces so you can change one element without re-wiring everything.
*There’s, however, one question to raise.
In OOSD (Offer Order Settle Delivery), every order must include an Order ID and may optionally include a six-character alphanumeric Booking ID, which can be used in place of a traditional PNR. While this Booking ID functions similarly to a PNR, it is not itself a PNR, as it does not inherit the structural constraints typically applied to PNRs; however, it still provides a compliant booking reference required by many governments’ APIS regulations, as well as BSM and other messaging standards that depend on a six-character identifier. Most flights, especially international services, will require such a reference. Still, an open question remains regarding whether these Booking IDs must eventually follow traditional PNR rules, such as ensuring that all passengers share the same cabin class or the same origin and destination, in order to avoid issues or flags raised by downstream systems.
We’ll share more thoughts on the following issues.
Author
