By Megha Goyal

When GoFood started out back in 2015, our promise was simple: Tell us what you want to eat, and we’ll deliver it to you. As we spread out from Jakarta, satiating the hunger of millions of customers in most parts of Indonesia, GoFood as a product got increasingly complicated. Orders started to pile up, and we were struggling to keep up with the skyrocketing demand. If we wanted to keep up with users’ expectations, a few things needed to be done. We had to change, and simultaneously up our game.

It’s a VUCA world, and we often remind ourselves that not a lot of things are constant. We’ve been working hard to reimagine, re-engineer and redesign the GoFood flow which hasn’t been altered too much for many years.

To help you understand how it all started, let’s take you back in time a little bit…

When the Gojek app for ride-hailing was launched in early 2015, we noticed there were times when our driver partners had lean work periods. To provide additional means to help them make use of this time and earn more, GoSend (to send couriers) and GoShop (to buy anything) were launched as auxiliary services.

We noticed that majority of orders placed in GoShop were for food. This gave way to GoFood, our dedicated food delivery product, launched in mid-2015.

Phase 1: Listing Model

GoFood started as a concierge model, where we had no tie-ups with restaurants. A Salesforce was deployed to list as many restaurant menus as possible on our platform. When a customer placed an order, it would be assigned to one of our driver partners, who would then go and place the order at the restaurant. The driver partner would wait around, and when the order was ready, pay in cash, pickup the order and deliver it to the customer.

Tedious? Yes. Scalable? No. 🤷‍♀️

Phase 2: Partnering With Merchants

To arrive at a scalable solution, we realised we had to take the restaurant merchants along with us in this journey and welcome them into our ecosystem. We started partnering with the merchants, who were known as ‘GoFood Partners’.

This not only helped our merchants grow their businesses, but also got ample visibility boost on GoFood.

Even after onboarding them into our ecosystem, a large part of the process was manual. It was far from ideal because there was no record of transactions besides a booking on GoFood and a receipt handed to the driver partner.

Often there were discrepancies in the number of orders assigned and the number of orders completed. How, you ask?

Imagine a GoFood partner who is part of a large chain of restaurants. When someone orders food from this chain, GoFood assigns this order to one outlet. However, the driver partner may decide to visit another outlet and pick up the order, as per convenience.

There were more problems galore.

If a merchant partner was not open for business on a particular day, and wanted to update their menu, or indicate items as out of stock, they had to call the Gojek Customer Care. During this time, orders would still be coming in, which resulted in driver partners accepting orders that most certainly couldn’t be completed without a hassle.

There was a lot that needed fixing here, and it could only be done by integrating merchants more deeply into our ecosystem. So, that’s exactly what we did.

Phase 3: The merchant app, GoResto

Towards the end of 2016, a concept was developed for an app that would cater to merchant partners, and by early 2017 GoResto (which is what we called it at the time) was ready.

We introduced the following in GoResto:

1. Electronic payments

All of Gojek’s driver partners had GoPay e-wallets associated with their accounts. With GoResto, we did the same for our GoFood partners. Transactions between driver and GoFood partners was directly wallet-to-wallet, hence, cashless.

2. PIN exchange for restaurant verification

To ensure the order is secured, driver partners would also need to share a PIN with the merchant while picking up the order. This electronic handshake helped us verify they were indeed picking up the right order from the right outlet.

3. Catalog management

We noticed a lot of cancellations were happening because the items were either out of stock, restaurants were closed or customers were generally skeptical about ordering dishes that didn’t have enough reference images. So, we started focussing more on improving the product experience for our customers and BCR (booking completion rate). Catalog management was introduced so that the merchants could regularly update details that customers saw on GoFood. For example: Availability status of dishes that were put on the menu, uploading details pertaining to different items sold, etc.

In the meanwhile, GoResto was rebranded to GoBiz. What started off as a product that helped merchants to manage their food orders, started evolving into something bigger. Since the scope extended beyond GoFood, calling it ‘GoResto’ made no sense.

The rebranding came with enhanced features in GoBiz. As you might’ve guessed, it also came with new, enhanced problems and a sub-optimal flow:

⚠️ The driver partner was ready, but the food wasn’t

The average time taken for a driver partner was:
~9 minutes to pick up an order
~19 minutes to deliver the order

A portion of this time was spent by the driver waiting for the food to be prepared, because in most cases, GoFood partners started preparing food only after the driver arrived! This was mostly because customer would add more food items or the ordered items would be out of stock. We figured that the driver arrival time could be parallelised with the food prep time. This led to 2 important things:

  • Overall delivery time for the customer could be reduced
  • Wait time for the driver could be utilised to fulfil other orders

️️️⚠️ GoFood Partner-driven cancellations existed, accountability didn’t

GoFood partners had the ability to set their open hours and change item availability, but they didn’t always keep it updated. When cancellations pertaining to these reasons happened, they were handled by…the driver partners. 🤦‍♀️
This meant, the orders had to be cancelled either by the driver partners or the customers themselves.

Items being out of stock or restaurants being closed accounted for over 35% of all customer cancellations after a driver was assigned.
On the driver side, these accounted for over 75% of all driver cancellations. 😓

⚠️ Price edits became pricey

In this order flow, the driver placed the final order with the merchant. This essentially means that the original order placed by the customer could be modified due to various reasons: Incorrect listing of price, unavailability of items, adding new items to the order, etc. To accommodate these cases, drivers were allowed to input to final price of the order, leading to a price edit.

And price edits aren’t uncommon. They happen to ~34% of the orders.

Multiple moving pieces exposed these orders to skip payments or consumer wallet sweeps.

Phase 4: Introducing Merchant Acceptance Flow

Due to various reasons, our driver partners were handling GoFood partner-driven cancellations and heavy-lifting to ensure the orders were fulfilled. This, too, had to change.

After brainstorming, mind-mapping and head-scratching, we arrived at Merchant Accept Flow (MAF). The merchants who are onboarded to MAF are called Super Partners. The solution lets our Super Partners accept/reject orders based on the restaurant being open, availability of items, or any other factors that determine order fulfilment or cancellation. This in turn helps our customers and driver partners know that the merchant is preparing food for sure, so that there are no customer or driver cancellations.

In Part-2 of this blog, we’ll dive deep into Merchant Acceptance Flow, how we went about designing it and introducing Super Partners to our customers. Stay tuned!