The Journey of a Gojek Jacket

By Abhinav Rai

It’s been just over a 100 days since Gojek’s rebranding exercise. New and consistent icons, naming, logo, fonts — a whole new visual appeal. This also meant our driver partners would require new helmets and jackets that embody our new design language.

When you’re a Super App that depends on 2 million driver partners, figuring out a system to distribute inventory to thousands of them at a time through our Driver Support Units (DSU) is no simple matter. This system has to factor in item combos, price points, discounts, and a scope to add new inventories — all without hogging too much of our partners’ valuable time.

The onus of building these systems falls upon our OpsPlatform team. But on a warm Thursday evening in late July of this year, when three of us from the team landed in Jakarta, little did we know we were in for a long weekend.

Gojek FaceOff (project moniker for Indonesia-wide events to sell & distribute inventory to our driver partners), was in a few days, and there was an inventory shortfall.

This is the story of that fateful weekend.

Here’s How It Went Down

The one where the jacket travels

Every Gojek attribute (Helmet, Jacket) comes with an RFID (Radio Frequency Identification) chip and a QR code with the same value printed on it. The idea is to map the jacket owner to the RFID, enabling better tracking and inventory management use cases in future. These jackets are produced at a central location, from where they make transits to smaller warehouses till they reach the DSU.

Every location movement for these attributes involve scanning the whole lot with RFID scanners and updating location for every scanned item in the Inventory Management System (IMS). Hence, solving the problem of monitoring, tracking, and alerting for low stocks at specific locations.

The one where sale happens

Every Gojek agent has the GoAgent app using which they can onboard drivers and sell inventory. Agents authorised to sell inventory start the sale by scanning a Time-Based One-time QR code (TOTP) displayed on the driver app to identify the driver.

After this, the agent scans the item QR codes stuck on the inventory. The best combos to maximise discounts are calculated based on our rule-based discount engine, and final values are shown to the partner.

If all looks good, the agent scans the QR code again (it changes every few minutes) as permission to start deducting the money in instalments (CICILAN) from the partner’s wallet. On successful scan, the complete record is saved at our end and a call to IMS happens, marking the sale as complete.

So far, so good, we thought.

We had another thing coming.

The one with the skewed inventory

Our system was built just like any retail store. You visit the store, get the item, pay and take the product home. But with three days left for launch, we received the news of an inventory deficit. Our backs were up against the wall.

Based on a market survey done by our Operations team, adding a pre-ordering capability was our best bet. This meant the driver would get the confirmation of the items purchased at the early bird discounted price, but would receive the items later when stock became available.

Before we discuss the solution, let’s first understand the main components of our technology stack, GoRetail.

• Agent App Backend — Handles all requests from app, does preliminary checks and passes inventory requests to Inventory service along with agent details.
• Inventory Service — Gets all inventory requests, routes it to different services, validates requests, combines their response, and returns the response to the agent app.
• Inventory Management Service —All about inventory — names, images, availability, SKU tracking, locking inventory for driver X at store Y at a configurable time.
• Discount Service — What’s a store without configurable discounts? Supports discount on first N combos/items for a specific place for a specific time period.
• Pricing Module — Knows the price for each item. Saves the old prices and variations.
• Transaction Service — Responsible for performing the transaction and storing the full record (Jacket with id JID sold to Driver D at time T by Agent A for price P in DSU DS). This talks with Go-Fin’s CICILAN (or later to GoPay) for making discounted payment for specific drivers and then saves the transaction record on success.

With this Architecture, We Had Three Options

• Go traditional with the earlier approach: Manage everything on Docs till a system was built to cater to pre-ordering. The data would later have to be dumped into the system via scripts.
  Delay in launch: 0 days
  Cons: This manually-entered data would need to be inserted for many of the microservices shown above, leading to a lot of scripts and potentially high error rates.
• Build a new flow for pre-order items: Separate the dependency of attribute distribution from payment. There would be a new flow in Agent app having a separate option for pre-order and supporting APIs in Agent App Backend, Inventory Service and Transaction Service for the change.
  Delay in launch: 5–7 days (2 pairs)
  Cons: This would mean cancelling stadium venues booked for FaceOff events, invalidate earlier comms sent, and break the whole spirit of rebranding. 🤦‍♂️
• Have dummy QR tags for pre-ordered items: All these Pre-Order item codes would start with PR (for others, they start with 61). This allows us to check if the transaction is a pre-order, and this is what the logic for fulfilment flow would be. This approach required us to add another item called Jacket Garuda Preorder in the IMS and repeat the combos with their discounts for this new pre-ordered item.
  Delay in launch: 0 days
  Cons: Lots of data feeding initially. Prior to the launch, all the data feeding was done by scripts via rake tasks as this data wasn’t to change much.

For eg: discount on Jacket Garuda and helmet combo should be the same as discount on Pre-Ordered Jacket Garuda and helmet combo.

Once actual stock arrived a few weeks later, agents could scan the driver QR codes again, and our system would pull up a list of their pre-ordered items. Once handover is confirmed, the pre-order details would be replaced with the details of the sale.

After heated discussions between business, tech and operations teams, we decided to go with the third option — dummy QR tags for pre-ordered items. 72 hours before the start of FaceOff, our team of three freshers in Jakarta, and their Tech Lead at our Bangalore office, got to work.

Three sleepless nights ensued.

We seeded the new items and their codes in the IMS, replicated the combos, prices, and discounts for these new pre-order items, and made a few changes in the Agent app to cater to the new needs. (Phew).

With time running out, we frantically tested the new flow several times.

It held up. 🙌

The events went off as planned, and after catching up on some well-earned sleep, we finally travelled to Surabaya to attend one of the events.

The one with celebration

Since its launch in July, our system has received incremental releases of pre-order fulfilment flow, a portal to configure combos, discounts, and prices, as well as options to add new DSUs and new OTP login flow for agents. This has served over 350k+ drivers in 60+ cities across Indonesia, and is built in a way that it can be replicated in any new country with a snap.

As the Gojek motto reminds us every day — #PastiAdaJalan — there is always a way. 🖖