With most of my work going on ‘behind the scenes’ in travel technology, its not often that I get to write about specific projects that 2 Aardvarks has been involved with. I’m very pleased, therefore, to celebrate a new online booking module going live with the recent launch of the new Ramblers Holidays website.
Why a new booking module?
Ramblers Holidays has had a real-time online booking facility since 2012. When this functionality was introduced, around 25% of the company’s total booking volume was transacted through the website from day one. This was rightly heralded as a great success, but over time, feedback started to come in from customers who were experiencing issues with the usability and performance of this part of the website.
The problem was that this original booking engine was a bolt-on to the existing legacy website, displayed in an iframe of that site – so a website within a website. There were some issues with handing data between the two sites, and also with the way the booking site behaved inside the main website – problems with scrolling, pop-ups and overlays, error messaging etc.From a user perspective, this often resulted in just getting completely stuck during the process, and it was almost impossible to use on a mobile.
We felt that the actual steps in the process were well designed – the stages were intuitive and the right amount of information was being collected. However, the other major area of feedback was performance. There was a long wait when entering the process (30-60 seconds depending on the complexity of the tour being booked), and another long wait before payment.
Ramblers Holidays decided to redevelop their main website in 2016, as part of a brand refresh exercise, and also to make the whole thing more mobile and tablet friendly. As part of this they decided to completely re-write the booking module and make it a more integral part of the website.
What was 2 Aardvarks involvement?
I have been involved with Ramblers Holidays for many years and have a good understanding of how their business operates from both an operational and a technical systems perspective. Richard Clowser, IT Manager at Ramblers Holidays, decided to bring the development and management of the website in-house, but needed some specific expertise on the interaction between the site and Travelink, the tour operator management software used by Ramblers.
Bookings are made in the Travelink system by both the Sales team, using the Travelink GUI, and the website using the Travelink API. It is essential that bookings from these two sources end up exactly the same. This means that all the behaviours that are controlled by the Travelink GUI, or are trained into the Sales staff, must be programmed into the online system as logic and rules.
My specific involvement in this project was to analyse and understand all those rules, and to encode how data was extracted from Travelink (using SQL queries and stored procedures), then written back into Travelink (using the Travelink API).
How has it been improved?
I realised early on that the amount of Travelink data required to display the user interface and make the booking was actually relatively small. The 30-60 second delay at the beginning of the process on the old booking engine was being caused by inefficient data calls to Travelink and then an overly complex layer of logic being applied to it by the the website. This was really because the site was having to use a large number of ‘out of the box’ Travelink API calls to make up the dataset that Ramblers needed and then patch it all together afterwards.
I decided to write a highly-optimised bespoke procedure that got all the data needed for the whole booking process in one shot, including as much of the logic as possible. This now takes only 3-4 seconds to run, which is a huge improvement from the 30-60 second delay that users were experiencing before. The whole data set is held and used by the booking module, then the Travelink API is engaged at the end of the process to write the bookings into Travelink.
This approach is slightly risky, in that the data is coming out of Travelink through one channel and going back using another, unrelated, channel. It requires that the two methods are 100% accurate and in sync. Thankfully, testing was extermely positive and only raised one or two edge case scenarios that needed to be tweaked.
Richard coded the application itself, and introduced responsive behaviour for mobile and tablet. We worked together to ensure that the application uses the right logic to present the user with the correct price and availability based on what options they select during the process.
So all-in-all, the new booking module is faster, more accurate, and an integral part of the new mobile-friendly website.
Take a look
Who knows, maybe you’ll find your next holiday!