 Hi everyone! Today we'll talk about the technical side of creating an online travel agency. Don't click away, we're going to explain some interesting behind-the-scenes details about the works of travel market. My name is Andrey Chebotarov and I'm travel technology competence leader at LTECsoft, and I'll explain you the basic functions of a booking engine and the challenges that arise when building this tool. It's called an engine for a reason. You see, searching in booking online should be automatic, otherwise people would still be going to travel agents' offices. So, an engine exists to carry the load and do the hard work automatically in the background. A booking engine requires lots of engineering efforts and something else to build. Basically, building a booking engine is maneuvering a few complex layers of an OTA and combining them into one mechanism. What are those layers? First, integration with suppliers. Second, search rules. Third, pricing changes. And finally, booking and ticketing flows. Let's start from the foundation, connecting to suppliers. Inventory providers are each OTA's main treasure. They may be global distribution systems, individual airlines, hotel wholesalers and so on. As I explained in the previous video, it's important to have individual agreements with at least some suppliers to get best deals and survive the competition. It takes months of negotiations to establish exclusive conditions and obtain advantages commissions to keep the end prices competitive. But there's a technical side of things. To make, say, flight search available, you must be integrated with the global distribution systems via an API. A booking engine has all those integrations and controls plugged in and it manages how searching booking happens on your website. These integrations allow you to do a number of things. Request for inventory, flights, hotels, cars and others. Check availability for this inventory. Get prices. Book those products. Receive tickets for them. And then an ancillaries. So the integration layer takes care of how and where you get this raw information. Usually you are integrated with one or two GGS's, several hotel suppliers if you sell hotels and several other travel product providers. But integration themselves don't define what exactly travelers will see when they search for flights or accommodation. It's a booking engine and its settings define which results to display. So how exactly does search work on OTA's? Let's say a customer wants to find flight tickets. You can just suggest generic results with standard prices which are fairly the same as different suppliers, but it's not very efficient if you want to stay competitive. So a booking engine is as smart as you make it. To know where and how to search, it should use a handbook of business rules that allow you to narrow down the search using specific parameters. And obviously an OTA staff must be able to manually tweak those rules for different cases. For instance, you may define that travelers that booking flights across the US would see the results that you source from the Saber GDS. And those who travel to Europe would see the results that Amadeo suggests, because you have better deals for these destinations for these suppliers. It's usually more complicated than that. Most OTA's may use multiple travel agent IDs to access different suppliers' inventories, as each ID may have different negotiated deals tied to them. Working with multiple suppliers is also a challenge. You must aggregate data from many sources, and if it intersects, for example, you can get the same hotels from different suppliers. You have to map them to each other on your end. And on top of that, you can augment search results' page with personalized offers for some users. If you know that this particular traveler usually looks for quality flights, results' page can automatically prioritize these over-budget deals. To wind up with a search engine, it's a complex mechanism that does two critical things. It decides where to look for the products that a traveler requests and what results to display. What the search engine doesn't do is defining pricing rules. Okay, this may get a bit confusing. If the search engine is looking for deals considering the prices, why do you need separate pricing rules? You see, you get products from suppliers for their prices, but you still have to get some margins selling them, right? That's where pricing rules are used, to adjust OTA margins that come on top of the supplier's price. In travel, prices are fairly flexible. They can dynamically change, and an OTA can tweak the pricing rules. On owned platforms, you can consider a ton of different factors to set them up. For instance, you can adjust your margin based on current demand, your inventory suppliers, competition, season, the sources from where your customers came from, you name it. Rule-based, or with machine learning, these techniques allow you to keep balance between competitive pricing and profitability. The most common example is adjusting pricing for meta-search engines. Smaller OTAs allocate the biggest share of their marketing budget to get listed on meta-search engines like Skyscanner or Kayak. Most of your visitors will actually come from them, so managing how your listings appear there is an important task. You, of course, want to display the cheapest price for some destination to reach the top of the search results, because there is a whole list of other OTAs like yours on the same page. So you need a dynamic pricing strategy to pass competitors and keep the business profitable. Marketing and revenue managers analyze all those factors to come up with flexible pricing rules. Another level of complexity with dynamically changing prices is how to keep them up-to-date. Your suppliers change prices and availability, you change margins, and it means that displaying real price all the time would lead to a slow processing. If you process the search results for a couple of minutes, most likely your visitors will leave for good. So OTAs usually batch prices and cash them to increase processing speed. And yes, most of the prices that people see on the OTAs results page are cashed and don't necessarily display the real current pricing. But if you update the cash regularly, this trade-off between the speed and up-to-date info is worth it. So you have to constantly balance between these two factors. At the end of the day, pricing rules is one of the most intricate mechanisms of a booking engine. Since it defines how to balance between the competition and profitability, you and your revenue managers can't mess this part up. Okay, those challenges concern the search alone, but the main task of a booking engine is to manage, well, booking flow. What's the challenge here? A booking flow is a set of consecutive steps from the availability search to the transaction. From the UI point of view, it might be the same regardless of the supplier, but on the back end things aren't that simple. Usually you would have multiple booking flows depending on an inventory supplier and other factors. For instance, we at Altecsoft have experience with OTAs who work with two different GDSs and each GDS has its own booking logic and specifics. That means that under the hood, the process varies depending on each individual GDS, bad bank or any other supplier. How do you request booking? How do you generate passenger name record? How do you chain messages via an API to keep them compliant with the rules of each individual supplier? How do you process payments? Setting up and plugging in new booking flow leads to architectural changes. Learning how to integrate two or three booking flows is manageable. But as your list of implementation growth, your engineering team ends up in a difficult position, trying to maintain old architecture, develop new business logic and keep it all working smoothly. Besides, you have your own business workflows that have to be aligned with external ones. But booking isn't ticketing yet. You can probably guess what ticketing does. Ticketing is issuing a confirmation that the seat was paid for and belongs to a particular traveler. In the era of electronic tickets, all passenger and flight data is kept in the airline's passenger service system, while a document that a traveler receives early are a seat. It seals the whole deal. Usually, ticketing happens some time after the booking. This time gap is needed to check if the passenger information is valid, the credit card is fine, and there weren't any other problems in the booking flow. OTAs can issue a ticket if they have an IOT accreditation, which is expensive. To bypass this accreditation headache, some OTAs partner with consolidators or other IOT agencies to do ticketing for them. Let's quickly sum up. A booking engine is a massive machine to interview. It needs mechanisms for smart search and flexible pricing. It's responsible for connections and booking flows with different providers. It's also responsible for payment and ticketing, whether you do it on your end or delegate to third parties. And this machine always keeps changing and scaling up. Building a booking engine is difficult, but possible with smart management, a talented team and domain experts. I hope this video helped you understand the processes in the heart of an online travel agency. I hope you enjoyed it and see you in the next video.