One of the latest trends is a single basket. The meaning of the basket (single / multi, the reader can add definitions based on his preferences) is simple - to create the opportunity, for the traveler, to book (pay) for bookings, both air services and all kinds of non-air services (car rental, accommodation, transfer, etc. ), throwing them, as in an online store, into a single basket.
I’ll tell you about the stones about which the development of these technologies stumbles
For air travel (the technology leader in the industry), it all started about 10 years ago when American Airlines tried to sell a full range of services online; many obstacles arose:
- From the resistance of competitors - 200 roofing felts, roofing felts of 300 travel agencies (from the story of the petitioner) wrote a complaint to the US Senate (on the death of travel agencies business);
- But most importantly, American Airlines is embarrassed by the technological readiness of the industry.
The path to a single basket
Year 2014, IATA (an international organization that sets standards in aviation) announces the transition to the new NDC standard in the usual venue for air forums at the Aviastar hotel (there I heard, for the first time in public space, this term) And it shows a picture - a basket in which the most diverse services are stacked. This is how the e-commerce customer basket came into the travel industry.
Comment: NDC is a global initiative of the World Aviation Organization, the technological basis is the transition from the use of telegrams to the xml data exchange protocol. XML of course simplifies integration. But the main goal is the market for additional services, its potential is $ 150 billion per year, and most importantly - tickets bring very little margin, and additional services from 5% (which is already higher than the profitability of tickets) to 50%. According to the owner of one of the American travel agencies - in their business an air ticket, it’s like milk in a supermarket, it doesn’t bring money, but it must be present on the shelf, the money is in another.
Year 2017, we launch in Aeroflot a unified distribution system for goods for a traveler, with a single basket - you can put in a basket the ticket: accommodation, car rental, transfer, Aeroexpress, insurance (as well as additional services for each of these basic services).
Year 2018, preparing for a presentation at the air forum in Kazan, making a picture about how conveniently arranged on the Aeroflot website: threw services in a basket and paid in one payment, and how inconvenient in S7, where each service is a separate purchase. I’m going to the S7 website, cross-checked, I haven’t been to the website for a couple of months, and there it’s the same thing - you can buy several services at once with a single basket. I had to use the Vnukovo site as a bad example, something like this -
Year 2019, everyone started working according to the same standard, there are not many projects completed so far, but only personally I know 4 projects that are in work. The largest is the project to build an import-substituting GDS (which I will not say, two of them are forbidden by the omnipotent NDA).
Simply put: selling through a single basket is a trend. And whoever does not learn how to work with a basket today will have to look for another job tomorrow.
And here we come to the interesting - and how the transition to a single basket really happens.
Comment: the characters will be employees of a large and respected IT company. These are knowledgeable and intelligent people. All the absurdities described in the article come from the usual reticence of thinking.
At first glance, everything is fine - GDS are switching to xml, changing booking structures, projects are breeding, everything to live in a modern way. There are certainly outsiders, like Leonardo PSS (Passenger Service System is a system in which the airline stores all its resources: boards, flights, seats; and there is still a lot of good PSS), the system is fresh, it’s only 5 years old. Nevertheless, it was built on antediluvian telegrams, and about the sophistication of the NDC that did not know at all. This creation of our days does not even know how to unload the schedule in automatic mode, it is shipped manually and often the button is forgotten and the schedule does not come, and here the manual calling procedure is turned on.
But these are outsiders living with import substitution. In general ... And not everything is good here. This fall, I had the opportunity to ask the chief technologist of a large project to build a Russian reservation system (modern, even with a claim to innovation), which approach are they going to use - GDS or marketplace. And then I ran into the answer: that everything is already in the industry and there is no need to invent anything here. The first thought was: unsuccessfully / at the wrong time asked. But after several such clashes and after my unsuccessful explanations of what modern approaches give (these were clashes with more than one employee), I realized the depth of the ossification of the industry.
And therefore, I present a couple of cases, why marketplace approaches are needed and what they give (I intentionally leave only air services in the basket, so that the examples would be brighter, but this takes on global scale if there are no air services). The examples use cases of an agent sales scheme.
Example one - round-trip transportation
We go to one of the most common search engines - aviasales (sorry guys, I respect you, this is not a stone in your garden) and look for Moscow-Istanbul, there and back. We find a bunch of proposals, but none of them satisfy us. Immediately I want to, as a traveler, combine flights myself. But do not give. Why? Very simple.
For round-trip GDS requires the formation of an RT reservation - (round trip ticket) - a round-trip ticket, i.e. round-trip. This is not always possible. The simplest example is you are an agent site and you have several sources for receiving offers on flights. And Moscow - Istanbul you have in one source. And Istanbul-Moscow, you, in a different source. GDS says, well, what can you do ... But we have a basket of a marketplace and we form the set we need there and back, and create two armor type OW - (one way ticket) - one-way ticket, and send the passenger a 2-way receipt. Everything is convenient, paid with one swipe.
Accordingly, in the order (for round-trip flights), in our system, we must create an entry in the orders: Orders table. As the main identifier, we use not the traditional PNR, but order_n - the order number. And two entries in the services table: Services, both with a link through order_id to orders. In the type_flight field, for an order formed according to the GDS rules, we set the sign of the flight type rt, not according to the ow rules, in the PNR field in the first case one identifier, in the second another identifier. The same with links to an electronic ticket and route receipt.
Such a simple construction allows, without violating industry rules, working as we need.
A separate story in this case, ensuring that you would surely book both shoulders. It’s more cunning, since requests in GDS are paid. But it all depends on which sources of proposals for air services you use, so let's leave this topic.
Example Two - Virtual Interline
This technology allows you to combine flights of various airlines, even if there is no agreement between them and common tariffs. Combine, in the sense of forming a proposal for a flight that is operated with transfers, i.e. If there is no direct flight that suits you and there are no interesting transfers, collect your offer yourself and get an option that suits you.
In this scheme, there is an ambush, namely, ensuring the placement of a passenger with a flight delay. Who will accommodate the passenger if one of the flights is delayed and who will compensate for the loss if the passenger arrives in Moscow-London, the London-Riad flight is delayed, and the passenger does not have time for the Riad-Jed flight, the airlines do not know about all these connections and nothing to the passenger should. But this is already a technology business, and we have an IT resource here.
The virtual interline is especially interesting for airports, having a similar system, you can expand your route network by including flights practically all over the world. But of course, our favorite, agency site (or just an agency).
Let's move on to the technical part
Rule - each leverage is a separate service, from the database point, a separate entry in the services table. And from the point of view of the service model, these are different services that can be independently processed, affecting mainly themselves. And the type of flights they have is exactly the one that is transmitted to the PSS, mainly OW. And each arm has a PNR. With a case, when we book a standard multi-segment flight, i.e. by interline agreement, then there are records in the table on each shoulder, but they have a common service_id, i.e. this is a single service (like PNR), and records, well, so we achieve standardization + you never know what we then come up with for the joy of the traveler, you need to atomize flights so that it is easier to manipulate the data later. And do not forget to enter the flight segment number in the segment_number field. And accordingly - if combined by ourselves, then we issue a ticket to each segment; if by interline agreement we issue a single ticket, so to speak according to the number of unique service_id.
But these are only entries in the database. More interesting, namely - BAGGAGE, this is actually a reason for a separate article. But since we are not designing here, but telling you about the current trend in one of the branches of the great tree of IT technologies, it’s enough for us to say that the most difficult thing in this matter is what to do with luggage.
Comment: just not in Charles de Gaulle, that one is very big, I was just so late for a transplant, praise a ..., in the sense of a fat black woman who thrust me on board, right on the runway.
Without going into details, let’s say: you need to integrate with several baggage management systems to ensure automated baggage handling. But here again we clearly go beyond the scope of a small article. We only indicate that in the current systems, after the first flight segment, it will be necessary to collect baggage at the airport, and then transfer it again to the next segment. This increases the minimum docking time (roughly speaking, you do not need an hour to reload luggage, but an hour to receive + an hour to hand over), and generally not use friendly.
An example of the third - a basket with the addition of non-aviation services
Read the following article ...