5-10 years ago the main goal for bus ticket reservation systems was to ensure the distribution of seat reservations and tickets in the operator’s own sales channels.
Although many bus operators competing in the international market had a wide network of brick and mortar travel agencies, more than 90% of domestic network tickets were sold through the operator’s own ticket offices.
Today, the nature of the reseller network has changed and it is quite clear it will continue to change even more for the next 5-10 years.
In countries where digital payment methods are matured enough, the digital distribution channels (OTAs & Metasearch Engines) and GDSs who provide the content for them are steadily growing to become market players that cannot be avoided.
Though at first, it may seem that such digital networks just replace travel agencies, this trend is changing the fundamental principals that a bus reservation system has to follow.
In this article, we will cover how is this fundamental shift going to affect operator’s reservation systems infrastructure and the technology behind them.
The brick and mortar travel agencies mentioned in the intro were in most cases using either the agent sales tool provided by the operators. Alternatively, they used their own travel booking software that included the operator’s content.
The latter was available only for bigger travel agencies and was based on allocating exclusive seat allocation quotas.
But what was specific about this model is that the passengers themselves did not perform their request of tickets against the operator’s reservation system. It was the travel agent who was responsible for it.
This resulted in high conversion rates between the request for travel (seat availability, fare, schedules, etc.) and the number of bookings that actually went through. The main reason behind it – most of the passengers went to a physical sales point already knowing ahead that they plan to travel.
The amount of passengers shopping around on different OTAs websites, while performing the same request, is much bigger than the requests of the hundreds of physical sales point workers combined.
Today, in the growing availability of self-service oriented digital booking and travel agencies, it’s the passengers themselves who perform requests against operator’s reservation and inventory management systems.
This shift combined with the expectancy of real-time response, dynamically changing fares, and expanding travel possibilities increases passenger’s urge to just „shop around“.
This is even further influenced by the growing competitive landscape of the intercity bus industry, driven by liberalization and attractiveness to the new young travel segment. All those factors result in booking conversion rates decreasing exponentially.
Another factor adding to the decline of conversion rates is the vast amount of emerging online travel agencies who include intercity bus content.
On one hand, compared to the amount of hundreds or even thousands of brick and mortar travel agencies, the typical amount of OTAs reselling a regional intercity operator’s tickets limits to around 20-30.
Yet, the amount of passengers shopping around on different OTAs websites, while performing the same request, is much bigger than the requests of the hundreds of physical sales point workers combined.
Additionally, it is a common practice for OTAs to cache content about seat availability and pricing within their own servers to decrease the response times for their own customers. Often, the reason being the operator’s own legacy systems just being too slow to respond.
With a growing nature of dynamic pricing and seat availability, this caching request against operator’s API is performed very often and usually without actual passenger’s purchase intent behind it.
Those caching sessions perform like crawlers adding a constant stream of requests against a system. In worst cases, the requests are not even optimized to include only the origins and destinations between you travel. Thus, adding a lot of unnecessary load on your reservation system.
In conclusion, our experience shows that compared to the physical sales points age a modern bus reservation system connected to a well-established digital distribution network has to be now able to handle around 10-20 times more requests per actual booking. But in peak hours it can be even 100 times more.
Considering the ever-growing dynamic nature and increasing complexity of the travel industry, such shift in distribution paradigm will put a huge strain on legacy reservation systems designed for the age of brick and mortar.
One of the key reasons why the shift from brick and mortar to digital sales channels will have a huge impact on legacy reservation systems is that most of them are built using monolithic software design principles.
It means that all the different functions of a reservation system (schedule, fares, inventory, booking, ticket fulfilment, etc.) are built as interconnected and interdependent components of an application.
To cater to the increasing load of digital resellers, monolithic system providers must scale or copy their application, which might be impossible in some cases or too expensive.
Thus, the inevitable scaling of legacy monolithic software becomes impractical, results in higher costs and in the worst case will negatively impact passenger’s user experience.
A modern reservation system should be built upon using modular architecture, e.g. microservices. Meaning that the different functions of booking flow are cut into small loosely coupled applications, which communicate with each other over APIs.
A simple comparison of monolithic and microservices architecture
The value of such architecture is that it’s easier and less costly to scale up only the modules requested by external partners over API.
For example, if 80% of incoming requests are only about the available schedules then scaling of that particular module is much more cost-effective than scaling the whole reservation system.
It goes without saying that one of the prerequisites to joining the digital distribution channels is a properly documented and structured API for external resellers to connect with.
Although there are different ways to build a distribution strategy (affiliate referral vs full API integration), a modern API should cover the whole booking, cancellation, and amendment process including all intricacies of the intercity bus industry and specific region.
Yet, often legacy reservation system suppliers either provide API-s based on outdated technology, resulting in poor performance or in the worse case, are not able to provide API connection at all.
Performance of such APIs relies on several factors:
It’s not rare for digital resellers to encounter API response times during peak and sometimes even normal hours of around five to ten seconds, which is mind-bogglingly slow compared to the average 0.5-1 second respond times of modern systems.
Considering that an average user gets anxious when it takes longer than 2 or 3 seconds for the system to respond, painfully long response times will eventually affect client relationships and the reputation of the operator as a modern service provider.
So what should be the main takeaway from this article?
It is clear that the digital resellers have a huge impact on the intercity bus industry and will continue to influence it for years to come.
When looking for a new bus ticket reservation system for your company, be sure to choose a system built on modern and scalable software architecture principles (microservices for example).
This will ensure that your bus reservation system is up for the task of handling the strain that new-age digital resellers put on the system and the system itself is continuously evolving to meet the everchanging needs of the market.