.webp)
In this issue, Ben Waymark tackles the hard questions on Order-led delivery: how to manage service lifecycle states, resolve conflicts between systems, handle disruptions without PNR-era queues, and what it takes to run day one in a hybrid airline environment.
In the first three issues of this Service Delivery FAQ series, we've covered the shift from PNR-based operations to Order-based service delivery, exploring what 'delivery with Orders' means in practice and why it's better than legacy approaches. We've looked at how airlines can start this transition even with legacy PSS systems, how 'ready-to-fly' status flows from DCS to Orders, and how services are passed to operational systems. We've examined baggage handling, ad-hoc interlining, rich media in shopping flows, and the practical benefits airlines are already seeing, from improved customer servicing to real-time visibility and faster ancillary upsells. We've also explored how carriers handle service delivery status across interline journeys, ensuring consistent views without needing direct system integrations between carriers.
Now we're tackling the harder questions: how do you maintain control when things go wrong? How do you define truth when systems disagree? And what does it actually take to run Order-led delivery from day one?
What is the delivery lifecycle per Order item, and what are the non-negotiable status transitions?
Each Order item has a service (flight, seat, bag, meal, etc.) that follows a defined delivery lifecycle. This lifecycle is tracked through status updates exchanged between the Order Management System (OMS), Delivery Management System (DMS) – Departure Control (DCS) is a function of a DMS – and delivery providers. We need a practical state model that covers all the critical stages—check-in, boarded, delivered, failed delivery, substituted, refunded, compensated, and partial fulfilment.
At the moment, this isn't very well defined by IATA, but ideally, we need to move towards something like this:
Created: Entitlement is reserved in the Order but not yet delivered.
Ready for delivery: The customer is eligible to consume the service (e.g. they can check in or drop their bag).
Checked-in: Departure Control confirms check-in. Seat is assigned, bag is accepted, and so on.
Boarded: Passenger physically boards and the service (e.g. flight) begins.
Delivered: Service has been consumed. Passenger has travelled, bag has been transported, meal has been served.
Failed delivery: The service wasn't delivered (e.g. no-show, technical issue, rejected bag).
Substituted: The original service was swapped for something else (e.g. new seat type, rerouted flight).
Refunded: Undelivered service is cancelled and refunded.
Compensated: Monetary or service-based compensation is granted for service failure.
Partially fulfilled: A portion of the service was delivered (e.g. partial journey completed, or only one of two bags loaded).
These transitions should be reflected in ServiceStatusChangeNotif messages and recorded in the Order's audit trail. This model supports rich disruption handling without reverting to artefact reissuance.
Who owns the truth when Delivery, Order management and partners disagree?
When multiple systems are involved, conflicts are inevitable. So we need to be clear about which system originates which events, how conflicts get resolved, and what the audit record looks like.
In the Order-led model:
- OMS is the system of record for entitlements and their status. It determines what was offered, confirmed, cancelled, substituted or refunded.
- DMS/Departure Control originates operational events like check-in, boarding and load status. These are communicated back via ServiceStatusChangeNotif.
- Delivery providers (such as ground handlers) also contribute status updates, for example, lounge access delivered or bag weight confirmed.
- Delivery Management System (DMS) will provide departure control functionalities along with these delivery provider statuses.
Conflict resolution follows this hierarchy:
- If a service isn't marked as delivered in the OMS, it's considered undelivered, regardless of what the Departure Control (DC/DCS) logs say.
- If the OMS has received a status update from a trusted source (DC or partner), that becomes the canonical truth.
- Discrepancies are logged and flagged for manual or automated resolution workflows.
The audit record is centralised in the Order and contains all status updates with source system, timestamp and event details. This enables full traceability and dispute management.
How does disruption management work in an Order-led delivery model without PNR-era queues?
Let's walk through a complete end-to-end scenario to see how it works in practice. We'll cover a misconnect with baggage complications, re-accommodation, seat reassignment, ancillary carry-over, and customer messaging, tracking what updates are at each step.
- Misconnect: Passenger arrives late and misses their connection. DC sends ServiceStatusChangeNotif to the OMS saying: Flight not boarded.
- Re-accommodation: OMS triggers a re-shop flow via OrderReshop to offer new routing options. Customer selects their new flight.
- Seat reassignment: The new seat is part of the re-accommodation Offer and gets updated in the Order via OrderChange.
- Ancillary carry-over: Valid ancillaries (like a pre-paid meal) are reassigned or refunded based on mapping logic.
- Baggage: The bag is already loaded on the original flight. The bag tracking system updates the OMS, which flags the mismatch.
- Customer messaging: OMS initiates messaging via push notification or agent workflow, sending the new itinerary and updates.
- Compensation (if needed): If the customer downgrades or loses a service, OrderChange or OrderQuote reflects the adjustment, and a refund or voucher is issued.
All updates are reflected in the Order in real time. No queueing or manual synchronisation is required between ticketing, reservation or inventory systems.
How do we handle partial delivery, service substitution and compensation without recreating tickets and EMDs?
The key question here is how you represent fulfilment, failure and remedy directly in the Order without falling back into creating new artefacts under a different name.
There's no need to recreate tickets or EMDs. The Order record handles everything:
- Partial delivery: Each Order item has its own delivery status. If part of a journey is flown or a service is only partially consumed, that's logged separately.
- Substitution: The Order shows which service was replaced and what it was replaced with. For example: seat 12A replaced by 14C, with a refund issued if the value differs.
- Compensation: This is reflected as a new Order item (like a voucher), an adjustment to the total paid, or a value store attached to the Order.
All events are logged with status updates (ServiceStatusChangeNotif), audit trail entries and, where applicable, OrderChange actions. Refunds, penalties or goodwill gestures are embedded directly in the Order; no duplicate artefacts required.
What are the minimum integrations and controls to run Order-led delivery in a hybrid airline?
For an airline running a hybrid model (Order-based front end with legacy systems in the back), you need to define the minimum viable set of interfaces and controls. This includes event ingestion, entitlement checks, exception handling and shared 'ready-to-fly' semantics.
Here's what that looks like:
Event ingestion: Your OMS must receive events from DCS, baggage systems, lounges, catering and check-in via ServiceStatusChangeNotif.
Entitlement checks: Delivery systems need to query the OMS (or receive push ServiceDeliveryNotif messages) to verify what should be delivered.
Exception handling: Your OMS should handle error responses and conflict flags (like when a bag is delivered but the Order has been cancelled).
Shared 'ready-to-fly' semantics: All delivery systems must align on Order-led definitions of 'checked-in', 'boarded' and 'delivered'.
Fallback process: You need the ability to log or override status manually via agent tools, whilst maintaining Order audit integrity.
This setup lets you support NDC and ONE Order fulfilment on top of legacy infrastructure, whilst progressively decoupling from PSS dependencies.
Author
