Why a new booking module?
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?
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 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.
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.