The “trip” aka booking, or ride, or duty (as our Shoffrs call it) is the fundamental construct at Shoffr. Everything here is built to deliver the perfect trip experience for our guests. But how does a trip actually work? Here’s the under the hood view.
A trip, like most other entities, has a life-cycle.

Booking the trip

The build-up towards a trip starts when a potential guest comes to our website and enter their pick-up and drop locations. At Shoffr, one of these is always is the Bangalore airport, the other could be anywhere in Bangalore city. We take these two points and calculate the distance and time (as predicted by Google APIs) this trip will take. This is then used to calculate the fare and show the checkout pop-up on the website (where guests can choose the use of toll, enter their details etc). Once the customer confirms the booking by entering the booking OTP, the booking creation workflow takes takes over.

The early stages of a trip are closely linked to the order entity (here’s how that happened). First we create an order and an order item (each of which corresponds to a trip), and then create a trip -all in PAYMENT_PENDING status. This means that a booking request has been initiated, but payment has not yet been. This is pretty standard design for order management systems.
The intent of this design is to confirm the order when payment confirmation is received from some payment gateway for online payments. While we built the system with this in mind, Shoffr does not have online payments today. So as part of the same “book” action, we trigger the confirm order workflow as well. This marks the order and order item as CONFIRMED. The effect on the trip is much more interesting.

“Confirmed” has a different meaning for a trip than it has for an order. Once an order is confirmed, we move the trip(s) underlying it to “CONFIRMATION_PENDING” state.

Confirming the Trip

Now we run our confirmation engine. While a lot of Shoffr tech is “simple”, the confirmation engine is one of the few “secret sauce” pieces which play a critical role in the business. The engine takes all the bookings we have at that time and tries to evaluate if we can serve the new trip without impacting the others. To do this, it marries our shift and car data, geo-spatial information from Google, and some statistical information from trip behaviour in the past (e.g. median delay in starting airport pick-up due to luggage coming early/late). Essentially, we are kind of solving the Traveling Salesman problem with “n” salesmen (number of cars) and real world unpredictability.

The engine can say one of two things: confirm/don’t confirm. If it says the former, we move the trip to BOOKED state and show a success screen to the guest. If the latter, we keep the trip in CONFIRMATION_PENDING state and tell the guest that we will confirm the trip in 45 minutes. Behind the scenes, this creates a task for our Ops team to
review and they take a judgement call on whether to accept the trip or not.

The original idea was that there should be no manual process involved. But we soon realized that the input to the confirmation engine was not accurate (incl. Google maps ETAs) especially during peak traffic hours, rains etc and so while so could judge some trips conservatively, we could not judge all trips precisely. Hence this manual process was adopted.

The ops team can now do one of two things: approve the task, which the moves the trip to BOOKED state, or decline the task which marks the trip DECLINED. The latter is a terminal state much like CANCELLED (which we use for cancellation post confirmation). All of these transitions trigger appropriate comms (SMS/Email/Slack) to our guests and internal teams.

Serving the trip

Now we move to the operational parts of the trip life cycle.

Our allocation engine picks-up trips 2-3 hours before their pick-up time and tries allocate them to the best possible driver. Like the confirmation engine, the allocation engine is a key part of our tech. It is meant to optimize for multiple variables like vehicle arrival time, vehicle travel time, and vehicle utilization simultaneously. In a way, it is a stricter, more real-time version of confirmation engine, because not only does it determine if a vehicle can go to do a given trip based on more data like telemetrics, it also determines the best suited vehicle for it.

• Once a vehicle is allocated to a trip, it moves to the ALLOCATED state and the allocated Shoffr can see it on his app. The next set of transitions are driver by the driver.
• When the Shoffr starts towards the guest’s pick-up location, he marks the trip ON_THE_WAY on his app.
• When he reaches the pick-up location, he marks it REACHED.
• When the guest has got into the car and is enroute to the destaination, the Shoffr marks the trip as STARTED.
• When the guest has been dropped, the Shoffr mark the trip as COMPLETED.

Evolution

The trip is such a central entity that its evolution is guided by pretty much everything else happening in the business. That makes the trip domain very fast moving and a lot of fun.

There are a few parts of the trip life-cycle that we are actively working on developing further.

The first is the communications aspect. We want to share a lot more information with our guests about their designated Shoffr which is context-sensitive and not spammy. This involves some geo-spatial intelligence and driving a lot of driver rigour on the ground.

Another is extending the trip life-cycle beyond servicing the guest and into the financial settlement world. We want to mange the financial settlement and reconciliation of the trip using trip states instead of doing it offline or elsewhere.

Stay tuned for more BTS info on this blog, and don’t forget to Book your Shoffr if you are flying in/out of Bangalore!