SCM Analysis of Food Delivery Startup Swiggy

2019
SCM ANALYSIS OF “SWIGGY”

SCM ANALYSIS OF “Swiggy” | Submitted To: Dr Nitin Seth
Table Of Content
1. Brief About “Swiggy”

2. Supply Chain at Glance
3. Differentiating Feature
4. Competitive Supply Chain
5. Bottlenecks / Challenges
6. Suggestion / Remarks
7. Analysis
8. References
---------------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------
1
BRIEF ABOUT THE COMPANY
Introduction
Food startups in India have garnered the status of industry unicorns in a short span of time in the Indian market. With
established firms such as Uber & Ola venturing into the food tech industry, the sector is sure to garner a lot of interest
and investment.
Swiggy is a leading food ordering and delivery startup in India. The company started operations in 2014 and is
headquartered in Bengaluru. Swiggy works by acting as a bridge between customers and restaurants. It utilizes an
innovative technology platform that allows customers to order food from nearby restaurants and get it delivered at
their doorstep. With Swiggy, customers do not have to keep the contact numbers of various restaurants and eateries
in their locality. Swiggy works as a single point of contact for ordering food from all restaurants that may be there at a
particular location. Swiggy has its own team of delivery professionals who pickup orders from restaurants and deliver
it at the customer's doorstep. This has made the task of ordering food a lot easier for customers. Restaurants also gain
by getting more orders and avoiding costs and efforts associated with maintaining their own delivery personnel.
2
History
The idea for Swiggy came in 2014, when the founders realized that there was a huge gap in the food ordering and
delivery space. Restaurants often faced manpower problems and their delivery personnel were also not trained to
deliver food in time. Swiggy started as a small setup in August 2014, with a team of six delivery personnel and covering
25 restaurants. However, the idea soon became a huge hit among customers and restaurants alike. Swiggy now has
operations in 8 cities and more than 10,000 restaurants on its platform.
Funding
Swiggy has received investments worth USD 155.5 million via six rounds of funding. Investors include SAIF Partners,
Harmony Partners, Naspers, Norwest Venture Partners, Bessemer Venture Partners, and Accel Partners.
End Term Submission | Course : Supply Chain Management 3

Acquisitions
Swiggy had acquired gourmet food startup '48 East' in December 2017. The acquisition of 48 East has helped Swiggy
to strengthen its service offerings and add additional capabilities as well. The deal was done for an undisclosed
amount.
Competition
Swiggy competes with other players in the food ordering and delivery space such as Zomato, Box8, Holachef, Dineout,
etc.
About the Founders

Swiggy was founded by Sriharsha Majety, Nandan Reddy, and Rahul Jaimini. Sriharsha Majety is an alumnus of Indian
Institute of Management, Calcutta and he currently serves as the Chief Executive Officer (CEO) at Swiggy. Co-founder
Nandan Reddy is an alumnus of Birla Institute of Technology and Science and he heads operations at Swiggy. He had
earlier worked at Galla, Zurna, IDinsight, and Intellecap. Co-founder Rahul Jaimini is an alumnus of Indian Institute of
Technology, Kharagpur and he is the Chief Technical Officer at Swiggy. Prior to Swiggy, he had worked at Myntra and
NetApp.
FINDING THE SOLUTIONS
The Restaurant Listing and Delivery Time Promise: The one thing that most people don’t realize is that the role of
delivery doesn’t begin when someone places the order, but as soon as they open the app.
When a customer opens the app, the first call is made to the Delivery system to figure out:
a. The restaurants that are actually serviceable to the customer, which means those from which a delivery is
possible within some stipulated time (say, at most 60 minutes).
b. The expected delivery time of an order from a potential restaurant.
An astute reader can already see the massive challenge.
First of all, how do we find serviceable restaurants? It’s the set of those restaurants where a customer could place an
order and have it delivered within the maximum delivery time.
But how can we calculate that? We roughly show 300–500 restaurants to each customer and consider thousands
more. If it isn’t shown within half a second, the customer will just leave the app.
Is it feasible to find all the restaurants such that a Delivery Executive can reach there, pick up the order and deliver it
to the customer? To even begin to do that, we need to calculate:
1. Assignment Delay: How long before we can find a Delivery Executive who can fulfill this order?
2. First Mile: How long before they arrive at the Restaurant?
3. Prep Time: How much time is required for the Restaurant to prepare the food?
4. Last Mile: How much time is required for the Delivery Executive to reach the customer from the Restaurant?
The Central Delivery Equation
Combining the components above, we arrive at the Delivery Time Equation:
Delivery Time = Max (Assignment Delay + First Mile Time, Prep Time) + Last Mile Time

The Delivery Time Components
A quick note about the formula: Since the assignment delay and first mile happen in parallel with the restaurant’s food
preparation, we take the maximum of the two times.
If we show too few, the customer will not place an order since his favourite restaurant may be unserviceable. At the
same time, if we take too long to show the list of restaurants, they will leave the app.
If we show too low a delivery time and we don’t deliver within it, it leads to bad customer experience. If we show too
high a delivery time, the customer may not order to begin with.
Everything in Delivery is about finding the Goldilocks value.
It’s about finding just the right time to ensure delivery, but not too high to discourage the customer from placing
an order.
It’s also about providing ample choice of restaurants to the customer, but just enough so we can calculate their delivery
times as quickly as possible.

Estimating Last Mile Time
Let’s start with the “simplest” of the problems: Last Mile Time.
Last Mile is the time taken by the Delivery Executive from the Restaurant to the Customer’s location. Well, you might
say, “Can’t you simply use Google Maps?”
Well no, not at our scale. And here’s why.
 Google Maps is just too slow for the number of combinations we need to calculate.
 Google Maps is prohibitively expensive.
 Google Maps doesn’t accurately predict travel times for people on two-wheelers (which most of our Delivery
Executives use).
 Google Maps doesn’t predict how long it will take for the Delivery Executive to go from outside the society
gates to actually reaching your door and handing over the package (AKA the last last mile). While this might
not make a big difference for other kinds of deliveries, an additional 5 to 10 minutes in food delivery can
significantly hamper customer experience.
Predicting Last Mile Time
So short of building our own Maps that scale to our needs, how do we solve this? Well it requires:
 Leveraging historical data: Swiggy, till date, has delivered millions of orders, and has a lot of data around how
long a delivery can take on a two-wheeler from a particular Restaurant to a Customer.
 Enhancing historical data with real time signals: Thanks to Swiggy’s unparalleled hyperlocal density, we can
leverage the travel time data of Delivery Executives currently doing orders to make predictions.
Estimating Preparation Time

Another big chunk of the Delivery Time is the time a restaurant takes to prepare the food.
Estimating Preparation Time when the customer first opens the app is a really tricky concept, given that we don’t even
know what or how much they might potentially order!
The Prep Time is driven by various factors:
1. Type of item: It takes much longer to make a pizza than it does to put a scoop of ice cream into a cup.

2. Number of items: It takes longer to prepare ten Kathi Kabab rolls than just one.
3. Load at the Restaurant: It takes longer to prepare an order if the restaurant is already busy serving many other
orders than if it has none pending.
Once again, we can leverage Swiggy’s rich data by looking at the restaurant’s and the customer’s order history to
estimate how long it may take for an order to be prepared.
We also need to consider other dynamic factors such as current load on the Restaurant, how long are existing orders
at that Restaurant are taking to be prepared, etc.
Predicting the Preparation Time is not only very important in showing an accurate Delivery Time, but it’s also important
in ensuring that the Delivery Executive reaches the restaurant only when the food is prepared.
Because, if a Delivery Executive arrives at the restaurant before the order is ready to be picked up, they waste precious
time waiting for food to be prepared instead of delivering other orders and, if they arrive too late, food goes cold and
well, nobody wants that, either.
Estimating Assignment Delay and First Mile Time

Now comes the really tricky part. How long will it be before we can find a Delivery Executive who can deliver this
order?
You know those times when you try to get a cab and the app says 5 minutes, so you go ahead and book one, just for
it to say, “Oh yeah no, it’s really 30 minutes.” Yeah it’s a hard problem.
The challenge here is that the demand for Swiggy is very dynamic, given that far more people place orders between 8
PM to 10 PM than between 4 PM and 6 PM.
So, our Delivery Executives are far busier during the Dinner Peak than during the early evening hours. Thus, during
peak times, it will take much longer to find a Delivery Executive who can fulfill the order.

So how do we estimate this?
Well, we track all the Delivery Executives and see their status. We can estimate how long it will take for them to be
available and start a potential new order. Again, you can see the tricky problems associated with this.
To begin with, the sheer scale of the issue. We need to keep track of every single Delivery Executive, what they are
doing, how long will they be delayed and then see their eligibility to deliver an order from the list of hundreds of
restaurants.
Furthermore, we need to accurately predict how many customers will order at any given time to decide whom we
should be serviceable to, given that we have a limited Delivery fleet and not everybody who opens the app ends up
ordering.
For example, if we show the list of restaurants to 10 customers even though we only have 1 Delivery Executive, we
will disappoint 9 customers who can’t place their order at checkout. However, if we reserve the Delivery Executive for
one of those customers and don’t show the list of restaurants to the other nine, and the customer does not order,
we’ve lost a potential order from one of the other nine.
Lastly, what if the Delivery Executive whom we have reserved, rejects the order?
You could say, “How about using historical data to get the average Assignment Delay and First Mile at a particular
point of time?” Well, that would only be right on average.
So you will end up disappointing half of the customers who are shown too low a value. But simply increasing it is not
right either, since every increased minute, results in fewer people ordering. Again, the answer is to cleverly calculate
the Goldilocks value.
We need to make estimates based on the current load of the Delivery fleet in the hyperlocal region and the current
distribution of fleet around the restaurants.
Lastly, we need to correctly trade off the buffer time to ensure that we show a high enough value not to give a
misleading promise, but low enough not to discourage the customer from placing the order.
The Supply Chain (associated with the delivery side of the system)
Types of Supply Chain control:
Complete Ownership — Dominos & Faasos — take ownership of the entire supply chain and production.
Asset light — Zomato & Food Panda — rely on large traffic volumes for order generation but outsource
delivery to third parties.
Hybrids — Swiggy — focus on providing a seamless user experience by controlling the customer experience

and logisitics.

The Restaurant Listing and Delivery Time Promise
The delivery part of the system starts when the Swiggy application is started by the customer. When a customer
opens the app, a request is made to the Delivery system to estimate:
1. The serviceable restaurants are identified, based on whether delivery can be made within a certain, stipulated
time.
2. The expected delivery time of an order from a potential restaurant.
First priority of the delivery system is to identify the set of those restaurants where a customer could place an order
and have it delivered within the maximum delivery time.
Restaurant:
A list of around 300–500 restaurants are shown to each customer .If it isn’t shown within half a second, the
customer will just leave the app.
To identify the optimal list of restaurants, such that a Delivery Executive can reach there, pick up the order and
deliver it to the customer on time:
a. Assignment Delay: How long before Swiggy can find a Delivery Executive who can fulfill this order?

b. First Mile: How long before they arrive at the Restaurant?
c. Prep Time: How much time is required for the Restaurant to prepare the food?
d. Last Mile: How much time is required for the Delivery Executive to reach the customer from the Restaurant?
Delivery time:
It is calculated using an algorithm based on equation:
Delivery Time = Max Time (Assignment Delay + First Mile Time, Prep Time) + Last Mile Time
Since the assignment delay and first mile happen in parallel with the restaurant’s food preparation, Swiggy takes the
maximum of the two times.
If too few restaurants are shown, the customer will not place an order since his favorite restaurant may be
unserviceable. At the same time, if a long time is taken to show the list of restaurants, they will leave the app.
If too low delivery time is reported and Swiggy doesn't deliver within it, it would lead to bad customer experience. If
too high a delivery time is displayed, the customer may not order to begin
The Goldilocks value:

It’s calculating the right time to ensure delivery, to not only provide a great experience (not too high) but also deliver
on the promise of delivery (not too low).
It’s also about providing ample choice of restaurants to the customer, but just enough so it's easier to calculate their
delivery times as quickly as possible.
Estimating Last Mile Time:

Last Mile is the time taken by the Delivery Executive from the Restaurant to the Customer’s location.
Calculating it:

1. Leveraging historical data: Swiggy, till date, has delivered millions of orders, and has a lot of data around how
long a delivery can take on a two-wheeler from a particular Restaurant to a Customer.
2. Enhancing historical data with real time signals: Thanks to Swiggy’s hyperlocal density, it can leverage the travel
time data of Delivery Executives currently doing orders to make predictions.
Estimating Preparation Time:

The time a restaurant takes to prepare the food.
1. Type of item: Different items have different prep times.
2. Number of items: It takes longer to prepare multiple units.
3. Load at the Restaurant: It takes longer to prepare an order if the restaurant is already busy serving many other
orders than if it has none pending.
The historical data stored by Swiggy is used by looking at the restaurant’s and the customer’s order history to
Also, other dynamic factors such as current load on the Restaurant, how long are existing orders at that Restaurant
are taking to be prepared, etc. are considered.
Predicting the Preparation Time is not only very important in showing an accurate Delivery Time, but it’s also
important in ensuring that the Delivery Executive reaches the restaurant only when the food is prepared.
Because, if a Delivery Executive arrives at the restaurant before the order is ready to be picked up, they waste
precious time waiting for food to be prepared instead of delivering other orders and, if they arrive too late, food
goes cold.
Estimating Assignment Delay and First Mile Time:

The demand for Swiggy is very dynamic, given that far more people place orders between 8 PM to 10 PM than
between 4 PM and 6 PM.
During peak times, it will take much longer to find a Delivery Executive who can fulfill the order.
Thus:
All the Delivery Executives and their statuses are tracked. It is estimated how long it will take for them to be available
and start a potential new order.
Swiggy estimates the availability based on the current load of the Delivery fleet in the hyperlocal region and the
current distribution of fleet around the restaurants.
Thus delivery of the orders successfully to consumers is done via using the customer's app to find the closest,
reliable restaurants around the consumer's local region and the availability and density of the Delivery Executives
around the region, plus the order delivery and order load histories of restaurants. Based on the historical data and
Google Maps, a highly accurate map is provided to Delivery Executives to deliver the orders in the optimal time.

Differentiating Feature:
Working on time frame:

As it happens in most of the cases that delivery time that has been proposed is not actual delivery time when one
orders food. In spite of the surge in orders, Swiggy has maintained an average delivery time of 36 minutes per order.
Very own Delivery Fleet:

Due to the possession of its own, independently-driven fleet of delivery personnel for picking and delivering orders
to its customers, Swiggy can offer their customers a variety of convenient features like faster deliveries, no minimum
order and live tracking of their delivery.

Top quality leadership:
Founded by Sriharsha Majety, a BITS Pilani and IIMC alumnus, Nandan Reddy, BITS Pilani alumnus and Rahul Jaimini
from IIT Kharagpur, Swiggy brings the best experience on boards at a time when food business is facing the digital
disruption.
Clever use of Restaurant menu:
Restaurants already categorize their menus (for e.g.: starters, entrees, desserts etc). Swiggy borrowed the system
and tweaked it a little to fit into the app by:
 Maintaining categories and adding subcategories to allow people to find what they were looking for more
quickly.
 Subtly suggest popular dishes that were quick to prepare. Less prep time meant faster deliveries and Swiggy
introduced Recommendations. Every restaurant had unique categories to accommodate their menus. Swiggy
added recommended dishes at the top of every tab, increasing the chances that people would select those.

Swiggy Dominating:
Swiggy entered the game early and built a core competency around owning the entire value chain and therefore the
customer experience. The fruits of that labor are plain to see.
Orders at Swiggy hover at the industry average (Rs. 300) but their customers tend to order far more frequently. The
implications these numbers have on annual order value per customer

Competitive supply chain
Self Restaurant Self/ Restaurant
74 cities (IN) 24 Countries 250 cities (world)

Swiggy founders invested in building a proper logistics network, with a vast fleet of their own delivery boys
and technology to back them. As soon as an order is placed, Swiggy will assign a Swiggy Delivery Executive
who will pick up the order from restaurant and deliver it to the customer. Zomato, UberEats and (Ola’s) Food
panda are credible players, but food delivery is not their core business.
As like other competitors lke Zomato and Uber Eats, Swiggy do not have minimum order criteria, hence a
customer can order from any of the restaurant available without any minimum order limit.
Swiggy introduced Cloud kichen model, which enable swiggy to ensure quality and availability of food, these
cloud kichens are operated by the partner restaurant which are selected on the basis of their reviews, ratings
and order turnover. These cloud kichens are exclusively for swiggy customers and with integration of the own
delivery model, swiggy has been able to provide fresh food even at late nights also.
Swiggy delivery boys handles one order at a time, and hence it increase total efficiency and customer
experience. Swiggy has a tentative TAT time of around 32 minutes which it further plans to reduce to 19
minutes for an order to be delivered.
While on other hands its competitors mostly rely on the restaurants to deliver the food and maintain quality
of the same throughout till it finally reaches customer.
Swiggy charges a good amount of commission as platform charge and delivery charges to ensure food reached
to its destination well within time with best of quality, it charges 15-20% commsions which is way to high while
Zomato & Uber eats charges 5-8%.
In the cutthroat competition, both Zomato and Swiggy have redesigned their complete app layout. Swiggy’s
VP of Design Srinath Rangamani adds, “At Swiggy, we aim to help users explore their choices in the easiest
and fastest manner possible. We realized that users often don’t get a chance to peruse the entire menu
because of the limited one-handed gestures that we are accustomed to. So, we redesigned the app in such a
way that the full menu could be accessed with a single vertical swipe. It needs only minimal navigation and is
suited to both left-handed and right-handed usage; all in an uncluttered and unconstrained environment.”
While on the other hand, Zomato’s redesign didn’t give them the results they expected and users and
experienced UI designers felt Zomato’s new design shifted its attention from food delivery app to restaurant
discovery app.
The main revenue model of both the apps being the restaurants that they have tied up with has favored
Swiggy over Zomato. Here is what a restaurant owner who is listed at both Zomato and Swiggy says, “ As a
restaurant owner, I would say Swiggy is much faster than Zomato with its service. It’s reliable for both
customer and restaurant owner as delivery boys come within 5 to 10 minutes when the order is placed and
once the order is picked, the responsibility lies with Swiggy. Even if a customer cancels the order midway,
Swiggy ensures the amount should be credited in the restaurant owner’s account. They even have a GPS
system to track the order which is good for the customer.”
Further the same vendor says “Zomato is slower than Swiggy and they COD which is, honestly, a tad bit of a hassle. It
is only good for online menu and not for delivery. Swiggy takes one order at time Zomato takes 2 to 3 order at a time
so because of their delay in service I generally prefer Swiggy over Zomato.”

The Swiggy Delivery Challenge
The Restaurant Listing and Delivery Time Promise
The one thing that most people don’t realize is that the role of delivery doesn’t begin when someone places the
order, but as soon as they open the app.
When a customer opens the app, the first call is made to the Delivery system to figure out:
 The restaurants that are actually serviceable to the customer, which means those from which a delivery is
possible within some stipulated time (say, at most 60 minutes).
 The expected delivery time of an order from a potential restaurant.
An astute reader can already see the massive challenge.
First of all, how do Swiggy find serviceable restaurants? It’s the set of those restaurants where a customer could
place an order and have it delivered within the maximum delivery time.
But how can Swiggy calculate that? We roughly show 300–500 restaurants to each customer and consider thousands
more. If it isn’t shown within half a second, the customer will just leave the app.
Is it feasible to find all the restaurants such that a Delivery Executive can reach there, pick up the order and deliver it
to the customer? To even begin to do that, we need to calculate:
 Assignment Delay: How long before we can find a Delivery Executive who can fulfill this order?
 First Mile: How long before they arrive at the Restaurant?
 Prep Time: How much time is required for the Restaurant to prepare the food?
 Last Mile: How much time is required for the Delivery Executive to reach the customer from the Restaurant?
The Central Delivery Equation

Combining the components above, we arrive at the Delivery Time Equation:
Delivery Time = Max (Assignment Delay + First Mile Time, Prep Time) + Last Mile Time

A quick note about the formula: Since the assignment delay and first mile happen in parallel with the restaurant’s
food preparation, we take the maximum of the two times.
If Swiggy show too few, the customer will not place an order since his favourite restaurant may be unserviceable. At
the same time, if we take too long to show the list of restaurants, they will leave the app.
If Swiggy show too low a delivery time and don’t deliver within it, it leads to bad customer experience. If it show too
high a delivery time, the customer may not order to begin with.
Everything in Delivery is about finding the Goldilocks value.
It’s about finding just the right time to ensure delivery, but not too high to discourage the customer from placing
an order.
It’s also about providing ample choice of restaurants to the customer, but just enough so we can calculate their
delivery times as quickly as possible.

Estimating Last Mile Time
Let’s start with the “simplest” of the problems: Last Mile Time.
Last Mile is the time taken by the Delivery Executive from the Restaurant to the Customer’s location. Well, you might
say, “Can’t you simply use Google Maps?”
Well no, not at our scale. And here’s why.
 Google Maps is just too slow for the number of combinations we need to calculate.
 Google Maps is prohibitively expensive.
 Google Maps doesn’t accurately predict travel times for people on two-wheelers (which most of our Delivery
Executives use).
 Google Maps doesn’t predict how long it will take for the Delivery Executive to go from outside the society
gates to actually reaching your door and handing over the package (AKA the last last mile). While this might
not make a big difference for other kinds of deliveries, an additional 5 to 10 minutes in food delivery can
significantly hamper customer experience.
Predicting Last Mile Time
So short of building our own Maps that scale to our needs, how do we solve this? Well it requires:
 Leveraging historical data: Swiggy, till date, has delivered millions of orders, and has a lot of data around
how long a delivery can take on a two-wheeler from a particular Restaurant to a Customer.
 Enhancing historical data with real time signals: Thanks to Swiggy’s unparalleled hyperlocal density, we can
leverage the travel time data of Delivery Executives currently doing orders to make predictions.

Estimating Preparation Time
Another big chunk of the Delivery Time is the time a restaurant takes to prepare the food.
Estimating Preparation Time when the customer first opens the app is a really tricky concept, given that we don’t
even know what or how much they might potentially order!
 Type of item: It takes much longer to make a pizza than it does to put a scoop of ice cream into a cup.
 Number of items: It takes longer to prepare ten Kathi Kabab rolls than just one.
 Load at the Restaurant: It takes longer to prepare an order if the restaurant is already busy serving many
other orders than if it has none pending.
Once again, Swiggy can leverage Swiggy’s rich data by looking at the restaurant’s and the customer’s order history to
It also need to consider other dynamic factors such as current load on the Restaurant, how long are existing orders
at that Restaurant are taking to be prepared, etc.
Predicting the Preparation Time is not only very important in showing an accurate Delivery Time, but it’s also
important in ensuring that the Delivery Executive reaches the restaurant only when the food is prepared.
Because, if a Delivery Executive arrives at the restaurant before the order is ready to be picked up, they waste
precious time waiting for food to be prepared instead of delivering other orders and, if they arrive too late, food
goes cold and well, nobody wants that, either.
Estimating Assignment Delay and First Mile Time
Now comes the really tricky part. How long will it be before we can find a Delivery Executive who can deliver this
order?
You know those times when you try to get a cab and the app says 5 minutes, so you go ahead and book one, just for
it to say, “Oh yeah no, it’s really 30 minutes.” Yeah it’s a hard problem.
The challenge here is that the demand for Swiggy is very dynamic, given that far more people place orders between
8 PM to 10 PM than between 4 PM and 6 PM.
So, Delivery Executives are far busier during the Dinner Peak than during the early evening hours. Thus, during peak
times, it will take much longer to find a Delivery Executive who can fulfill the order.
So how do we estimate this?
Well, Swiggy track all the Delivery Executives and see their status. It can estimate how long it will take for them to be
available and start a potential new order. Again, you can see the tricky problems associated with this.
To begin with, the sheer scale of the issue. It need to keep track of every single Delivery Executive, what they are
doing, how long will they be delayed and then see their eligibility to deliver an order from the list of hundreds of
restaurants.
Furthermore, Swiggy need to accurately predict how many customers will order at any given time to decide whom it
should be serviceable to, given that it have a limited Delivery fleet and not everybody who opens the app ends up
ordering.
For example, if it show the list of restaurants to 10 customers even though we only have 1 Delivery Executive, we will
disappoint 9 customers who can’t place their order at checkout. However, if it reserve the Delivery Executive for one
of those customers and don’t show the list of restaurants to the other nine, and the customer does not order, we’ve
lost a potential order from one of the other nine.
Lastly, what if the Delivery Executive whom we have reserved, rejects the order?
“How about using historical data to get the average Assignment Delay and First Mile at a particular point of time?”
Well, that would only be right on average.
So you will end up disappointing half of the customers who are shown too low a value. But simply increasing it is not
right either, since every increased minute, results in fewer people ordering. Again, the answer is to cleverly calculate
the Goldilocks value.

Swiggy need to make estimates based on the current load of the Delivery fleet in the hyperlocal region and the
current distribution of fleet around the restaurants.
Lastly, we need to correctly trade off the buffer time to ensure that we show a high enough value not to give a
misleading promise, but low enough not to discourage the customer from placing the order.
Swiggy is a data-driven company, and as its engineering team, we’re always considering how we can deliver data in a
meaningful way to the rest of the company.
To help the entire Swiggy team analyses information quickly and understand metrics better, it built Swiggylytics — its
very own customizable analytics SDK for real-time data.
We built Swiggylytics with the following goals in mind:
 To be able to remotely configure the SDK
 To mark or unmark certain events as real-time events and to drop certain events whenever needed
 Ability to drop/restore certain events from client
 To conserve device battery and memory and to avoid network latency
What’s inside Swiggylytics?

Swiggylytics | High level design
Config Manager Checks for the latest configuration on every app launch. If the config file has changed, then the
server returns the latest configuration. If not, a small payload packet is returned which means, “you shall pass!” ;)
Swiggylytics Core is the orchestrator that handles state management amongst sub-components like event router,
constraint manager, persistence manager and others.
Event Router responsible for routing the events based on the device condition, config, batch size, batch window etc.
For eg: real-time events are given highest priority in the queue.
Constraint Manager monitors all constraints like network (2G, 3G, 4G, and Wi-Fi etc.), battery (low, critically low
etc.), memory and others, so it can decide whether a certain event can be dispatched without impacting user
experience.
Beacon Service periodically checks if there are any unprocessed events in the persistence layer. If that’s the case, the
beacon service sends those events in a batch ranked by descending priority.
Persistence Manager maintains the local database, in case of device constraints or throttle conditions, so that
there’s no data loss, networking choking or any other issues.
Dispatcher is responsible for sending events to network, We use travelling window concept to batch the events
based on the time and batch size, This helps reduce network choking.
App state checks app life cycle like app foreground, background etc to flush the data accordingly.

Swiggylytics’ superpower? Customisability.
Swiggylytics is customizable — so if you ever want to dispatch real-time events, non-real-time events or even
dropped events, the configuration can be targeted with a variety of factors like app version, platform and many
others. Not just that, you can even control the SDK’s performance with global configurations!
The Swiggylytics control centre
Swiggylytics Dashboard
Swiggylytics dashboard allows for remote access to mark certain events as real-time or drop them and even filters on
particular app version and see the applied configuration. Global configs are used to control the SDK’s performance
and behavior like sync time, batch size of real-time and other events, retry times, timeouts, batch window size and
other factors. The dashboard allows for a user to set validation directly on the values or in the SDK itself for safety
measures!
How did we test Swiggylytics?

Testing Swiggylytics was a challenge due to the sheer number of config combinations. Just having unit & integration
testing alone wouldn’t suffice. We need compressive way to cover all possible use case and also test how the SDK
would behaves in real-life scenarios. To solve this we built a test app which mimics real-life scenarios like by invoking
multiple network requests calls, image download requests etc. This enabled us to check for the network latency,
memory, battery usage etc. In this environment we are able to trigger multiple events (100, 500, 1000, 2000 etc.)
through the app at once to see how the SDK behaves. This approach allowed to stress test the SDK and validate on
how throttling, persistence behavior kicks in. Having this test app helped us identify the design flaws earlier in the
development lifecycle.
Swiggylytics, as a product, has empowered Swiggy’s engineering, analytics and product teams to access relevant
metrics anytime they need it and make quick, data-backed decisions to improve the user experience, and build a
better Swiggy for everyone.

Everyone likes their food fresh! When we started Swiggy, we realized the time sensitive nature of the food business.
The quality of food is inversely proportional to the time it takes for us to deliver it, and in turn when it is consumed.
An ice cream melts in 25 minutes, and a pizza becomes soggy after 35 minutes. We realized that to deliver the best
on-demand consumer experience, we had to be in the delivery business ourselves. And here is where we introduced
live-order tracking for the food ordered. This allows our consumers to track the Delivery Executive’s (referred to as
DE) current location with utmost accuracy.
Delivering food is at the core of what we do. But to make it happen at a reasonable scale and efficiency, requires
having great coordination between our three users — Consumers, Restaurants and DEs.
Our interconnected marketplace — every piece on the customer experience is deeply connected to how the
restaurant and delivery variables are, at the instant
Unlike a traditional e-commerce company, Swiggy is a three-way marketplace in a hyper-local setting. Which means
that at every given location (lat-long) we operate, there needs to be a critical mass of consumers, restaurants and
DEs at all times to deliver an optimal experience. The demand from consumers also needs to match with the supply
of restaurants available in the area and should be deliverable at a reasonable time. This is a constantly changing
dynamic that needs to be managed by maintaining real-time accurate information.
To be a Hunger Savior is not easy
Being in the food delivery business in not easy and comes with a unique set of challenges. For instance, if a
consumer in a city wants to order a specific dish from his/ her favorite restaurant, but doesn’t find that restaurant on
the platform, we fail on our promise of variety.

If the consumer decides to order his/ her favorite dish, but the delivery time is 62 mins, we fail on our promise of
timely delivery.
If a consumer orders a particular dish, but we then find out that the restaurant is out of that dish, we fail on our
promise of availability.
But failing at the right things is what has helped us learn and improve ourselves, thereby enabling us to deliver 4x
more orders over the last year, across the 12,000 restaurants and eight cities that we operate in
The ordering experience, and behind the scenes
Using the Swiggy app is very simple as the app is geared towards the best customer experience, not only the
ordering experience. Which means we take various restaurant and delivery aspects into consideration to help you
decide what to order. Swiggy is a complete real-time platform. For every instance that the app is opened, thousands
of calculations occur instantaneously — your food preferences, the live snapshot of delivery executives in your area,
which restaurants are live, are you seeing enough variety, the range across all price points and cuisines, and many
many more.
The promise and predictability of the supply chain plays a huge role in consumer choice. There’s no doubt that we
encounter uncertainties in dish-preparation times, restaurant’s efficiency, DEs speed, changing traffic conditions,
and his familiarity with the area, to name a few. After you place an order and the restaurant confirms it, the
assignment algorithm takes those numerous factors into consideration and assigns a Hunger Savior to your order
accordingly, and the best route for him to follow. All of this happens in a matter of few minutes and it’s pure magic!

Data — At the center of all we do!
All of this is possible thanks to our focus on big data and an impressive engineering team that is constantly working
to ensure the roadblocks such as order preparation time, delay of the DE etc. are cleared quickly. The sheer beauty
of this lies in being able to capture and develop significant intelligence on delivery and restaurant volumes and their
variations.
The hyper-local context is another area, where we are building technology that improves consumer experience and
helps bring efficiency to the marketplace. We have to ensure that we keep a constant check on DE login volumes in a
certain area, zone-wise cancellation rates, demand-supply match in that area for both food and DEs. Today, this
helps our business and operations teams take the right decisions at the right moment. In the near future, many of
these decisions may be automated.

CHALLENGES
1. The advantage of swiggy having its own delivery fleet is also a challenge. It takes liability of the order away
from the restaurant and places it on itself. Other food services such as Foodpanda rely on its partner restaurants for
delivery, and therefore the blame could be attributed on the side of the restaurant whereas Swiggy doesn't share the
same privilege. As the other answer commented, this could translate into delivery times and the state in which the
food reaches the customer.
2. Another challenge is cost. There is very little money on each order when there was no order minimum. Even with
an order minimum of 250, with simple back of the napkin calculations, there isn't enough money to go around after
calculating for overheads, payment of the employees and delivery executives (essentially contractors).
3. Timeliness of delivery. Swiggy has achieved this by optimising many factors. The first is that it looks at data
on traffic and festival days to predict when it will need more delivery staff. The second is that Swiggy increases the
estimated delivery time (and sometimes even charges a "surge" fee) when the weather or traffic is inclement. The
third thing is the company has tried to reduce the number of interactions between its delivery executives and
customers. “A number of initiatives happen at the app level that make sure that DE [delivery executive] doesn’t call
customer and vice versa.
4. Packaging of the food when delivery.Food delivery firm Swiggy launched a marketplace program for enabling
packaging solutions to restaurants on its platform as it looks to diversify its play in the food technology sector. The
initiative called ‘Swiggy Packaging Assist’ offers restaurants, an access to a variety of packing solutions for their menu
needs with about 30 products to begin with. The marketplace connects restaurants with vendors of these materials
and offers eco-friendly and food grade certified materials including leakproof, sturdy, stackable, eco-friendly and heat
insulant packaging materials. Vendors on the marketplace will offer discounts of up to 5% to restaurants opting for
these solutions. Large food delivery firms including Zomato have taken efforts to move towards sustainable packaging
and reducing plastic waste - an inevitable accompaniment to the burgeoning food delivery industry. Zomato offers an
option to opt out of plastic cutlery while placing an order to minimise the use of plastic.
Swiggy Packaging Assist will see its catalogue expand to introduce eco-friendly meal trays and other items made from
materials such as cornstarch and bagasse. To enable faster adoption of sustainable packaging options at the restaurant
level itself, Swiggy is working with multiple design consultants and manufacturers to come up with innovations and
enhancements to the quality of packaging available in the country.
The Bengaluru-based firm is also building an on-ground team to provide customized solutions and consultation to
restaurants to improve their quality of packaging.
This is Swiggy’s second partner focussed initiative after it launched a partner financing program Swiggy Capital Assist
last year. That financing program, Swiggy claims, has been used by 363 restaurant partners across 10 cities, to grow
and expand business through access to additional working capital.
5. Food quality 4000 restaurants were de-listed by Swiggy for not having license or registration under the Food Safety
Law. Food Safety and Standards Authority of India or FSSAI in July 2018 had directed food e-commerce firms to de-list

the restaurants which don’t have registration under the Food Safety and Standards (FSS) Act, 2006. As per the Act, no
one shall commence or carry on any food business without license or registration under the Act.
6. Huge cost involved in logistics but the margins on orders are very low to operate.
7. Increase more order delivery by each delivery boys
8. Routing algorithm
Summary
Generating the list of restaurants for hundreds of people opening the app every second, and then accurately
calculating the delivery time for each of the hundreds of restaurants is one of the most challenging problems we are
solving at Swiggy.
As a data driven company, we religiously experiment with various strategies to get a sense of the trade-offs associated
with each strategy to figure out the one which not only matches the business goals, but also ensures the best customer
experience.
In the end, it’s all about the trade-offs and coming up with the Goldilocks value.
REFERENCES
 //economictimes.indiatimes.com/articleshow/65658677.cms?utm_source=contentofinterest&utm_medium
=text&utm_campaign=cppst
 https://m.dailyhunt.in/news/india/english/news+patrolling-epaper-newspatr/swiggy+company+profile-
newsid-80728099
 https://yourstory.com/2018/04/learnings-failure-making-swiggy/
 https://bytes.swiggy.com/the-tech-that-brings-you-your-food-1a7926229886
 https://inc42.com/buzz/swiggy-looks-to-become-king-of-hyperlocal-delivery/
 https://www.zeebiz.com/companies/news-swiggy-raises-210m-to-increase-its-supply-chain-network-
expand-to-new-markets-52130

SCM Analysis of Food Delivery Startup Swiggy

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SCM Analysis of Food Delivery Startup Swiggy

Uploaded by

Copyright:

Available Formats

2019

SCM ANALYSIS OF “SWIGGY”

1. Brief About “Swiggy”

End Term Submission | Course : Supply Chain Management 3

About the Founders

End Term Submission | Course : Supply Chain Management 4

FINDING THE SOLUTIONS

An astute reader can already see the massive challenge.

2. First Mile: How long before they arrive at the Restaurant?

The Central Delivery Equation

Combining the components above, we arrive at the Delivery Time Equation:

End Term Submission | Course : Supply Chain Management 5

Everything in Delivery is about finding the Goldilocks value.

End Term Submission | Course : Supply Chain Management 6

Well no, not at our scale. And here’s why.

Predicting Last Mile Time

Estimating Preparation Time

The Prep Time is driven by various factors:

End Term Submission | Course : Supply Chain Management 7

Estimating Assignment Delay and First Mile Time

End Term Submission | Course : Supply Chain Management 8

Types of Supply Chain control:

Hybrids — Swiggy — focus on providing a seamless user experience by controlling the customer experience

End Term Submission | Course : Supply Chain Management 9

2. The expected delivery time of an order from a potential restaurant.

End Term Submission | Course : Supply Chain Management 10

The Delivery Time Components

The Goldilocks value:

Estimating Last Mile Time:

End Term Submission | Course : Supply Chain Management 11

Estimating Preparation Time:

The Prep Time is driven by various factors:

1. Type of item: Different items have different prep times.

2. Number of items: It takes longer to prepare multiple units.

Estimating Assignment Delay and First Mile Time:

End Term Submission | Course : Supply Chain Management 12

Working on time frame:

Very own Delivery Fleet:

End Term Submission | Course : Supply Chain Management 13

Clever use of Restaurant menu:

End Term Submission | Course : Supply Chain Management 14

End Term Submission | Course : Supply Chain Management 15

Self Restaurant Self/ Restaurant

74 cities (IN) 24 Countries 250 cities (world)

End Term Submission | Course : Supply Chain Management 16

End Term Submission | Course : Supply Chain Management 17

An astute reader can already see the massive challenge.

The Central Delivery Equation

End Term Submission | Course : Supply Chain Management 18

Everything in Delivery is about finding the Goldilocks value.

End Term Submission | Course : Supply Chain Management 19

Well no, not at our scale. And here’s why.

 Google Maps is prohibitively expensive.

Predicting Last Mile Time

End Term Submission | Course : Supply Chain Management 20

The Prep Time is driven by various factors:

So how do we estimate this?

End Term Submission | Course : Supply Chain Management 22

We built Swiggylytics with the following goals in mind:

 To be able to remotely configure the SDK

 Ability to drop/restore certain events from client

 To conserve device battery and memory and to avoid network latency

What’s inside Swiggylytics?