How can airlines achieve real value from Offer, Order, Settle, and Deliver (OOSD) without waiting years for a full system overhaul? What role does modularity play in helping airlines capture incremental wins while still managing legacy systems? And how can the industry balance the need for new standards and seamless digital experiences with the reality of complex integrations and customer expectations?
Recently, Sam Chamberlain, Chief Product Officer at FLYR, joined T2RL Talks with Deputy CEO Bert Craven and VP of Airline Retail Keith Martin to discuss the airline industry’s “long and winding road” to Offer, Order, Settle, and Deliver.
Listen or read below. Visit the FLYR for airlines page to learn more about our solutions for modular retailing.
Bert Craven: Hello and welcome to the latest edition of T2RL Talks. I’m Bert Craven, Deputy CEO here at T2RL. In a break from our normal programming, instead of the dulcet tones and smooth stylings of Ian Tunnicliffe, you’ve got me. The only consolation I can offer is that I’m joined by Keith Martin, our VP of Airline Retail, and Sam Chamberlain, Chief Product Officer at FLYR. So, hello to both of you.
This week Keith and I are going to be talking to Sam about FLYR’s long and winding road to Offer, Order, Settle, and Deliver.
If we pick up on the first keyword there—long—we’ve talked many times on this podcast about the fact that the journey to Offer and Order, Settle, and Deliver is going to be a long one. It’s potentially a three-to-five-year business transformation. And while that may sound daunting, that’s not actually unusual for the airline industry, is it, Sam? You’ve been around the industry for many years, so I’m presuming those timescales don’t daunt you at all.
Sam Chamberlain: They don’t—it’s absolutely normal, quote unquote. But what that also implies is that it’s going to take airlines that amount of time, or even longer, to really start to get value out of the transition to Offer and Order. And I think that means there’s probably another avenue to explore: whether something can be done on a shorter timescale to bring value sooner, while still understanding that the transition to fully displacing a PSS will take time.
Keith Martin: How can airlines really get that value from OOSD capabilities in a timeframe shorter than those long-term years? They want to see quarterly change, right? And importantly, how can they ensure that these efforts won’t be wasted as the transition progresses? How do they get those quick wins?
Taking a modular approach to transformation
Sam Chamberlain: That’s a really good question, Keith. I think we have to change how we look at this. In the past, we thought about going from one PSS to another, or these major commercial initiatives where you rip and replace a large piece of the technology ecosystem. That still applies, but instead of this “big thing to new big thing” approach, you probably have to think about how the two worlds can coexist for a period of time.
That coexistence means new technology and solutions that make up the Offer, Order, Settle, and Deliver ecosystem live alongside the traditional PSS for a while. That allows airlines to start capturing incremental value from technology that links with the PSS. You can think of it as: take a short step to get some value in a reasonable timeframe, then another step, and another. With the final step being the “grand prize”—no longer needing the traditional PSS, because you’ve taken incremental steps over time and now have everything you need in the Offer, Order, Settle, and Deliver world.
Bert Craven: So this notion of incremental earned value, incremental transitions, and coexistence—it sounds like the fabled modularity of Offer and Order solutions is pretty critical in achieving that, right?
Sam Chamberlain: Absolutely. Vendors and airlines alike have talked about the importance of modularity for a while. Everyone agrees that avoiding “open heart surgery” is better—being able to collect pieces from your vendor or vendors of choice. The point of modularity is that the airline can pick and choose where those pieces come from.
At FLYR, at least, we don’t have those legacy concerns around balancing PSS investment with new development. We can look at it from a clean-sheet, greenfield perspective: focus on making modular pieces work, and then figure out how that integrates with what the airline already has.
Bert Craven: Yeah, but there’s making modular pieces work, then making your own modular pieces work together, and then making your modular pieces work with other people’s modules. What’s your approach to that? Because we’re in a new world here, and there’s a need for new standards. The advantage of the monolith was that it had one big perimeter. Now it feels like we’ve got a lot of little jigsaw pieces that still need defining.
Building new standards for integration
Sam Chamberlain: Yeah, that’s absolutely true. We sometimes make it sound minimized or simplified by saying “modularity wins” and that’s all we need to think about. But the devil is in the detail, that’s for sure. IATA and the airline community are trying to adhere to certain standards that will make this happen as seamlessly as possible. But, as we build the Offer and Order ecosystem at FLYR, we’re seeing that it isn’t enough. Either it’s not defined adequately, or it’s not robust, or it hasn’t been thought through. It’s relatively easy to sit in front of design or mockup software and say, “Well, I think an integration architecture should look like this, so that’s what the standard should be.” But when you actually come to build it, you realize there are lots of little things that weren’t considered.
That requires vendors and airlines to create or evolve those standards. We’re already seeing that happen. A good example is order accounting. Moving away from revenue accounting to order accounting brings a lot of complexity. While there are reference frameworks and standards, they’re certainly not complete. One path is that we, as a vendor leading in this space, can help frame new standards, push them into the community, and see them evolve. Or, we can try to make things as open and simple as possible so one piece of software can connect with another—whether that’s through open APIs, open source solutions, or other approaches.
We need to simplify as much as possible, but I’ll be the last person to say integrations and integration complexity aren’t important. I’ve been burned enough times to know they’re painful and real. But there are ways we can lead the charge together and create evolving standards that make it work.
“…the Legacy Translator is crucial…Airlines don’t need to know how EDIFACT or teletype messages are being translated, or how they manifest as orders. They should just know the process is seamless in the background.”
– Sam Chamberlain
Bert Craven: Yeah, and FLYR is one of the organizations doing this for real with customers—building actual hybrid architecture. So when you talk about all of these little things, this isn’t anticipatory. This is stuff you’re solving today in the real world, right?
Sam Chamberlain: Absolutely. And some of this involves unexpected “no-nos” that pop up. For example, implementing our Offer and Order Management System with a third party providing intelligence. Not because we aren’t provisioning that capability, but because we’re open to the airline saying, “I want my optimization and intelligence from this vendor, but I want my core offer orchestration and order management from you.”
So we went into it knowing our first foray would have modularity. That was fine—we expected to plug in different pieces. But again, you get into the detail and discover something isn’t defined. Then there’s a bit of back-and-forth: one vendor thinks it should be done one way, another thinks it should be done differently. Having the airline in the middle is a good thing. We can look at it from a value and use-case perspective: what are we actually trying to achieve for the airline? What’s the most replicable and scalable solution for this airline and the next, and the next? From there, we come to consensus.
So far, that’s working quite well. We haven’t had any extreme “my way or the highway” scenarios. Probably because everyone has the same objective—making this work.
Enabling backwards compatibility with legacy systems
Bert Craven: We’ve talked about new modules, but one big challenge—something airlines are very focused on—is maintaining interfaces and backward compatibility with legacy standards. The challenge is defining new standards and unlocking new capabilities, while still talking back to EDIFACT environments and so on. How have you found that? Because it sounds particularly tough.
Sam Chamberlain: It is tough. We describe our approach as a kind of “silver bullet” or magic piece of the ecosystem. Of course, it’s not really magic, but it bridges old and new. Our version of that software is called the Legacy Translator. You might also hear it called a document bridge, document exchange, or standards exchange. It creates the interfaces to handle legacy EDIFACT standards, teletype messaging, or whatever’s needed for legacy GDS distribution or interline codeshare connectivity. Then it marries that perfectly with the order data model and the offer data model, so information can synchronize and flow both ways.
It really is a little bit magic in that it makes it seamless. Even if an airline says, “I’m going to do a full transition away. I’m not going to do this in a modular way. I’m going to shed the PSS, and move fully to Offer and Order,” they’ll still have to deal with interline codeshare partnerships. Unless they forgo all distribution methods, they’ll still live partly in the old world. They can’t just choose to live only in the new one.
That middle piece—the Legacy Translator—is crucial. Somewhere deep in that box, a ticket might still be created to allow a passenger to through-check and travel on an interline journey, and for settlement to happen. That’s the magic of marrying old and new while hiding the complexity. Airlines don’t need to know how EDIFACT or teletype messages are being translated, or how they manifest as orders. They should just know the process is seamless in the background.
Bert Craven: Interesting. Keith, I know in your work with customers, a key focus has been identifying scenarios and use cases for cost savings, incremental revenue, and so on. Can you give examples of that—what airlines are looking for in terms of early earned value or incremental value?
Keith Martin: Yeah. Airlines beginning this transformation know it’s going to be long, complex, and costly. They’ll be running parallel worlds. So building the business case for whichever transition path they take is extremely important. Each airline is different depending on their maturity level—whether it’s NDC, dynamic pricing, or different prep levels for moving toward OOSD. But the business case is key.
I’d be curious, Sam, what you think in terms of cost-saving or revenue-generating use cases—what airlines can take advantage of before completing the transition from the current PSS.
Adding value with incremental use cases
Sam Chamberlain: Yeah, absolutely. I just explained a little about how important a Legacy Translator is and how all this technology comes together. But there’s no point going through these transitions for technology’s sake. It’s nice to have a shiny box that does something new, but unless it’s reducing costs, driving revenue, or improving the passenger experience—or ideally a combination of those—it’s a moot point.
So at FLYR, we’ve gone to market asking: how can you take an incremental use case from the Offer and Order, Settle and Deliver ecosystem on top of your PSS to either reduce costs or drive value? That’s how you build a business case. And it’s not an isolated business case. You take one, get some value, then take another, and another. You build incremental value step by step over time.
What I’m going to say next may sound simple, like candy-aisle shopping or plug-and-play. But for example, we’d work with an airline to ask: what’s the most important thing for you to explore next? Maybe personalization—continuous pricing, personalized product creation, experimentation. There’s been a lot of research and activity there, so that might be the first use case. We’d then ask: what components from this toolkit enable that, and what value can we expect? Fortunately, for that type of use case, there’s been a lot of work done in recent years on the value of continuous and dynamic product creation.
“Offer and Order should let you sell whatever you want, however you want, through any channel, with whatever flexibility. That means architecting a system not constrained to flights.”
– Sam Chamberlain
But the next airline might say, “I’m in a joint venture or a group, and the most important thing right now is a consistent brand offering across carriers, with seamless cross-retailing of products.” Not just selling an entire itinerary, but being able to seamlessly sell seat selection on the partner carrier.
Another airline might say, “Our brand is built around loyalty, and we want to sell and apply loyalty to third-party products beyond the fare.” The good thing is that underpinning this is a relatively small set of products—often enabled by a new kind of digital shopping cart. They can say, “I’ll take this one first, here’s the value. Next, I want to move to a consolidated order model across channels, which makes seamless servicing a reality and reduces cost and pain.”
So the sequence is a bit “pick and choose your own journey.” But we work with the airline to recommend a logical order, the value they’ll see, and the business case. If it doesn’t work, then there’s no justification.
Solving for complex dependencies through modularity
Bert Craven: Have you found there’s a secret to doing things in isolation—small experiments? In my experience, that’s really challenging. You try to change one thing in one channel for one set of customers, and it’s like trying to move one Christmas tree light: the whole thing wants to move. By the time you trace it through the system, your “one change” has become a huge project. Have you found good tips or tricks for creating those isolated experiments?
Sam Chamberlain: That’s a really good analogy. And it’s true—this world is so complex that you can’t touch one thing without ripple effects up and down the chain. But we don’t have to worry about PSS implications for ourselves. We’ve built modular solutions to tackle small opportunities with minimal disruption, while still tying everything back to the PSS or PNR.
We’ve put a lot of thought into seamless synchronization—with the PNR, the DCS, order or revenue accounting, and all the inputs and outputs. That way, when something changes, it’s reflected perfectly in the source of truth, which—while the PSS is in place—is still the PNR.
For example, we might implement an advanced, flexible shopping cart that allows non-homogeneous orders. You could book a flight from London to New York and meet a friend flying from Madrid, and it’s all in one order. That can’t break anything. The integration with the PSS has to handle it—so maybe that’s two PNRs, which we marry together and represent in one order, then service independently if needed.
The more use cases we think of, the more we trace end to end what the implications are—right from product creation and ideation of what the airline wants to sell, through to servicing, post-delivery, and settlement. We ask: which part of the ecosystem does this touch, and how can we simplify and minimize the ripple effects?
I’ll go on record and say there will be some use cases where you just can’t make it work. It’s too complex, or there are too many dependencies, and you can’t avoid breaking something. In those cases, we have to think about how two pieces of the puzzle need to be solved together with modularity. For example, we can give you this use case, but you’ll need both an engine that dynamically predicts product bundles and a change in your digital experience to handle it.
So we look at the whole picture. Whether we provide it ourselves or it comes through partners and other vendors, we make sure the airline knows: this is everything you need to think about.
Transforming the digital experience for customers
Bert Craven: Yeah. And that’s key when you talk about the digital experience, because in almost every case, the last piece of technology before the customer’s eyes is separate from the Offer and Order Management System. Simply changing the OOMS doesn’t change the customer experience. So how have airlines been approaching the UX challenge—educating customers that, by the way, you can now add two completely different itineraries to the same booking? Is that going to result in very different booking flows?
“It’s good to talk about ideas, but what matters is proving them. And there’s no better proof than launching a new airline with no dependency on a legacy PSS.”
– Sam Chamberlain
Sam Chamberlain: Yeah, it’s something that we’re exploring in a lot of detail with design and user experience partners right now. What does a future-state shopping experience look like for airlines that are selling in a completely different way than in the past? There are two parts to this. One is: what does that experience look like? And that sounds like a whole new digital experience. The other is: what if the airline wants this capability, but not a complete replacement of the digital experience right now?
There are tricks and ways to add side-loaded digital experiences—that’s how we refer to it—that let you step out of your current digital loop temporarily to solve the problem, then come back in to complete the transaction. That can be made seamless. The passenger wouldn’t know they were in a different experience, except now they’ve got something extra they can do to their advantage. It’s branded seamlessly for the airline.
If the airline wants, as part of their transformation, to replace their digital experience, that’s fine. That’s just another piece of the puzzle. What we don’t want is to say, “Here are all the benefits from those example use cases, we’ve installed everything, we’ve handled the plumbing—now you’re on your own to figure out digital.” That would mean another project taking another year, and time to value goes out the window. The whole idea with modularity is reducing that timeframe and allowing you to get value much sooner.
So the proposal is: you don’t need to do a complete rip-and-replace of the front end. Here’s how you can complement or supplement it in a seamless way. If you want to replace it later, you can.
Shopping cart flexibility and lessons from e-commerce
Bert Craven: Is there now a sort of decoupling between the notion of the order and the cart? In the sense that I could have a shopping experience on an airline’s website where in my cart I’ve got an extra bag added to one trip, I’ve booked another trip, and all of those sit in one cart. But when I click checkout and pay, everything is neatly arranged into the correct order structures. Is that where we’re headed?
Sam Chamberlain: Yeah, there’s nothing stopping that kind of flexibility. Consumers might not even realize it today, because everyone’s conditioned to buy airfare and travel products in the same way, and it hasn’t evolved much. But when they shop on Amazon, Walmart, wherever, they know how a digital cart works—save my cart, come back later, finish on my iPad instead of my desktop. That flexibility will come to the travel ecosystem and the airline world.
Now, whether that means reconciling multiple orders or not is no longer a technology question. It’s about what the airline wants to allow and what kind of experience they want to give. There’s nothing in the architecture that prohibits it.
We’ve said this before: a product is a product. Offer and Order should let you sell whatever you want, however you want, through any channel, with whatever flexibility. That means architecting a system not constrained to flights, not constrained to “all pieces must be bought and sold together.” A lot of inspiration comes from digital retail outside aviation—things that already work well, but haven’t applied to travel because of legacy constraints.
Bert Craven: You used an interesting phrase there—breaking the conditioning of users who’ve come to expect airline and travel products to be sold in a very specific way. And Keith, you’ve had years of experience in retail both outside and inside airline. Is this like a light bulb going off for you, like this is what you’ve been talking about all along? Does it feel like the right kind of progress?
Keith Martin: Yeah, absolutely. Online retail e-commerce is still far ahead of what airlines use today. And we’re all using it every day—Uber, Amazon, as Sam said—complicated products boiled down into very simple customer-facing processes. There’s now an expectation from airlines willing to invest and take the risk of transformation: to bring that same level of customer experience to their own customers.
We’ve already got proof in the wider retail world—it’s worked well for a long time. We’re still waiting for proof from airline IT vendors.
Sam Chamberlain: Yeah, you said proof, and “the proof is in the pudding” is never more applicable than here.
From big ideas to proof—in 18 months
Bert Craven: That’s what everyone wants to know, Sam: when are we going to see it?
Sam Chamberlain: Exactly. It’s good to talk about ideas, but what matters is proving them. And there’s no better proof than launching a new airline with no dependency on a legacy PSS. Over the last 18 months we’ve gone from some base solutions to production-ready software that can handle this end to end.
Just a week ago—on August 2—we demonstrated, in a production-like environment, the first truly digital-native Offer and Order transaction end to end on a mobile device. A passenger shopped with a flexible cart, added products, paid, and then came back to service them.
It worked. We’ve got the timestamp of that first transaction, which means all the components came together—optimized pricing, offer orchestration, catalog selection, inventory decrementing, order creation and management, distribution of order-related messages—all seamlessly.
We’re going to launch this in production later this year. And in just over a month, at Engage, I’ll be excited to share how we made it happen and what the last 18 months have really looked like.
Bert Craven: Yeah, I’m really looking forward to it. Hopefully by then some of us will have experienced the live booking and spoken to the carrier about the ecosystem. No pressure, but the world is watching with bated breath. I’m really looking forward to the conference.
This is a great segue to talk about T2RL Engage 2025, coming up 22–24 September in London, at a fantastic venue next to St Paul’s Cathedral. We already have a huge contingent of vendors and airlines registered. And as Sam said, FLYR will be there to talk more about their journey with a real customer doing real bookings. It feels like a turning point, like traction.
Thank you, Sam, for coming along and talking to us today about FLYR’s long and winding road. Thank you, Keith, for the extra perspective. It’s been great talking to you both. See you in September.
Sam Chamberlain: Thanks, Bert.
