We have been looking forward to making a blog post about HotelSwaps for quite some time now. HotelSwaps is one of our latest projects that we are particularly proud of as it showcases some of the things that Zoocha do best:
- Interpret a complex set of requirements and deliver against them
- Robust implementation of said complex requirements
- Make innovative use of Drupal
- Deliver on budget
What is HotelSwaps?
HotelSwaps is a membership network, which allows hotel owners to exchange their unused hotel rooms with other HotelSwaps members around the world. Using a simple point based system, hotels can earn Points by depositing its room nights for use by other HotelSwaps members. These points can then be issued to staff or guests, who can then use them to book free stays in other member hotels.
HotelSwaps came to Zoocha with a detailed set of wireframes, business rules and example data so we knew exactly what they wanted their system to do. What they needed was a company with the knowledge and experience to understand the complexity of the HotelSwaps requirements and the skills and capability to build it.
The key requirements that Zoocha had to understand were:
- Permissions – Multiple user types, all having different privileges
- Content Management – HotelSwaps admins need to edit and create content when required
- Multi-currency e-commerce – US dollars, Euro and GBP(£)
- Reporting – Management reports
- Messaging – Time and event triggered emails
- Points system – The ‘currency’ for HotelSwaps members and guests
Drupal was the ideal framework for the HotelSwaps project, as there was a mature set of Drupal modules available to support the bulk of the implementation. Some of these Drupal modules required extending to meet the specific functional requirements of HotelSwaps. Specifically:
- Points system
- Deposit and Reservation System
Having implemented the core functionality of HotelSwaps (creating Hotel's and users) the next step was to find an appropriate and robust way of implementing the points system.
After trialling the Userpoints module, we found that it offered 80% of what we needed it to, but was not going to be able to perform one of the key parts of the points system – the expiry of points. Due to the requirement of being able to track where points had come from so that they could be refunded later if required, we extended the userpoints module to create a custom HotelSwaps version that also included the transactions between the Hotel and the User.
From here, it was possible to create a transaction from a Hotel, then another transaction for a User. These were linked and could then be displayed via a “Hotel/User Statement” so the Hotel/User can see where their points have been earned/spent.
Once the points system was in place, we could start to look at how the hotel and users could award and spend their points. This requirement is all based on a reservation system. So before we could implement the reservation system, we needed to create the calendars.
Drupal has an established and robust module for Calendars, but after some investigation, we decided that we would not be able to customize the calendars sufficiently to be able to display an interactive input calendar. This meant that we had to implement a custom calendar module which dealt with creating the different styles of calendars that were required throughout the system. The implementation of a custom module allowed us to be able to customize them as much as we required to meet the given specification.
The jQuery cycle plug-in then allowed users to be able to navigate through the months with ease.
Now that we had a system in place to manage the dates and calendars, we started to build out the “Deposit” aspect of “Deposit and Reservations” system. This was the most important part of the system because in order to make a Reservation, you require a Deposit of Hotel rooms for that night. Deposits were created using a Drupal feature known as Entities to create the days deposited per Deposit. Deposits were possible in a variety of situations – during the affiliation process, during the renewal process, doing additional deposits (in order to “purchase” more points) and also by accepting a reservation request from a user.
Once we had deposits in the system, we could implement the “reservation” part. Reservations are possible in two scenarios – making a reservation for a date that has already had a room deposited for the hotel of the length of chosen stay, and also by making a reservation request for a set of given dates.
To determine if a hotel had availability or not, we had to keep a running total of whether that hotel still had room nights free. Therefore, we implemented a custom system that checked the availability by checking the deposits against reservations whenever there was a deposit or reservation in a certain month. Having this availability held in the system meant that it could decrease the search time as it did not have to do the checking of deposits and reservations each time someone added a month to their search selection.
In addition to having the depositing and reserving parts of the system, there needed to be a way for the hotel staff to know what guests to expect in to their hotel. Therefore, we integrated a listing feature which displays this detail on request, but otherwise, a weekly timed email that would send every hotel and up to date list of which guests they had in the following week, along with how many room nights were returned to the hotel as they had not been reserved. To make this possible, we used Views to get the required information and Rules to fire off the email to the hotel staff at the correct time.
Another main requirement of HotelSwaps was that they'd be able to give promotions to hotels and guests to try and increase the usage of the system. This would vary between being for one hotel, a corporate chain of hotels, or even for guests. After finding that some of these requirements couldn't be met by Commerce Coupon, we built on it to allow it to perform as required.