At AyAuto , what drove us was simple; give customers honest auto rickshaws at their doorstep and give drivers more customers.
Customers didn’t need convincing, and came on board immediately. Drivers on the other hand needed more than a little prodding, and a lot of oprant conditioning . As a startup with limited resources, and a model that was infinitely scalable – with some very serious constraints in terms of our bargaining prowess with our supply forces – we had to automate as many processes as we could, spend as little money as we could while focussing on running a startup with an untested model in a completely new market.
Now this was a mammoth task; a Dial-a-Rickshaw service meant we had to have a contact center, at least in principle. We started out with 1 SIM card and 2 call diverts. A day after we launched, we quickly realised this just wouldn’t do; we missed calls left right and centre, had no way to understand which calls were returned and which weren’t and our agents spent too much time entering a customer’s number into the screen.
When we asked around for numbers that could make and receive multiple calls simultaneously, we were introduced to the uber complex and expensive world of PRIs, EPABXs. They cost more than our first quarter’s budget to setup – the big ugly machine, an expensive telephone line from an operator, and the telephones for each agent – and much more to maintain – electricity, staff and space. Not only that, we are also warned, and omniously, that a fibre cut when a road’s dug up by the local corporation will ensue in a downtime of at least 4 hours. And from what we noticed every day, as we do in most Indian cities, roads were dug up everyday. The odds weren’t exactly in our favour and we simply couldn’t afford a downtime of 4 hours; that would be social suicide. Even if we were okay with all of these limitations, the process would take a month, and if our location was feasible enough! I couldn’t tell my customers that now, could I?
Enter Cloud Telephony. I still remember the day my co-founder and I came across Exotel’s homepage, in late 2011. We were thrilled. We called even though it was 10pm (they answered!), and they clarified the million questions I had about this. We moved our number to Exotel the very next day. This solved our problem of making and receiving calls from one number, having all that data integrate with our CRM and be down-right inexpensive to setup. And wow, my agents could answer calls from their cell phones itself!
Exactly 3 months into our AyAuto journey, we began scaling. And fast. So fast that we were burning money almost linearly. A look at our costs showed us that we spent too much time and money just tying up customers with drivers; so much that it was 90% of our revenue per booking. Let me illustrate.
The old process: A customer calls us for a pickup; we search our CRM for a driver within 5 KM (our autos were tracked with Mobile Triangulation and GPS); we call each of them up (50p per driver) and ask them if they can take the ride; we then call the customer up to confirm/apologise for the ride. Our call costs and the agents that were blocked because of this process added up. It simply wasn’t scalable.
After some brainstorming with Exotel’s CEO, Shivku, we implemented what I still consider a suave mix of Cloud Telephony and…old telephony. We decided to capitalise on Exotel’s new “Missed call” offering. We gave each driver an ID card that had numbers in the back. All these numbers were programmed as speedials in the drivers phone as well. Like thus:
AyAuto’s Driver ID Card (Front/Back)
Here, the driver would press speedial ‘3’ on his phone if he wants to go off for the day, and not receive any more calls. He would press ‘4’ if he wanted calls just now. And so on. Each call would hit Exotel’s server, and be automatically cut; so the driver isn’t charged anything and they loved this part! Exotel would then notify our server through their APIs about this driver’s status and AyAuto’s algorithms would take it from there.
The new process was was simple but very effective. When a customer called, our system would automatically lookup drivers in a 5KM radius, understand whether they were busy or free, and automatically send SMSes to them. An SMS looked like this:
We went a step further and automated a few more touchpoints – as you can see in the ID card above, there are a few speed dials for “Picked up” and “Dropped” as well. The driver would use these when he picks up or drops off our customer, respectively.
We learnt this during our times at AyAuto and are sharing openly now, so that you can maybe implement some of this in your travel, taxi, auto, cab, logistics businesses to automate processes especially in implementing technology with drivers, autowallahs and logistics folks in India.
Hope this helps!
Also read up on some other case studies in the travel & transport space by Exotel .