On demand | Elevate 2022
Creating @ play: Dynamic offer creation tools for today and the future
One of the hottest games of the season? Dynamic offers! But for airlines, getting to true continuous pricing is a long and complicated question. Dual RBD is ATPCO’s answer to how you can create more price points without heavy investment—over 50 airlines are already using this method to achieve a high score.
You’ll also hear about other initiatives the Dynamic Offers Design Team is putting into play such as the Product Catalogue and a solution to integrate dynamic prices into existing end-to-end processes. It’s time to level up the industry!
Melanie: Welcome. I'm going to just start with that I am very, very excited to be here and very excited to see all of you. And if you think I'm just like making that up, ask anyone in this room that knows me. I find this subject exciting and I get really, really excited when we can talk about industry solutions. So welcome. Thank you so much for staying for the last or almost the last session of the day. I really appreciate seeing you all here and joining us on this journey to dynamic offer creation.
My name is Melanie Dezelak. As you can see on the screen, my primary job at ATPCO now is on dynamic offers and I co-lead the Dynamic Offers Design Team with my colleague Daphne, who you saw earlier today on the stage. I forgot my little clicker.
As with any sensitive material that ATPCO discusses in any of our design teams, we throw up our legal disclaimer and we usually read it to you. Today, I'm going to take a moment and I'm going to ask that everyone of you in the room take a moment to read the legal disclaimer so we understand what we are and are not allowed to discuss, and I will pause a moment. All right. That give you enough time to read through? Okay. Thank you very much.
All right, so we are here to talk about dynamic offers and some of the initiatives that ATPCO is undertaking. So as you all heard earlier in the conference, we have a goal to get to 80% dynamic offers by 2026. And that is a very lofty goal. However, it's one that we feel very positive that we can do provided we do it together. This is going to be a journey that we undertake as an industry to come up with solutions to move us from that bottom left quadrant to that top right quadrant. So I know you've seen this diagram, you've seen the capability matrix before. What I want to call to your attention on the screen here is what ATPCO is doing currently and what we have coming soon in the future as our first set of initiatives towards dynamic offer creation.
The first item that we're going to look at and we'll spend a brief amount of time on it, I promise, is dual RBD validation. As many of you know, this already exists in the market today. Airlines are already making use of this and this was our real first initiative to offer airlines the ability to create more price points and step into dynamic offers.
The next two initiatives that we want to talk about are what we're doing to help the transition. What we're doing to help the airlines that are now transitioning into dynamic adjustments where they're taking ATPCO fare data and they're adjusting the amount and they need to help this flow through some of the current processes again as they move from that bottom left to the top right. And these two initiatives are enhanced distribution and the Airline Order Posting. So we'll take a look at those today as well.
And then lastly, we have initiatives that we're doing to move us into that continuous pricing in that top right quadrant. And these are initiatives creating new data sources, first of all, with web fares integration and secondly with shopping insights. And those two initiatives are being led by my colleague Daphne, who's in the back of the room here, who I hope you've all met and seen earlier today.
And then our last initial set is the Product Catalogue and we've all heard a lot about a Product Catalogue, very rightly. This morning we heard that there's not enough industry definition and a real explanation around how we see that working and what it is. So we'll talk about that. Today though, we have a short amount of time. We're only talking about four of the initiatives, we'll do dual RBD, enhanced distribution, Airline Order Posting, and Product Catalogue.
I will pause if anyone wants to take a seat. We have several open seats at the front and we have a few here if you don't want to stand. I think there's like four, five in this row.
All right, so as you can imagine, these four subjects are very detailed. I happen to enjoy detail. I find it fascinating. I know that some of you don't necessarily like all that detail, so what I'm going to try to do is keep this middle of the line. I won't go as in-depth as some of you may want, but I also won't be as high level as some of you may want. So bear with me. We'll try to be middle of the road so everyone gets enough information and if you don't have enough information, feel free to talk to me afterwards or I'm happy to set up a call with you to go through any of these in more depth. But it is detail heavy, it's a lot to cover, so we may not have time for questions. I'm going to apologize up front. I will stay late and talk to any of you if you want to discuss any of this. And again, I can set up a call if you want to go deep on any of these items. All right, let's get started.
So today, ATPCO does offer dual RBD validation. This is something that over 60 airlines are using today and they're seeing the benefits. And what is this, you might ask? Well, dual RBD validation allows an airline to offer more price points or create more price points simply by requiring availability into inventory classes. So that means it resolves that 26 character constraint, whereas today you can only have 26 price points based on the 26 letters of the alphabet. Using dual RBD validation allows you to open up more price points and it allows you to really kind of step into dynamic pricing. Depending on the use case that you introduce, you can optimize your yield, your upsells, you can improve your workflow efficiencies, you can better align your products so you've got better accuracy. And then as we've always said, this is your first step into dynamic pricing by creating more price points.
We see three main use cases, I will say these are not the only use cases for dual RBD, but these are the three main ones that we're seeing that we want to introduce you to and expose you to so you have a better idea of what you get with dual RBD validation.
The first use case is what we call upsell. This is the classic use case where you have a fare in one cabin that can book into another cabin. So you might have an economy fare that you can put out there as an upsell fare and allow the passenger to sit in first.
The second use, this is what we call lockstep, or this is where you can synchronize prices across brands. So you may have multiple brands either in the same cabin or in different cabins and you can synchronize those prices so that they move in lockstep. As you open and close inventory, the prices move in lockstep together.
And then lastly, there is the idea of creating a trigger class or a secondary class that's reserved and allows you to increase price points and expand the prices on that curve. We'll look at examples of each of these cases on the next few slides.
So the first one, upsell. As I said, this is really the classic example. This was the use case that came to ATPCO when we were first asked to create dual RBD validation. And in this example, we've shown we have economy class fares. We have H, Q, and V, where each of these fares also has an upsell fare, or kind of a sister fare if you will, that requires dual inventory validation. So for example, the passenger can buy an upsell fare, but the price of that upsell fare, that price of sitting in first and booking into A is based on the validation or the availability of that economy RBD. So for example, if we had V class closed, then you would be able to sell the Q economy fare for 250. Or you could sell the Q upsell fare for 400. And the $400 fare is available because it requires inventory validation in both A and Q. So the passenger sits in A, it's booked in A, but because Q is still available, they can buy that fare. Again, this is our most classic example and we do have multiple, a lot more information on this in our implementation guide if you require some more information.
The second use case is what we call lockstep or as we said, this is when you have multiple brands in the same cabin as in this example, and you want the prices to be synchronized across brands. So what we're showing in this example is hypothetically, you may have an economy cabin, you have three brands in economy. Let's say you have basic economy, you have I'll call it standard economy, and you have super economy. And you have all of your price points in basic and your price points in super are controlled based on the RBD of the economy. So that economy is what we call the anchor. There's no dual RBD validation in economy class. You've got the YMQHK&L hypothetically as your as your RBDs with their associated price points.
And then you have those economy RBDs are used as secondary RBDs in, let's say basic for example. So the basic economy sits, everything in basic is booked into X. You use one RBD to control basic economy and for booking, and you use the economy RBD, the six RBDs in economy to control the price point. So for example, if the economy RBDs of L&K, the two lower classes, are closed, then the basic economy is going to book into X, but it will be at the 675 fare, the $675 fare because K&L are closed, but H is still available. So you can see how the price point in basic is controlled with the RBD availability in economy.
[inaudible] No, the X class is still open and here we have the L and the K closed. And because the X is open and the H is open we can book into basic economy at 675. We have a very similar example with super economy where again, everything is super economy books into T and then the secondary RBD is the economy RBD and it controls the price point and super. So you can see here hypothetically for this example we've said, let's say basic economy is always $50 less and super economy is always $50 more and you keep those prices synchronized by the economy RBD being open or closed. This is again a hypothetical amount that we've used here. Obviously an airline could use a percentage, so you could have a percentage difference between the brands, you could have a different amount variation according to your own requirements. So we've just used this for an example.
And I do apologize, we aren't going to be taking any live questions today because we do have a full session, but we are happy to meet with everyone individually afterwards. [inaudible] I don't know the answer to that question. I will say I do a lot of individual sessions with airlines that want to introduce dual RBD and I use a lot of very similar slides and I'm happy to schedule a one-on-one session and we can really go through these in depth because we also have examples on how you could potentially set up your inventory and a lot more detail if you're interested.
All right. The next example is the same as the one we just looked at, but here we have brands across cabins. So here for example, we've said we have the economy brand as our anchor and the opening and closing of the RBD and economy is controlling your business and your first. So in this example, the economy RBDs are the secondary validation for business and the secondary validation for first, and that keeps those prices moving in lockstep.
I do want to kind of go back to this one, I made a note. In this example we've got, I'll move over here so you can see, we've got 19 price points here. So you can see there's 19 price points that we're using but we've got only eight RBDs in use. So even, the way this use case is being used is to keep the prices in lockstep, we're still opening up more price points using fewer RBD. So 19 price points only with eight RBDs and you'll see that same thing through all these examples. Same thing here in this one, we've got only one RBD for business, one RBD for first, and then we've got the three RBDs in economy and we're able to open up all these price points.
Again, we find this is very common for airlines if they want, especially with a passenger, transparency. If the passenger is always used to one brand being a certain amount or a percentage difference from another brand, it's very easy to keep them in step and it's easy for you to keep them accurate.
And then our last example, our last use case is where we create more price points using that secondary trigger class where we've reserved the trigger class. So the left side of the screen shows you your current structure where we have five RBDs and five price points. The right side of the screen shows, simply by introducing one more RBD, X, here we've used it as a reserved class. We're able to now have 10 price points using 6 RBDs and we're able to spread out, flatten out that curve a little bit.
Again, this is all in place today. You can already do this today. It's all in FareManager. For those of you that are used to coding and ATPCO’s FareManager it's in your RBD Chart 1. You simply use the application values B and D which allow you to say if the first RBD is available, then the second RBD is required or permitted. So the functionality is there today, it's implemented in the systems today and you can get started.
There are really no roadblocks to implementation, as long as you define your scope and you make sure that you've met your preconditions and assumptions. So for example, you need to make sure your shopping, your pricing, your order management systems can all handle two RBDs. You need to make sure your inventory system can handle the additional price points, make sure it can handle the structure that you set up. And then in terms of fare management, you want to make sure that you can identify fares that have dual RBD, because as you all know, in a fare basis code, we often use that first character for our primary RBD, but there's nothing to tell us what the secondary RBD is. So what we find is that most airlines are using the fare basis code taxonomy or that positional match to set aside a letter or character in the fare basis code to tell them that it was a dual RBD. So for example, a given airline might have position seven with a value A that says this was dual RBD validation in Q, for example. So it's something you need to consider, identifying the fares, making sure inventory management and your shopping, pricing, and order management can handle this.
Now if you're ready and you do want to move on and implement dual RBD, I do want to share, a lot of you may have been at Elevate 2019 and that was our last big conference together and we had an airline share their journey to dual RBD implementation. And I went back and looked at those slides. They had a really, really good quote, I thought, which said it was four months from idea to launch. That was four months from idea to launch, so from the time they sat in a room like this, four months later they had it all implemented. And in their example they used it to introduce premium economy and they used a single RBD for premium economy and they got it all in in four months.
So it's not a lengthy implementation as often in our industry, we do find it takes a while. This can be done relatively quickly. We have an implementation guide. It's on our website on MyATPCO. You can go ahead and download that if you want. A lot of the examples that I put in my slides are in the implementation guide, plus it has a lot more information if you're interested.
We also have training. Our training department already does dual RBD training in their instructor-led courses and they are going to be putting it into e-learning and I think this is really cool. In early 2023 they're going to do a two-hour virtual class on dual RBD validation. So I'd encourage you to take a look at that and then as always, if you need some help, if you just need help coding it or help getting started, you can contact Partner Services and we can help get you started. Like I said, I do a lot of 1-on- 1 sessions, so if you want to have just a bilateral discussion we can certainly do that as well and help you with any detailed questions you have for your particular use cases.
All right. That was exhausting.
But now, like now, we can be really excited because we're going to talk about what's coming next. And this is really what gets me excited because we're moving out of that bottom left corner now and we're moving up through that capability matrix. And we have a couple of enhancements that we are putting in place to help with that transition. As we heard from several of our speakers this morning, this is an evolution. This is something we're taking baby steps. We just need to get started. It's not at all, it's not a complete cutover. I loved what our what our friend from American Airlines said when he when he mentioned that we're not going to just shut off fares for a whole week and stop flying for a week so we can cut over to a new solution. We're going to transition, so we're going to have to keep the old in place with the new as we move into the future.
And the first way we're offering a solution is with what we've called enhanced distribution. So enhanced distribution is for airlines that have public tariff data. So that's public data. And they want to have that public data available for sale to any passenger, available for display to any passenger. But they want to control the distribution. So perhaps that data is only to be sold on their direct channel, or perhaps they only want it sold in their NDC channel, but it's still public data.
Now today ATPCO controls public data distribution and we assume that the data is sent to everyone. So today if I had an airline ask me, you know what? I really want to control the distribution of my public data and I only want to send it to certain subscribers for use in my direct channel. I would turn to my colleague. I'm going to call on her. Lyn Quillin's in the back of the room. Everyone look at Lyn, and Lyn would manually help the airline control their distribution, and I want to say that again, Lyn would manually help them with that distribution. So it's a manual process that we undertake for airlines that have these types of requirements. But what we're finding is more and more airlines want to control distribution of public data. So obviously Lyn is one person and she can't manually control distribution for 400 airlines. So we're looking at an automated solution.
But the reason that we, and I will say we worked on a POC already with an airline, to try to really understand their requirements and they were really doing this to help enable dynamic pricing, to help enable NDC, to really drive requests to their NDC channel, and to open up content on their direct channel. But they still wanted the data to be public because they had internal processes specific to public data that they wanted these fares to flow through and they still wanted to use the ATPCO fare and rule structures because this is a transition, they didn't want to throw away current structures and the rule validations, they just needed a set of data only for their direct channel or only for NDC that they could then play with. They could be a little bit flexible with this data and start looking at it and start seeing how they could have dynamic offers, maybe do some adjustments to the data, some swap out some attributes to adjust the price and so on. So we said, okay, let's look at our manual solution and see if we can automate it.
Again as I said with the POC we found three use cases though, we found the NDC, we found the direct and we also found airlines that have web fares. That said, hey, if I can control the distribution of these web fares, then maybe I'll put those into the ATPCO fare and rule structures and then everything's integrated and everything's in the same format.
So we looked at our current process and I talked to Lyn and she said in our current environment what happens is an airline has to first of all contact our support request portal. They can request an enhanced distribution or request some of this restricted distribution for existing tariffs and only for new rules. And then we had a few requirements in place. One is that the data has to go to one selling channel subscriber or basic subscriber. That's a public tariff requirement. And the second is that public data goes to all limited subscribers. So those are subscribers that use the data for revenue accounting and decision support and so on. So in other words, Lyn told me, this is still public data. All we're doing is controlling the distribution within these restrictions.
So when we look to automate it, we are looking at our enhancing our Data Distribution Control, or our DDC, and this is where my colleague Shelly comes in. I'm going to just wave to Shelly because she helped me with the DDC. And she let me know that we're going to enhance the DDC, but it's going to have a few caveats on it. So first of all, we're going to allow airlines to optionally restrict their public data. And I'm going to actually, that's optional. It's very important. We understand that you don't have to use this. You don't have to use this functionality. It's all optional for an airline if you choose to restrict public data distribution.
If you do go down that path, ATPCO will have edits that at least one selling channel subscriber or basic subscriber will receive the data. So a basic subscriber is a GDS or anyone that is doing shopping and pricings of that data. So I'll say I've looked at Sabre is a basic subscriber. Amadeus is a basic subscriber. I saw Accelya in here somewhere. There are basic subscribers. Those are examples of basic subscribers. You'll be able to go in and restrict distribution to those subscribers.
The data is still going to be public. It's still subject to all public tariff requirements. That means if it needs to be filed, it'll go through a government filing. Again, the selling channel has to receive it. All limited subscribers will still receive the data. It's viewable by anyone because it's public. And then any data processing standards or data application specific to public data will still apply. That means the receiving subscriber who gets that data will still treat it as public data. There's no change for them. We've simply controlled the distribution. Now that's our first phase.
Our second phase which we haven't looked at yet, is to look at the use rights. And this means the airlines have said, okay, now I want to control the distribution, but I want to tell the receiving system how they can use it. They said, you know what, I might give you the data, but you can only use it for changes and refunds. Or I might let you see the data but you can only use it for revenue accounting. So that would be our second step. So to our first steps to control the distribution, the second step is to look at the use rights.
Now we put out an Initial Solution here, a Milestone 2-3 if you want to take a look at the ATPCO Notifications. If you haven't already read it, you can take a look at the detailed solution and provide some feedback. We also included in that notification all of the public tariff requirements, so if you're curious about what all of the requirements are, has to go to a selling channel, still goes to all limited subscribers, must have a inventory at risk, has to go through government filing, if you're curious there, we've got a bullet item list of all the public tariff requirements that that you can see in the notification.
This is a kind of mock up. This is what our data distribution control looks like today. It's just to show you that this is what we'll be enhancing for public to allow you to control which of those selling channel subscribers can receive the data. And then this slide is for all of you that code ATPCO fare and rule data. So for those of you that don't, bear with me, but for those of you that do, this is really important. So take a peek here and make sure that we all understand this and if it's not clear, come have a chat with me.
So as I've said, this is public data. It will be treated as public data. That means the subscriber gets it and they think it's public data because it is. But today, we know that a lot of subscribers have a lot of different roles. So a single subscriber may be GDS, they may be your PSS system, they may provide your change and refunds, they might be an NDC platform, they may provide revenue accounting services. So the same subscriber may play a lot of roles. So when they receive that data, they don't know if there's anything limited on how they can use the data.
So what you need to do as an airline is you need to make sure that your sales restrictions or your Category 15 is coded to control the sale of the data. So that means I've given you a little example, it's hard to see, but in this, hypothetically, let's assume we have Airline XX. And let's assume Airline XX works with the basic subscriber, BBB. BBB is a GDS, they are XX’s PSS and they are also XX’s servicing system. And let's say that XX has data they want to limit public data distribution. They only want it available on their website xx.com and they have a pseudo city code defined for xx.com. And here we've said the code is right here, ABC123. So they will use ATPCO's new functionality. They will control the distribution of the data, but they also need to go into Cat 15 and indicate that sales are only permitted at pseudo city code ABC123 to make sure that the receiving GDS knows, you know what? This might be public data, but it can only be sold on the airline’s website.
So that's something to keep in mind. We've got to really keep that in sync, especially until we get to the day that we have use rights. Again, we ran a POC of this. The airline we tested it with actually had multiple subscribers involved that some were doing their PSS, some were doing their servicing, and they were able to make this work successfully just by making sure that the Cat 15 was coded correctly. Okay, so no more bits and bytes details but I wanted to make sure that anybody in the room knew that. All right.
So that was enhanced distribution. The other one coming, and this, they get even more exciting as we go along. Like, honestly, this one you heard about yesterday, this is Airline Order Posting and my boss, Tom Gregorson, told you about this from the stage yesterday. Oh my gosh, you're here. You make me nervous. Well see, now I'm going to stutter cause the boss is in the room.
All right. No, this one is seriously exciting. And we have been talking about this in our dynamic pricing working groups before they were dynamic offers design teams. We've been talking about it for a while. And this again is a really cool transition solution to help you move your way across the matrix and get to step into dynamic offers but it doesn't break all of your current internal systems. So what is it you might ask?
Well, it's going to help airlines today that are adjusting fares. So for example, the challenge that came to us is that there are airlines today, many of you that are taking an ATPCO fare and you're adjusting the amount at time of shopping. And so, so the fare’s filed, it's filed at a specific amount at it's shopping time based on any contextual business reasons you have, you might adjust the fare. The problem though is that downline systems such as changes and refunds, those servicing systems, they are dependent upon having a comprehensive database of all the fares in the market because they have to take the sale or ticket data and compare it to those historical fares. So you can see that if you adjusted the fare, then it's not in their database. They can't find the fare when they look at the ticket, they can't find what original, that original fare doesn't exist in their database. And it's not just a challenge with servicing, although that's the number one challenge we hear. It's also a challenge with any other downline system dependent on fare and rule data. So revenue accounting and settlement are two other really good examples.
So what we've done is we've said, hey, we can take a copy of your order, we can convert that into fare data structures, the current structures, and we can send that out to downline systems. So then those systems have not only your original fare, but they also have any of your adjusted fares and they can use that in any of their downline prices like changes and refunds.
And it's a really, really great solution, I think, because it allows an airline to get a step into dynamic offers. Take a bigger step now, because now you're adjusting the fare. Maybe you're even adding a ticket designator and you still don't have to change all of your downline systems. You don't have to do a huge costly investiture up front. So you're able to adjust fares, you can put dynamic prices out there, but the data still flows through the downline systems.
Also, we see it as offering a good place to test the transition. So it gives you a chance to really play with it and see how much data do I want to file upfront and pre file and how much, how many prices do I want to do through continuous pricing? So it enables you to say how much do I want here and how many, how often do I want to do it here, and you can figure out what works best for you as an airline without again without breaking your downline processes.
And then lastly we see this is going to lower industry cost in two ways. First of all, as I mentioned, you don't have to change your downline systems right away. They can work as they do today. You can work on that, you can get into dynamic offers and you can change your downline systems eventually as you move into full offers and orders and as you move into ONE Order, but today they can continue to work as is.
The second cost benefit we see is that potentially there should be a lot less data and a lot less churn. We saw statistics earlier in the conference on ATPCO fare filings and how they have exponentially increased and the amount of changes, or churn, how many times airlines are changing the data in a day. That has also increased. The amount of churn and the amount of fares in the market now are just continuing to grow. So we believe that if airlines aren't forced to file all price points up front and they can instead just file the prices that were sold, then we have less data in the market, we have less churn and we have less data, which would be helpful I think to all of us. So those are our benefits that we see.
We did issue as Initial Solution Milestone 2 that went out this week. So if you haven't seen it because you've been here, please go take a look at MyATPCO and take a look at the Bulletin or the Notification. And we've got a lot of information there on the details of this solution, including record layouts, which we all love. The data dictionary which we all love. So all the detail is there for you just to give you a simple idea of how the flow is working.
Again, this is a hypothetical example for one airline, just in one use case, this airline is filing, they've got pricing data in ATPCO today. They are at time of shopping, they are creating, their shopping system is creating offers using ATPCO fare and rule data and then their merchandising system is taking the offer and adjusting the amount. So we've got an adjusted amount and then they're presenting that adjusted offer to the customer and assuming the customer accepts the offer, assuming it's converted to an order, at the time of order creation, the airline is sending the order to ATPCO, and they're also giving us some supplemental shopping data. And we are taking all of that data. We're converting it into ATPCO structure.
So for example, we're creating a fare record, and this is really cool, we are adding supplemental information to the fare record, which is the order ID, so that it's now going to flow through the system to give you that extra data point, so you can kind of track this back to that initial dynamic offer that you created. Then we're sending it to downline systems. In this example, we're sending the data to a change and refund system and they can choose to keep the data in a separate database. Because this is data only for downline use, it can't be sold or they could integrate it into their current database. Here we've shown them separate just for illustration, so that when a ticket is actually presented for change or for refund, the change and refund system can go look for fares in their current database. They can also look for these, the new Airline Order Posting fares and they can run through their Cat 31 process as they do today.
I think this one's exciting. We are in a POC, we've done POCs with two major airlines. We have another, a third that we just talked to that wants to work with us on this as well, and we are planning to have the MVP out next year. I I'm going to call out, I keep calling out my colleagues, but I've got Shelly, Aruna and I think Brian Trauger's in the back of the room. They are the team that are really working on this now. So give them a lot of credit. This is a really, really fun project that that we've got going on.
All right, that was exciting. Okay, so now this is like where we've all wanted to get to, at least for me. This one's near and dear to my heart. And so I've been just kind of waiting to get to this one, the Product Catalogue.
And before I get started on this, I have to stop and I have to talk to my friend Raeleen Hollier. Did anyone hear Raeleen this morning? She was in the dynamic offers panel that Daphne led. It was a great panel and I thought it was exciting and I always thought Raeleen and I were good friends and good colleagues and we work really well together. And for some reason she said that I had ran around with a cattle prod. Really? I gotta come over here. Like, really? Well, I was actually going to forgive her because she said cattle prod, and I thought okay, I can laugh it off, but she said it twice, like the next time the mic came back to her she mentioned it again, and I thought that was so unfair. [laughter] But I don't prod. So I asked my boss if I could have an ATPCO cattle prod because it actually sounded kind of cool. Thank you. But I couldn't get it before today so this was the closest I could get. Thank you. Really, there's always a downer. So thanks, Raeleen, but I don't, it's not really like a cattle prod in these meetings.
So I do have to take a step back because Raeleen had some valid points, as did Jerry and the others on the forum, that this is a really hard topic because this is brand new. For most of us, this is a very immature topic. We don't quite know what our requirements are. We don't quite know how we see the end of that path. So we know it's there, we know where we want to get to, but not exactly sure how we're going to get there or what it's going to look like. So Raeleen often has questions, as do a lot of us in those teams, and they're awesome questions. They make us understand where the gaps are and we learn and we move forward a little step at a time and we get, eventually we'll get closer and closer to those solutions that will work for all of us. But it's not easy. But it is fun. It is fun. You better not say it's not.
I always tell people, come be part of the solution, come help us build a solution because we're not building it for ATPCO, we're building it for you. I mean that, that's the truth. And the more knowledge we have in the room and the more input and the more questions helps us all think better and helps us build better.
So that's where we are with Product Catalogue. Like it's a new concept. It's the hardest thing I've ever worked on. So some days I look at it and I think, oh my gosh, maybe there's a lot easier jobs out there, but this is cool and I think we're all in a really, really special place that we can actually change the industry, and the last big industry change happened before a lot of our time. So you look at it that way and this is really exciting and you want to be part of it. I don't want to run away from this. This is just great. So come join us, come change the industry with us and change it in a way that or a place that you want it to be. So that's my spiel. Product Catalogue.
So to Raeleen's point and I believe Jerry had the same point, we don't have this as well defined yet. We're still trying to figure it out ourselves, but I promise we will work on definitions, and I took an action item to have a Product Catalogue definition, at least a proposal, a draft as well as dynamic bundles, dynamic offers, and dynamic pricing because I think those were the four takeaways I had from this morning. We will take that as an action item for the design team. That said, where are we today?
We started looking at the Product Catalogue first by looking at how things work today. So for today, airlines, you do a lot of work, and on the stage they said you're a jack of all trades. You are, but but the sheer amount of work you do to just get your prices out in the market I think is really incredible. So you've got to define every permutation today of product and price. And in today's world that means you're creating fare records, Record 1s, Record 2s, Record 3s, you're creating your RBD data, you're making sure that all of that is correctly identified in your branded fares, you're making sure that the correct optional services are not only coded but also identified with your brands. You're making sure that any applicable fees are also, all the data is there and also associated correctly with the correct fares, with the correct brands. It's a lot of work and you do this today for every single possible price point and product permutation that you have and it's a lot of maintenance and it's a lot of work. And we understand that that is not sustainable. There's not an expectation that we would continue that in the future. That's not where we want to be.
We want to be in a world where we can separate product and price. And that's really the first, I would say, requirement that we came to with Product Catalogue is that we were separating product from price. So we looked at Product Catalogue to say how do we define product, what's the best way to define a product. And try to leave price to the side, we're not addressing price at the moment.
We also heard that airlines need the ability to easily create bundles, to dynamically bundle products together and unbundle products depending on the contextualization and offer that you're creating at the time. So we said, is there some way that we can create building blocks of products or building blocks of attributes that you could then easily assemble or disassemble at the time of product creation, but you don't have to file every possible permutation of how they may assemble or disassemble.
So those were our top requirements, separate product from price and then somehow find a way to easily bundle and unbundle products and attributes.
The next thing we looked at is that with the catalogue, airlines need a way to inform sellers, to inform customers what product offerings you have. So you want to be able to tell the seller and tell the customer these are the products I offer, because ultimately we want to get to a place where they can shop by product and shop by attribute so that they can ask you for specific products, ask for specific product attributes and you can build your offers around that as opposed to the way we do it today.
And I don't remember the exact quote, but I loved what Expedia said to us yesterday, was can we move the product attribute to the top of the funnel? I thought that was a really good way to put it. Really put it in something that we've been looking at too. Can we start creating offers based on the products and the attributes that the customers ask for that you think they want as opposed to having that happen at the end? So that's something we'd like to be able to enable.
We're also with the Product Catalogue looking to create a common industry definition for products and a common way that you can distribute that catalogue so that that same product is defined and means the same thing in any seller or with any other interline partner or any offer creation system that's using it. So we're looking at a common definition to help, you know, really ease the initial implementation and ease the distribution of the data. We're not telling you what products to create or how to create or what attributes to use or not. But what we're saying is if you create a set of attributes, let's have a common definition for what those attributes mean so that they mean the same thing in every system that's using them, be it are they using it in a shopping request, is it something you're sending in a shopping response, and to make sure that the same thing, if I have an extra legroom seat on my airline, I want it to mean the same thing with everyone that's looking at that product.
We spent quite a while coming up with use cases, and I know I only have three on the screen. I know that there are a lot of use cases for the Product Catalogue, but we boiled it down to three general use cases. The first one we said was offer creation. We saw the catalogue data being used in the offer creation process where you took these building blocks of products and attributes and you bundle them together to create your offer. That was our, we called that an airline-to-system. That's where the airline was creating catalogue data for use within an offer creation system. That was our first use case.
We identified the second use case. We identified what we've called interline alignment or supplier- to-retailer. And this is where a supplier airline might want to share catalogue data with their retailer airline so that the retailer airline knows what products are offered and also they can search by those products. But they can also align products. It would allow you to align your product offerings with your interline partner, as well as know what products may and may not be offered. Because if I'm checking my surfboard for example on my flight, but I need to connect with my partner’s flight and they don't take surfboards, well, I need to know that that's a product that they don't offer. So there was in terms of aligning across the product offering but then aligning my products and brands with my partner.
And then the third use case we're looking at, we've called this product search, but this is when an airline wants to expose their catalogue data to a seller. So for example, you might want to share what products you offer with sellers so that they know that they can come search for those products, search for those attributes on you and that would help them. Again, it all improves the customer experience in the end, so that the seller knows what the customer is asking for, they know that you are an airline that. First, what the customer is asking for and they can ask for it in the first place. So those are our three use cases.
We are ready to take these into an exploratory stage. We've called it a POC, but it's really kind of an exploration stage that we are still working to set up. But that that's where we stand with the use cases. Now in terms of the catalogue itself, we've done a little bit of very simple, very high level work to define the data elements and the data structure for the catalogue. And we base this around a very simple concept of what, who, when, and where and how, what product is being offered and then who, when, where, and how can the product be used. And most of our work has been spent on the what, what is the product that you're offering, how do we define a product in the first place?
So we took a look at how products are defined today. So we looked at the IATA retailing taxonomy to get some insight there and we also looked at ATPCO's optional services to get some insight there. And our insight not only was how's the product being defined today, it was also what are our lessons learned from today, what's not working today and what is working, because we don't want to duplicate what we've already had and we want to learn from any mistakes or challenges that we have in our past.
So when we looked at the IATA retailing taxonomy and optional services, we came up with a proposal for a structured, hierarchical way of defining products where we started with the delivery location. Was it a flight? Was it ground? Was it at the airport? Then we moved into a high-level group. So for example, is it a meal and a subgroup? Is it, you know, a breakfast? And then details and dimensions are in level 4. And we really went through a lot of effort there and we have a really nice spreadsheet that we've created that we issued in a notification as an Initial Solution or Milestone 2. So there's a lot of detail in those in those levels.
However, we do know that that was a first draft, and in our recent design team meeting, we've realized we still have some work to do. We know it's in progress and we have changes we need to make. So for example, we had some questions on whether a delivery location really needed to be at the top level or it should be at a lower level because it's the same product being offered regardless of where it's being delivered. That was the proposal from a couple of airlines. So that's something we're going to talk about in our next design team, which happens to be tomorrow.
Then we looked at level 4 where we had dimensions and details and we said, you know what, we really need to separate out level 4. We need some more, we need to segment out that data and really define how we think it's going to be used. Things like amenities, things like additional product details, things like bag types, things like the dimensions themselves. So we know that level 4 needs to have some work as well and we're going to do that tomorrow too. But it was a really good first step and it really got us thinking about how to define the product.
The second piece we haven't really worked on the right side of the screen other than to say at the highest level we know there are going to be targeting rules. So somehow, well, an airline may need to say where, when, how, who can use the product. And these are targeting rules that are not, again, not to be confused with today's rule categories. They are not pricing rules. They are rules that actually are defining a product. So the example we always use is bus service in Denver. Well, it's Denver bus service only in the winter time. It's not the fact that it's in location. Denver defines the product. The fact that it's only in winter defines the product. These are targeting rules that products only. It's only offered that time of year and it's only during winter in Denver. So those are the types of targeting rules that we believe are going to be needed to define who and where and how.
And lastly we have business rules. These are the least defined of all of these. But we've said at the highest level we think we might have bundling rules, we may need some interline alignment rules, we may need some rules whether an inventory check is required or not. And so those are that right side of the screen is what we're going to be working through our POCs.
And then lastly for the transition, as we have to transition from today's world to that top right quadrant, we realize that we may need some type of pricing data, I'll say, associated to the catalogue. I've got just a kind of dotted line there around the arrow and a question mark. So we don't think this is part of the catalogue, but for the initial phase, we have heard from several systems and airlines that they may need to reference price, so a price that they're going to use to help base their price calculation, and they also might need a settlement value until such time that they are ready to implement that full NDC interline request/response where they get the settlement values in the response from the supplier airline. And then lastly, they may need a few pricing rules to help with the price calculation. So they may still need minimum stay or advance purchase in the early days. But we don't believe these are officially part of the catalogue. They're just something that may need to be there to help the transition.
All right. So our next, this is what we're doing tomorrow. So it's a sneak peek for all of you coming. I know it's very exciting.
We need to look at, we're going to start with the what, we're going to start with the product definition on that top left and we need to look at it in context of each of the use cases and say, okay, well, if we're defining product elements or how I want to define my product, we need to talk about those elements in terms of the use cases and how you expect them to be used or shared, whether it's an offer creation, whether it's with an interline partner or whether it's with a seller. So tomorrow's going to be fun because we have some specific products that we're going to take through each of the use cases and try to define our requirements. Eventually we'll need to do this for all of the elements and all of the data that we'll have in the catalogue because we see it may be that you only want to share a subset of the data.
So these are completely new ideas on how you want to share your data, how you want to distribute your data. You may want to share a subset of the data with some partners, but all of the data with other partners, and we've really got to take a peek through that. It may be that some of those attributes can only be in the shopping request. They're for attribute search, but some, or maybe some can only be in the shopping response there to further expand on information about your product.
And just to give you an example, so here assuming we have two products, I was very creative, I have product A and it has levels 1 through 4 attributes, and I have product B and it also has levels 1 through 4 attributes. It may be hypothetically an airline only wants to share product A with Airline XX but product B they will share with Airline XX and ZZ. So it's just to show you may have some products you share with some airlines, some not, and you may segment. So for example, you might only want to share levels 1 through 3 with a specific seller. So these are all types of requirements that we really need to get through as we're defining attributes and as we're walking through the use case requirements.
It's good, yes. All right. And it gets even better. So not only do we have that, we have all these there every time we do this. As Raeleen said, there's another question and the questions are good because in the end we want a well defined solution.
So we're still holding on to some open items. I've called them key discussion items, but they're all open. Bundling is one of them, how do we bundle the products? What are our bundling rules? What do we do when airlines say some products must be bundled, some products must not be bundled? How does that work within the airline? How does that work across an interline partner?
Product code is another one. So what we mean by that is once you've defined your product, do you need a code that allows it to flow through the current processes? And for example, I'll give you fare basis code today, you're using fare basis code to define your product and you've got a fare basis code taxonomy that defines your product and it flows through the whole ecosystem today. Well, can we leverage that to transition our catalogue in today's world to where we want to be in the future because we know it works. So is there some way we can use that solution, somehow leverage it?
Then availability is a big open issue that we are hoping to address with a use case or excuse me, with a POC on seats. So there's a lot of open items on availability. Extra legroom seat was an example. How do you know up front if the extra legroom seat is available or is it the extra legroom aisle, was the example yesterday versus the extra legroom in the middle? Airlines might internally have solutions, but there's not a whole industry solution for this. So we need to talk about expectations and transition and what we want to do with availability.
And lastly, does the product apply on a leg basis an O&D basis, a journey basis. So these are things we're going to work through also.
As I said, with fare basis code, we're hoping to leverage the fare basis code taxonomy and see if we can automate it. We know it's the only piece of data that flows through the full end-to- end process today. So it's a really powerful piece of data. We know there's problems with the eight positions, but it's still a good piece of data to use. And is there some way we can automate that and use it to define the catalogue data?
So what we've done with that is we have had private conversations with many, many airlines on their fare basis code taxonomy. I won't read the list, but on the left side is a high level, a summary of what we're hearing airlines are using in their taxonomy. Just some general observations. They tend to use the taxonomy for product definition. They also use it for ticketing and reporting. It also supports many internal processes like market analysis, reporting, product performance, brand identification. Airlines are very creative, hats off to all of you. You're very creative with what you do with your fare basis codes and you're all different. Nobody's the same. And it makes it a challenge. So the question to ATPCO now is can we automate this?
So we have done a data mapping exercise, which was awesome. We took all your requirements and we mapped as much as possible to the data to say what can we automate and what can't we automate? And the next steps for our design team is to say, well, we don't think we can automate everything. So how do we want to incorporate this into a solution? Do we want to look at partial automation from the catalogue as we move into the future of full automation? I will share that no airline we talked to has a clear transition path from moving off of fare basis code and into a full offers and orders world. It's still a question, they all are planning it, there's just not a clear path.
So in the interim we think that we can really make use of fare basis code, but we want to look to the future for offers and orders when fare basis code will likely be gone. And maybe it's an offer item ID, maybe it's a service ID, and these are all things that we need to consider.
As I said, we're moving into a POC stage. We are primarily looking at right to fly, seats, and then bundles. Some of our POCs will be exploratory on paper, trying to theoretically see where we want them to work. Some are going to be live and they're really cool.
We're going to try to look at ATPCO's current data and see how we can transform it or use it a little differently to send out those building blocks and maybe allow some dynamic bundling of fares and ancillaries to create a dynamic brand, if you will. So that's, stay tuned, that's in a POC stage. And then we'll let you know. We've got systems and airlines committed. As I said, we're still trying to match up. We've got a few outliers that we're still talking to before we really officially kick all of these off.
All right. I'm going to close. This is almost closing. I'm going to come back to the same slide because we see this slide all the time, but this is a really valuable slide. We know that Product Catalogue will get us to that top right corner. But the thing is, we know that airlines are going to live in multiple quadrants within an airline depending on your market segments and your requirements, and across airlines. So we know that the catalogue data that we are creating now has to be interoperable with that bottom left corner. So for ATPCO, interoperability is something that we say all the time. It rolls off our tongue. It's one of our favorite words because we truly believe that the solutions we create to get us to the future have to be interoperable with the present during this transition phase. Because we're not all going to move at the same time and we're not all going to be in the same box, but we still need to interline and we still need to keep all the functionality and the beauty of everything we have today.
So if that sounded great, which I hope you thought it did, I invite all of you to participate. ATPCO’s design teams are open to all of our ATPCO customers. Anyone can join. There's no limit. We do have the Dynamic Offers Design Team, which again, I co-lead with Daphne who's in the back corner. You've all met her. We do this together as a team. Our next meeting is tomorrow in the hotel here. So if anyone is staying overnight and you want to come, you are welcome to just come, let me know just so I make sure we have enough breakfast and lunch for you tomorrow. But you're all welcome.
If you just want to see the documentation or get some ideas on what we work on, everything is on MyATPCO on our design team page so you can take a look at past presentations, agendas, and things like that.
If you want to get come play with us and a POC, come talk to us. If you have some creative ideas for what you'd like to do in a POC, we'd love to hear it. So no idea is a bad idea. Come talk to us and we're happy to get you involved.
And lastly, as I said, we had a quite a few notifications go out. Please provide feedback on those Milestone 2s and 3s. We'd appreciate it.
With that said, we're done. I thank you all for your patience. I'm so sorry this ran long and I hope you forgive me for that, but thank you. Obviously, this is an awesome topic and this is where our industry's heading. So please, please join us, get involved, be part of the solution and I do not have a cattle prod.
An event experience you can't miss
ATPCO's Elevate + ARC's TravelConnect
Chief Strategy Officer, ATPCO
For over 25 years, Tom has been working to develop products that enhance the travel industry. Throughout his career, he has gained insight and provided leadership through his various roles at airlines and global distribution systems, and with ATPCO since 1996. In his current role, Tom leads the Strategy organization and is responsible for creating the long-term vision for ATPCO and exploring new business ventures. His focus is on industry standards and effective ecosystem governance, as well as driving forward concepts like dynamic pricing and tax automation. Tom has built a reputation for being a thought leader and implementer of industry solutions in the distribution space.
Melanie is a principal at ATPCO with over 25 years of experience in airline pricing standards. She played a key role in the development of ATPCO’s data collection and distribution standards for airline fares and related data and has led multiple industry working groups, including recent efforts on dynamic offers.