Case Study: Technology tactics to handle 300% demand with about 50% supply

Covid pandemic is obviously a want-to-forget event these days. In HoChiMinh city, the situation is even worse with the whole city lock-down. As a foreseeable result, delivery demand peak in our platform, up to 300%, while our supply significantly dropped up-to 50% at early days of the event. The type of demand also shifted from multiple verticals to mostly groceries.

After experiencing unexpected low operational metrics at beginning, eventually, we have stabilized our services by many tactical actions, mostly based on our distinguish technologies. Hence, I want to note down in this very rare occasion to prove technological effectiveness with such fluctuated demands:

1. Drop demand: we calm down demands by surging price of different services at various geographical areas, so that users can opt to choosing another time or service to place their orders.
2. Increase supply: we prepare full instructions with official e-paper from AhaMove to grant our drivers doing delivery, so that our drivers are more confident to get out to the streets without fear of punishment from authority. We also use live map tool to monitor driver locations and inform them hot areas.
3. Focus on grocery delivery: grocery delivery has some differential attributes over others: it doesn't require super fast fulfillment like food, and it naturally centralizes in finite cluster of stores, so we can offer a new grocery-fit delivery service, which is auto-optimized to combine orders into multiple-dropoff trips and delivered within 2 hours. Wow, it works great and improve operation effeciency a lot, in the context that we have fewer drivers these days.
4. Compromise SLAs by flexible matching rules: delivery and ride-hailing are both well fit on-demand vehicle-based enonomy, but they are also slightly different. The fact is: Ride-hailing is more expected on short waiting time than delivery, and it may lead to an effect that ride-hailding app prefer auto-assigning order to drivers as this way will give best experience at user side to see their request accepted. On the other hand, delivery accepts longer wait. Hences, while we adopt auto-assign mechanism to achieve faster matching, we won't cancel non-matched orders, but let them be listed on the platform in a period so that our drivers can see and accept some of waiting orders. By defining max concurrency allowance in our platform and flexible matching rules, we can adjust capacity of a driver and improve acceptance rate with a trade-off of longer acceptance time and delivery time.

Balancing supply & demand is an interesting problem, especially at big scale. Many factors and side effects can affect to a single representative metric - acceptance rate, and in our case study, this metric is improved and optimized in such a special occasion by not only one but many measurements, some are ad-hoc implementations, but most are well prepared from a long time and now all exposed in a single right time. As the time of this post, we now can serve up to 160% demand and keep improving our performance day by day.