Yesterday we launched the “Book return” functionality on Shoffr which will make it easy for our guests to book both onward and return trips in one go. They can now click on the “Book Return” checkbox, and select the pickup time for the return. We will create two trips for them with the origin and destinaton reversed and the two pick up times selected.

With the upcoming Republic day weekend, this is a great way to book a Shoffr both ways easily.

Why?

We have seen a fair number of our guests booking trips from their homes to the airport and back again, often on the same day, when travelling for work or for dropping off friends/family. People travelling into Bangalore for work do this even more often since their schedule is predictable.

The obvious thing to do after seeing this behaviour was to build the functionality to book return trips (like most travel sites do). This would save the guest the hassle of making two bookings and this convenience should give us more trips.

How?

There were two main problems in building this.

• We tough about letting guests choose both the pick up point and time for the return journey. But adding all this info would make our booking form very large. and confusing – potentially leading to drop offs.
• Managing the order lifecycle now that it could contain multiple trips. What happens when we could confirm one trip immediately but not the other? How do we do invoicing if one trip is cancelled? And so on.

Taming the booking form

In the beginning, we were asking guests to enter their name, phone number, email, location, landmark, and pickup time before we let them see the fare for the ride. Though we pre-fill these if the guests is logged in, it is still quite a lot. Adding returns to this would add at least two more fields.

We decided to trim down the booking form before we built return booking. I moved all the personal info fields to the ride confirmation pop-up and leave only location, pickup, and landmark fields on the home page. This freed up a lot of real estate on that page.

Once this change looked stable and we confirmed that was no change in the number of incoming rides, I looked at the data of the customers booking returns. It turns out that most of them were booking onwards and return rides from the same two points. This meant that for most guests, selecting another location would be unnecessary. Hence we decided to add one check book to indicate that the guest wanted to book a return, and a date-time picker for selecting return pick-up time. This way, even with the added functionality, we had fewer fields on the main page, leading to lesser cognitive load on our guests.

Multiple Trips per Order

I’ve lost the count of time I have “learnt” that cutting corner in core tech hurts, yet it happens 😦

I had decided early on that our Order entity will directly map to one Trip entity. This was challenged when we added the “Use Toll” option since toll would now have to another item on the invoice, but I managed by added a toll amount field in the order itself.

Bundling returns in the same order completely broke this since one “order” could now contain multiple trips. I could have hacked a little more by creating two order and then linking it via some field, but disgust finally overcame hustle.

I rewrote the order management system, the website, and the internal admin portal (which our ops team uses) such that an “order” can contain multiple “order items”, each of which maps to one “trip”. Orders and order items are highly coupled as they are both part of the order management domain. They share identical life-cycles, and impact each other when operations like cancellations, refunds etc happen.

This core change obviously led to a large fallout everywhere else in the system, most importantly in our website and in the admin panel used by our Ops team. Any code dealing with amounts amounts had to be re-evaluated and changed if needed.

Rollout

I started with removing the customer details fields. This was the least risk change since it didn’t change anything in the core order creation integrations, and the booking form could use a cleanup anyway.

Then we did the backend rewrite to introduce order items. The trick here was to add a schema transformation layer in our existing order API so that external systems like the website could continue calling them without being aware of the internal data model change. This was a little extra work but allowed me to deploy continuously instead of having to do everything in one big push.

Then just to be extra sure of everything, I added the “Book return” functionality to our admin portal. This would make life easier for our CX/OPs folks, but also let us test stuff in production without rolling it out to customers at large – a 10% rollout, if you will.

Then, I built and rolled out the feature on the website. This is available to all customers.

Evolving

There’s a few rough edges on the feature right now which we will fix very soon.

• Currently the return trip is always created as unconfirmed (though gets confirmed within 30 mins) because running the allocation engine twice added a lot of latency to the booking flow. This is obviously not ideal.
• Also in terms of communication, if one of the trips is confirmed but the others is not, customer get two SMS-es with different language which is a little confusing. We will clean this up very soon.

Have you booked your Shoffr yet? Come give us a spin – we are the best airport cab ride in Bangalore.