At Zoho, we do not follow strict working hours. Flexibility is in our culture and employees are free to work when ever they feel they can be most productive. Then, there are also the sales and support executives who go the extra mile; Work across time zones, thus end up working till late into the night. Traveling home was a problem for these employees as public transport would not be available at these odd hours. It was to tackle this, that the Admin team decided to introduce cab facility to those who leave at dark hours of the day. They started off with two cabs and it was easy back then to manage it manually, on trip sheets. But as the need for more cabs eventually grew, they needed an automated system to handle the scenario.
It was about the same time when Zoho Creator was fast becoming a much preferred online application builder and the logical choice, especially for such situational needs. You can’t find a ready-made application for these custom requirements. You’ve got to build one yourself, which is why we came up with
Book a Cab
. Here is the story behind it.
Cabs were made available from 9.30 at night to 5.30 in the morning. When we got started, the scenario we had in mind was a simple one, not anywhere near what we ended up implementing. This application had to allow employees to book their seats in advance, keeping in mind, plenty of criteria or logic as we call it. We began using this application when we were around 700 employees strong. We are almost 1500 now. Till today, we haven’t considered upgradation or maintenance of this application. It didn’t need any.
Here is what
had to say about the whole experience. “I was given the simple and raw scenario of booking cabs in advance, to start with. I did it, and it was ready
in less than an hour
. I am not exaggerating. The initial app had only a form and a view: form to book cabs by employees, and the view for the Admin team. That was all I could think of, then. Looking back, it was the best thing to have done because if we had sat there thinking what else should go into the application, we’d have been drooping over it forever. We deployed the application, half-baked though, and as data started flowing in, we identified the unique use-cases and included them all. This took us two more weeks of intense testing, to achieve the stage of completeness”, Rajesh said. He has been around for 4 years now, and was a student of
. This was his maiden venture into app-building and is well worth the mention.
Here are a few scenarios which added to the complexity of the application:
The application had to be publicly available.
Requests from employees alone had to be considered (filtering by email address which is unique: firstname.lastname@example.org).
On any given date, an employee should book once only. (no-duplication is achieved by filtering the records by email address).
The two cabs scheduled for 9.30 pm and 10.00 pm are dedicated to female employees.
For every time slot, booking had to be disabled once all the seats were occupied.
Booking four days in advance should be possible, but never for an elapsed time slot.
Booking for a time slot should be disabled 10 minutes prior to the commencement of the trip.
All these and more conditions had to be checked when entered records were edited, just as when they are initially entered. Twice in an application can be very degrading, but not with Deluge.
Deluge Script has been used extensively throughout this application. So abundantly that it replaces a powerful feature of Zoho Creator: the date and time field. At the time of developing this app, the date field alone had been implemented, and there was no date -time field . As for handling time slots, we used a pick-list, but differentiating between day and night was the real challenge.
What Rajesh did was to convert time into an integer. For instance, 4.30 AM would become 430 and 11.30 PM would become 1130. He has utilized two thresholds, 1200 for the night and 800 for the day. Comparing the time selected for booking with these threshold values, the application identifies night and day. It is too confusing to explain in English, the logic that originated in Deluge. So, we’ll let you take a peek at the code. We agree, the code is very out-dated and can surely be optimized a lot. But we just didn’t care to do it because it was good enough. And good enough worked just fine. Why bother then, to mess it up?
The application grew with usage, from a single form and view to two forms and five views, excluding the general feedback form and its view. Here is how scalability has been taken care of. Did you wonder why we use 800 in the code instead of 530 when the last cab is at 5.30 in the morning? It is considering future expansion of time slots. The second form of this application is to add new time slots, as and when the need arises. The various views are Current-day, All bookings, Time-Slot, My-cab and Front-office views. The first three are available for editing to the Admin team alone. They are pretty much similar, except for the fact that current day displays bookings for that day only. Time-slot lists all the cab timings and enables adding new ones too. Unlike All Bookings which lists all bookings, past, present and future (we support future booking too, remember?). Every employee can view all his bookings and edit or delete the future ones with the My-Cab view. Here too, past entries are disabled as they need not be edited. Front Office view has all bookings, but with no edit privilege, and is used by the logistics organizers.
Even though this application is highly custom-made to suit our specific needs, there could not be any harm in letting you
try it out
. Deluge script appears to be tedious to a non-programmer. Not in reality, though. Only when you try these applications, will you experience the power and ease of Zoho Creator that we almost always talk about.
If at all you come across
any ready-made application to address this highly situational need, let us know. We’d love to say