The first is getting customer address data. So address data can be available in different forms. As you know, the data, the address itself in India is not structured. All across India, you have different ways of writing addresses. And there is no set format that you can put even if you're collecting address in the most efficient manner that you think. So the challenge becomes more, I would say complex for third party logistics company because then you're dealing with data, address data collected from different clients who have different ways of collecting the addresses. And then, so the first, this challenge can be met by, you know, putting a logic where you have all the customer address data from the different clients in one format and that should be just text. And with whatever the, there are occurrences of a particular client, you can remove it and then put all the addresses in one place and that becomes your corpus of the customer address data. Second step is address structuring, which is I would say the heart of it. If you have it done right, you have the automated in the run sheet right. And why is there, and none of the algorithm, let me tell you will work with the efficiency that you expect it to work for if you don't have structured data, structured customer address data. Why do we need this structuring of the address data? As you know, there is no constant format of the address as I mentioned before also. There is no spelling check that is put when you're inputting an address. It's a free flow text in most of the cases. And there are combined words because customer is inputting, he or she can write anything. They can combine the words, they can write things which are not meaningful. We had instances of occurrences of addresses which said in the address field, you say, we got to see that you cannot find me, just call me on this number. So you can have addresses like that, which is not any address information. So you can just leave it. Then there could be abbreviations, right? Few abbreviations which are needed, few abbreviations which are just customers, you know, way of writing it. So how do you take care of all these things? This is very much required if you are trying a machine, learn something from an unstructured data that to address data. Now, how do we do the address structuring? Now that we know all the problems that exist, the first thing that we will talk about is basically creating a vocabulary. Before you even go and think of doing a spell check or doing, separating the combined words, what you need is the ground truth. You need some source of data which will help you do that. Do a spell check or do a separation of the combined words. And how we can attain it is by using a basically reverse geocoding approach where what we did was for a particular dispatch center, you create a grid of lat-longs, decide on the distance that you want between them and then reverse geocode them. Now, Google has a particular way of storing the address which is mostly formatted. If it has the address, it will be formatted. If it does not have the address, it will give you no address. Now, how it is formatted is not necessarily in this form where I have shown that this is the formatted way, but it is generally separated by comma. In your original address, there is no separator. Trust me, there is no separator which you can use universally across your address to separate the words. When you go for Google Maps reverse geocoded address, you see there is a comma separated address and it becomes very clear that something at the end is actually a pin code. Now then the second last is country. Then you have city and similar things. So you have an idea of what these tags possibly can be, what each segment of the address is. And then from here, you can create a base of each of these tags, be it locality or be it sublocality, roads for that matter. In Bangalore, we have mains crosses and then build over it. So that becomes my source of truth. I know that these are the sublocalities which exist for Kormangala. So suppose I am dealing with Kormangala DC, I know that Kormangala first block, fourth block, fifth, sixth and some layouts. These are the part of localities which will show up in my addresses. So that becomes my ground truth. I built a spell corrector over this data. So whenever, so, and here, when you're doing a spell corrector, any similarity algorithm, not a usual similarity algorithm can help you. Now you cannot go ahead and use an NLTK's spell corrector because NLTK is not built for this purpose. It has not used address data for generalizing its library. So you cannot use that library. In most of the cases, you cannot use a predefined library. So you have to build things from scratch and they're not difficult. So you can develop a similarity score for each of the words that occur in your address with this base where you, I'll show how you can do that, where you just compare and replace. So basically what you're doing with this step is cleaning the address, cleaning in the format of spell check and removal of the combined words. The third step when you will get into named entity recognition because it encompasses the natural language processing, you'll have to go through the pre-processing part of the data before the first step was cleaning, getting rid of spelling miscorrections and combined words. The second step is pre-processing the data as a textual data where you basically tokenize the words which are available in the data. So when I'm saying data, it is each address. So you're tokenizing the address into words that is existing in the address. The address is cleaned now. Then you're removing this top words. In general, addresses do not have so much of stop words because it's not, and it should not be an English flow of sentence, but you can have stop words of addresses itself. Remove, people might write anything. So just to be extra cautious, remove all the English stop words and also remove the address stop words that you see, which might not add any value to your algorithm. The third thing, important thing that you have to do when you're doing named entity recognition is a supervised training data set. How do we attain that is, according to the steps that I have shown so far, what you have now is each address, all the words in that address, clean the address, separated and treated for the pre-processing aspect. Now, there is training that you have to do. Now, why am I training it? What is the goal of the training? The goal of the training is basically to identify the entities, right? Identify entities and the entities here are tags. So the first step is to create these tags, which you want in your address data. What we did, we went ahead and we found out around 43 tags that will define addresses. When I say tags, these are something like, you can see in the example here, there is house number 36, wire strangle apartment, SD-bed layout and then the address continues. Now, in order to show how tags can be formed is, house number 36, I have given a tag FNS, FNC, FNC. Now, FN is a tag, which is flat number. FNS is starting of the tag. FNC is continued, continued. So the moment I extract FN from this particular text, I get flat number. Similarly, BNS is building name, start continued. And the moment I extract BN from this text, I get building name. So these are the tags. The tags are FN, BN, sublocality and similarly. So based on the address that you see, you can tag them, this is actually a manual process where you'll have to go through the addresses to understand for each dispatch center, what are the ways in which the addresses are written. Do this dispatch center generally deal with, are there many roads around it? So it will have multiple road level tags instead of you say anything like sublocality. Might be it is identified by roads than by sublocality. So that depends again on the kind of data that you're dealing with or a particular dispatch center that is around a particular locality. So once you have these tags finalized, you go ahead and train the data for around, what we did was around 8,500 addresses for a particular dispatch. And the training is not supposed to be heavily manual. Once you have decided on the tags, what you can do is train them through a macro basically or write a function to train it. Whenever you see an apartment, you tag it as BNC. And there are multiple things that you can automate and then go through the automatically generated train set to manually verify it. The next step is building the model. Now that you have a trained data set which is giving you tags for each of the word, what you want to build is a model that given an address will give you the tags for each of the word in the address. And the model that we tried was maximum entropy. And what maximum entropy does is if you have information, multiple information about a particular class, it helps you weigh them based on the different data points that it will see and gives you the class accordingly. So maximum entropy model also allows you, so it basically works on features. It helps you put your own features into its processing. So you can build feature data points which are, say n grams. Now what are n grams? Basically combination of words or tokens. So suppose I build features on my data set, address data set and say that whenever the third word of a trigram or the last word of a trigram is an apartment, APT or APART or whatever, all the ways that you want to put it, the tag which follows before it is BNC or BNS. Now this becomes one feature. You can also put features like landmark indicators. We also had one tag which is called LMI which is landmark indicator. Now they become very important. They're really important because you can put conditions like if you see a word in a biogram which is opposite, near, above, below, then just say the tag is LMI. So these are the features which will go into Maxent and it learns with the data and also the features that you have passed to it and gives you the tag for each of the word given a particular address. And the accuracy of this that we saw was 98%. So the Maxent does a real good job in giving you the tags of the words of the address but that's not it. That's not something that we are building. That's just the first step towards what we are building. So the second step is geocoding. Now that you have the tags for the addresses, how do I geocode it to get the exact point where this delivery boy has to go and deliver the shipment? Now in the geocoding itself, what you'll do is basically get the tags for all the addresses, form a priority of the sequence of tags that you see in each address because not all the tags, an address can be lengthy as 45 words, 50 words. Not all the tags are important. Not all the tags can get you the exact pin point of where they should go. So basically you have to form a priority sequence of tags and then create a geocode layer over it. When I say priority sequence of the tags, what do I mean? Basically give priority to all the tags which help you identify a pin point of the customer address and what are those tags? Generally the tags like building name or set of building name, set of building being tech parks or any smaller organization kind of a thing. Then you can have apartment names. All these things have more, much more priority than a sub locality or a locality because when you geocode a locality or a sub locality, what you get is the centroid of that locality which is not helping FE in reaching the customer. So what you want is exact points. So all the apartments and buildings, they have higher importance. Definitive landmarks have higher importance than non-definitive landmarks. What are definitive landmarks? Generally landmark indicators which with words like above, below, opposite, they are definitive. It says that it is there. There can be landmark indicators which are near, around this much kilometer away which is not a definitive landmark indicator and they have very low priority. So that's how you define your priority of their tags and then you geocode it. When you geocode it, you have to put a logic in place when you pass a lat long to the Google API which is geocoding. You have to pass a combination of the different tags that you have got. So you can pass apartment name along with a locality or you can pass apartment name with a sub locality, apartment name with a road or something and then check on which one of it is giving you the highest accuracy because accuracy of the lat long that you're getting is very important. It should not be one kilometer inaccurate where the FE is just roaming around. Now the next step and the final one is actually to cluster. Now that I have addresses, I have the lat long for each of the address. I've identified the tags, used the tags to geocode and I have the lat longs with 200 meter accuracy. What I would want to do is still my DRS is not automated. I would want to automate the creation of DRS and how can I do it is for every dispatch center early in the morning, you can run a job which does all these things in the background and once you have the lat long, you cluster them for that particular dispatch center. So when you're clustering, you basically get a few clusters which is defined by, I would say, majorly the sub localities that this particular DC deals with. So this might be, if it is just Kormangala fourth block, this can be one layout, SD-bed layout, Achandra ready layout or the other layouts. So because each FE is assigned to each of these sub localities. What we've used here is a modified K-means because there has to be a business logic put in when you are clustering also. You cannot, so what if you're clustering and one of the cluster has 15 shipments, the other cluster has 85 shipments. So you have to put a logic where you are putting a threshold on each cluster containing at least 35 shipments or whatever is your norm of the company that each FE should deliver at least this much per day. And then you can also customize it. So if at a particular day, you see that the attendance of the FE is supposed to be 10, then the usual is suppose 15, then you put your clustering as 10, cluster K, with K-means with K as 10 and you get 10 clusters. Thinking and in most of the cases, FE's know the locality well. So they can go to each of these cluster and then deliver it. Now, how does it function? This clustering is what it has done is has created a label of cluster name with each of the addresses for that particular dispatch center on that particular day. Now, when this center manager walks in this morning in the center, what he does is just scan each of the shipment and what he sees is the route number or say the shipment pile number. So basically he'll see that this belongs to route zero, this belongs to route one, this belongs to route two and he keeps piling each of the shipment based on whatever route number it displays. And when the FE's walk in, it just takes 15 minutes. We reduce the time from three and a half hours to 15 minutes. And then when the FE's walk in, they don't have to wait because the center manager is shuffling and sorting, but they just pick their pile and they move for there. And this also, we also automated the printing of the DRS where every route will get, you know, all the shipments that belong to it and you just print the DRS and hand it over to the FE's. So that's it that I have. This is how you can automate. If you guys have any questions, I can take them. No questions? Oh. A couple of questions. First is that what is the advantage of doing all the natural language processing before using a service like Google? You can just throw the address itself to Google geolocation and get the lat long. Okay. We did that. So that is the first thing that comes to your mind when you are doing anything around geocoding or reverse geocoding. But trust me, it does not work because of multiple things. When you are throwing an address to Google for geocoding, it needs the address in a structure format. It needs you to give it the, give it the apartment name or whatever is the POI along with sub locality or something which it can map. If you don't give it, if you give it pass it a random address, it will give you the lat long of the centroid of whatever it can identify in the address. Sometimes it identifies the state. It gives you the lat long of the state center. Sometimes it identifies just the locality in the address and it gives you the centroid of the locality. But that's not something that we wish for. What we were wishing for is the exact point where the FE needs to go. And we could not achieve it by doing that. Hi. So yeah. Thanks for the talk, it was very interesting. So how do we ensure that the process that you described for determining the lat long, that it's always within 200 meters, like, is that? Yeah, that's why I had it in the recommendation aspect. It's not always possible. It depends on a lot of things, I will tell you. It depends on the previous step that you have followed. It depends on how good is your tag at the first place where you fitted a Maxent model. How good is your Maxent? If the tags that have been identified by Maxent, how good is your priority of the tags that I described? And how good is your combination of the priority of the tags that you're putting to the Google API? As I said, Google API works in a certain manner. And you have to exploit it in the best manner possible. That's why we were doing a combination of the tags, important tags, and passing it to the Google API. So for one particular address, I would tell you, we were hitting Google API like 15, 20 times and getting the lat long for that particular address only. And then comparing within that address which one has the maximum accuracy by looking at the distance from the DC or from any fixed point. So that's how you, that is a process that you'll have to kind of fine tune and curate on your own. There's no set way which I can say, but one of the ways that I have done is something that I've explained. Hi Divya, thanks for such insights. I was wondering, have you guys taken care of language input as well before NLP? No, because most of the addresses coming from the clients, it was in English. So we did not take care of the language aspect. We did not run into it, I would say. Had it been there, then yeah, one step ahead would have been the conversion or translation of the languages. Hi, so if you put in, say, 100 addresses, what's the time it takes to do the geocoding? How many of those 100 would you have to manually correct the whatever input? The geocode stuff or the training? From address to the geocode. Okay. How in 100, how long will it take? How many of, what percentage do you manually intervene? And do you create, do you have to keep hitting Google over a period of time or do you can shortcut Google, say, over a period of time? So, okay, to answer your first question, how much time does it take? Generally, we were running it for each DC, which has a load of around 20K, at least at a particular time of season. So for that particular time, we ran it for, it took seven, eight minutes for the entire algorithm to run. So it is not much of a time consuming process. And second is how many, the second question of yours was, how many out of them do you have to manually intervene? So once you do the entire process and the flow is created, you don't have to go and manually check them. But yes, we were collecting feedback. Initially, when you roll them out, you're collecting feedback from the FEs on how well you have been able to identify the lag logs. So that process continued for 15, two weeks or so, where we took the feedback and fed it into the system. So that is one thing, but manual process comes only in the training side, where I showed you the supervised training happening. So that is the process where the manual it will come, which also you can automate to an extent. To your answer of how many times do I have to Google, hit Google API? Well, Google does not allow you store addresses or the details. So ideally you should not be storing them and hitting them every time that you are using the API. Correct, correct. So what, but then you have used the entire Google's resource in order to build it. So it is actually, I would say, companies call whether they want to store it. We were not storing it and we were hitting the API because it did not take much time. We were hitting the API every time and we were paying for the API. So that was, but yeah, you're building a database of your own with support of Google. Hi, so once you have the geo code, would not a routing, a vehicle routing problem be more useful to your use case than a clustering formulation? Correct, yeah. So I did not explain here, but within each cluster we did vehicle routing as well. But you don't necessarily need it because of, I would say a phenomena that is very popular here because the FE's know the entire area. They have it on their tips of the mouth.  But yes, in case you want to get rid of that manual human intelligence also, you can just go ahead and route it within each cluster. So that's what we did. So I think routing it within each cluster makes more sense than routing it across the clusters. So how do you define these clusters? Are these already defined that these areas fall into cluster A or B, or is it real time? So for example, if I have a pickup from Coal Mangala, will it be picked up with HSR pickups or with the Domino pickups? Okay, so when you're doing this entire process, it is happening for a particular dispatch center. And dispatch center in logistics is basically the end point from where the delivery happens. So this dispatch center will be one dispatch center only, which will be Coal Mangala. It will deal with shipments dealing to around Coal Mangala or around that center only. So you will never hit up a case where you have shipment from HSR coming into this. And how do you define the clusters? It is real time. It will happen based on the shipments that have been received that day. You might have a few shipments, you know, larger shipments for a particular sub locality that day. So it will be richer cluster as compared to the other one. So that's how it happened. And how do we include the time slot part in this? Yeah. So time slotting, we had to modify the clustering logic. If you're supporting time slotting, like there are a few customers who want delivery to be done in this time slot. So you basically within each cluster, you'll have to create sub clusters. And then see if that makes sense. If there are just one shipment that is happening from three to five, then particularly you'll have to include in your routing within the cluster. And put it at the end. And this is what it was a combination of both clustering and routing. So in the routing logic, you'll have to put that time bucket in consideration because not all of the shipments in our case had the time constraint to it. Any more question? I think we're out of time. Thank you, Divya. So the next speaker is Aditya Madan, who is Senior Product Manager at Flipkart. And he's going to talk on perfect grocery deliveries, solving location problems unique to India. Over to you, Madan. Good morning, everyone. Thanks for being present here on a Saturday morning. I know most of them you've been partying on a Friday night. So my name is Aditya and I am part of fulfillment service group at Flipkart. I am part of the product team. And today I'll be talking about the location problem. Some of the aspects that Divya also mentioned in her talk that how this problem is very unique to India and how at FSG or Fulfillment Service Group at Flipkart we are solving that problem. Okay, so the agenda for today is I'll be introducing FSG or Fulfillment Services Group what at FSG we are doing currently. Then I'll be talking about the location problem of India and what is the impact of location problem to the supply chain and what is the havoc that it's causing on the supply chain then how FSG is solving that problem and the way forward. What is our vision to ensure that we deliver the best in class customer experience that we promised to the customer. So introducing FSG, what is Fulfillment Services Group and what it is responsible for at Flipkart. So Fulfillment Services Group is responsible for ensuring best in class customer experience after the customer has placed an order. By this what I mean is that once the customer has placed order on a Flipkart website from that point till the order is delivered to the customer and even beyond delivery the entire experience is controlled by the services offered by FSG. FSG offers different kind of services and to get into detail of those services I'll quickly walk you through what is the entire flow of a journey or order journey after an order has been placed. So quickly talking about it whenever an order is placed it's created into multiple shipments. Each of the shipment then flows through different facilities or the supply chain network that exists within Flipkart. So a shipment will flow through a fulfillment center. So we have hundreds of fulfillment center and it will then flow through a sortation center where it will be sorted further to move it to a delivery hub and from delivery hub it moves to a customer. Now think about a situation where you have hundreds of fulfillment centers you have hundreds of sortation centers thousands of delivery hubs and millions of packages are moving through this complex network. So there are millions of packages that flow through the complex supply chain network and you'll be hearing about this more when my colleague Senthil talk about this in his presentation on orchestration and network intelligence. So just giving you a brief to tell you how a shipment flows through the supply chain network within FSG. Now coming to the address problem in India before moving further I have a question like how many of you understand your address? Like all of you, right?  Okay, so why I ask this question is that I want to share a few examples of how India understands the addresses. So this is an example of a very good address where the user has been kind enough to provide the details about house number, the apartment name, city, locality and all the things, right? So user very well understands the address. Another example of a address that user has provided. So as we move forward, right?  So here the user has only provided locality. So user believes that this is what the understanding of my address is and this is how I've been giving my address and this is how everyone is able to connect through me to my address. Moving forward, the user says that a locality or a landmark. So this is my address, right? Anyone who has to connect me has to come to near this bus stop and I'll be there. Another example looks like a perfectly good address. If you see one of the important address attributes here is the pin code. The pin code is something that the Indian Postal Service has provided us. That's how the entire geography of India has been divided, right? But I don't think that all the users have understanding of the pin code also, right? So in this case, in this example, the address is of some other pin code. It actually belongs to 560017 but the user has mentioned pin code 5600103 and this is because of numerous reasons like one of them being that this is how traditionally they have been writing address and this is how they write it. And this one is my favorite, right? So this is example of an address where user has provided, I think a lot of information here, right? And user has shown great intent to actually find himself also, right? So the user has mentioned that you can ask anyone. So just translating whatever you can ask anyone and they will take you. So I think thanks to the user for giving a good intent of the location. What exactly they want to do, right? And helping RFEs to reach to the location, right? So this is how a snapshot of how India understands the address, right? So each and every user, each and every customer, everyone has its own understanding of the address, right? And there is no right or wrong, right? And why there's no right or wrong because address itself is a combination of numerous attributes. And all those attributes are not standardized, right? There are a bunch of attributes such as state city or even pin code which can be standardized across. But then that does not solve the problem, right? So consolidating all this, what are the problems that are associated with addresses in India, right?  There are zillions of addresses, multiple combinations of how user understand, multiple attributes. As I mentioned, none of the attributes are standardized, right? For example, city like Bangalore have crosses, right? City like Delhi has sectors. Even within a city, Delhi has sectors, Delhi has nuggers, they have gullies, right? So you don't have, you don't get the luxury of standardizing the attributes. Another problem is that the addresses are organized very poorly physically, right? So logically it looks like sector 23 has to be next to sector 24, right? Or house number 43 has to be next to house number 42. But that's not the case always. So the logic division does not work always within the Indian context. And as I have shown you numerous examples, users don't know or understand their addresses, right? And all these problems are further accentuated in tier two, tier three and tier three plus communities which are the next growth engine for the economy as well as the e-commerce industry. So what does this all mean for the supply chain, right? And I think Divya also mentioned in her talk, right? It results in a lot of inefficient manual planning. And why manual planning? Because you have to rely on the local knowledge of your hub managers or your field executives to actually do the entire out planning. To actually do the entire shipment flow planning. Another problem that it creates is unoptimized shipment flow. So in my first slide, when I talked about the flow of how order moves through the various facilities within the supply chain network. If let's say customer has given one wrong pin code, right? Then it can enter into a different facility from which it is supposed to be delivered. Which would mean that either an order is delayed or the customer is contacting multiple times, the customer is supposed to know where my order is. And the third most important thing is customer discovery in the last mile. I'm sure most of you would be an online shopper and may have faced this situation that delivery boys are calling you that, okay, I'm here, how to come to your location or are you available, right? So the discovery of the customer, and mind you, the customer has given the right address. So customer has said that this is how I know my address and this is how I've been giving my address. So now it's your responsibility to come to me, deliver it without disturbing me, right? So what does this all mean, right? All this pans down to one point which is degraded customer experience. So a delivery boy calling multiple times to the customer, right? Is very relating for the customer. Shipment not getting delivered on time, or whatever time has been promised is again degraded customer experience. So keeping all this view or all the problems in mind, how at FSG, we are solving this problem. So before jumping into the solution, what we feel is that every address has to be standardized in some form. One way of doing that is obviously you get into different standardized attributes. You create labels of address, right? But ultimately the micro point for doing or the micro unit level for doing any planning is the geo codes. So what I'll talk to you about is and how we are solving the problem of geo prediction, right? Different companies are doing it in different way. So today I'll talk about how FSG is solving that problem. So what at FSG we have been doing is we have built a flip location intelligence platform which we called as flip. Flip is a crowdsource platform with the aim of geo predicting each and every lat-long and we use machine learning algorithms and some of the techniques that we use I'll be talking about the flow of how do we geo code and address. Within flip when I say crowdsource platform, right? We are not using or not relying on data source from one particular source. We are using multiple data sources. One of the most important being one of our own database. I think there was a question from another gentleman in the audience that over the time you get your own database then why are you not leveraging it? So this is what we do exactly. We are leveraging our own database because we do millions of deliveries and we have got millions of exact location points that has its own set of challenges which I'll talk later but that's one of the very important database that we have built. The other database that we use is map my India data. So we also rely on their own, their network how they have created the idea of localities, sub localities and all that is called as the location type. So I'll give you a brief about how do we geo code using a geo location service that we have built. So you see an address mentioned here 691 Shahid Bhagat Singh apartment pocket three Dhuarka. This address is fed into the geo location service as an input. So address attribute is a standard input and we tokenize an address. So again if we are talked about some of the tokenizing techniques we follow some of those techniques and I've also built on top of it. So a token, what would a token look like? If you see at the bottom of your screen Dhuarka is one token sector 14 Shahid Bhagat Singh apartment pocket three. These are examples of a typical token that will come out of an address and these are very few examples. There are numerous tokens that are created within that address. For each and every token we retrieve a polygon. What do I mean by this? So for Dhuarka as a token, we'll obtain a polygon. Now how do we get a polygon for Dhuarka as an address? We have done a lot of deliveries on the locations where Dhuarka is one of the address. So we'll have many geo coordinates available for that. So we'll take each and every geo coordinate and generate a polygon out of it. Once the polygon is generated, right? Each and every polygon for each and every polygon for each and every token. Area intersection score is calculated. So what do I mean by area intersection score is? So for example, in this case, let's say sector 14 as a polygon. So sector 14 intersecting with Dhuarka. We calculate what is the intersecting area of a sector 14 polygon with a Dhuarka polygon and divide this by the total area of sector 14 polygon and come up with a score of a particular polygon. This process is repeated for each and every token and the area which has the highest score is returned or the polygon which has the highest score is returned. So the idea of taking the intersection is that we get as close or pinpoint the exact location of the address because that forms the basis of the precision or accuracy of your geo prediction. Now, how do we get to the geo prediction accuracy? Once a polygon is returned or once the final polygon is selected with the highest score, we create a bounding box across that polygon and we take the diagonal of that polygon as the precision accuracy in meters. So what are the critical outputs of a geo location service that we have built? So latitude, longitude and precision. So precision is very important to know exactly that okay, what is the level that you are operating or you are geo predicting? And that's a very critical output because different precision levels are required for different use cases and applications. So this service has a lot of use cases and application and some of them are like navigation. Another one is like identifying what is the exact customer location for a field agent. And another one is automated beat planning or route planning that we do. And I'll be talking more in detail about the automated beat planner that we have at the FSG. So before going into details of what is automated beat planner, what it all is doing, how it's consuming the geo location service, I'll quickly introduce the concept of beat. So beat is nothing but a sequence or order or route that a field executive or a delivery executive follows on the ground when he's handed the shipment. So every day delivery executives are handed say 40 to 50 shipments and they deliver those shipments in certain order or and following a certain route. So that is typically called as beat in supply chain language. Moving forward to automated beat planner. So with automated beat planner, we have, we take number of inputs, we process this inputs and the idea is to generate a automated beat plan which maximizes or which minimizes the overall cost of the delivery, but ensures that the guardrails of customer experiences are maintained. So let me detail out some of the inputs that go into automated beat planner. One of the inputs is order size, right? What do I mean by order size? So number of shipments that are there in order, typical characteristics of a shipment, which is like what is the size of the shipment, what is the type of the shipment, whether it's a hazardous material or not. So all those inputs which are associated with every shipment, what is the category of shipment goes as one of the inputs. Then geo codes, which is coming out of flip service, geolocation service, slot time or delivery time. What are the delivery times or slot times that customer has chosen or what we have promised to the customer for the delivery capacity. So we have different type of vehicles that are available in our supply chain to attempt deliveries, beat vans, beat bikes. So each vehicle has certain capacity or there are different ways of defining capacity. So we define what is the maximum carrying capacity or what is the range of capacity that you want to operate into. And the other important one is the traffic. So what are the traffic conditions that exists on a particular day at a particular time of the day? So all these inputs and there are other inputs as well. These are major inputs that we are currently consuming in automated beat planner. All these inputs are fed and ABP processes. And once ABP processes, the output is a beat plan. So the beat plan is generated to again minimize the cost. And when I say minimize the cost, it's function of numerous factors here. The productivity, the number of shipments that a field executive can deliver, the capacity or how much utilization you have done of a vehicle. So all those factors contribute to the overall cost equation. And we ensure that the guardrails of the customer experience are maintained. You don't want that you have made a promise to your set of customers that we'll deliver by this time. But to minimize on the cost, you miss that promise. So the idea here is that we continue to deliver best-in-class customer experience. But by deploying technology, we keep on reducing the cost of operations. So that's the overall journey of an automated beat planner that how it does. Now, let me talk more about what happens when a beat plan is generated. If you see on your screen, this is a UI that is shown to our planners. It tells completely what is the area. What are the different, what is the different routes that different delivery executives have to follow? What is the order? So each and every geo location here is an address or a customer location where delivery is supposed to be done. There are certain features that we give to our planners. One of them being manual override. So what I mean by manual override is that whenever a planner feels that one of the orders is not planned in an efficient manner, right? There is a chance to or there is an opportunity to move it from one beat to another, right? Why would that happen, right? If the system is predicting it, why would a planner want to do this? Or why we have given this functionality, right? So what happens is that many times at ground, right? The reality on that particular day may not be exactly what has been planned, right? For example, you have planned for 10 beats assuming that 10 field executives would come every day, right? But there has been an attrition or not all of them have reported or let's say all of them have reported but because of some unforeseen circumstances, one of the field executive had to cut short his delivery of today, right? So that's one of the reasons why we have given this plus every model or every system with have certain accuracy, right? And this is a continuous evolving process. We take feedback of every delivery that we do and we feedback into the model. So we keep on improving the accuracy but whenever there is an error rate, we throw it out of a delivery area and then we have to rely on the ground knowledge. The idea is that we want to do away with it but if we don't give that address, we have to deliver it, right? So all the exceptions are handled in different manners, right? Some of those we even call the customers to try to get a better feedback of their addresses, right? But those cases are very small and the idea is that we reduce or minimize those cases or those use cases with time. So the services that powers the key features automated beat plan are geo location, which I've already talked about, the geo distance service. So geo distance service basically gives you the distance between various lat longs. So you basically feed the lat longs and it will give you a road network distance between different lat longs and we use to create a distance matrix to come up with what is the route plan that has to be created. Maps interface, so the entire map interface that you are seeing on the screen, this is a Flipkart map interface. So this is created on the data. So we create our own tiles on the base data that we have in our database as well as we use the map idea data to create tiles and this map interface is powered by Flipkart itself and traffic prediction. So these are the services that are currently used by automated beat planner to do the entire beat planning or the run sheet planning. So what is the way forward? Looks like, okay, we are solving the problem for address. We are moving away from manual planning. We are doing the automated planning but is that good enough for customers? Is this pushing the boundaries of customer experience? So we at FSG believe that there is a lot of room to push the boundaries of customer experience itself. So what we want to get to is a perfect matching of supply and demand. Now, before going forward, let me talk to you what I mean by perfect match, right? A perfect match means that each and every shipment or each and every order should be assigned to a particular delivery channel in a perfect manner. When I say a particular delivery channel, what it means is that a particular field executive, a Kirana store or a third party logistics partner and who will define this, right? So there are two key stakeholders that are involved in this entire operation. One of them is of course our customers and the other one is our field executives or our delivery executives, right? So customers will themselves keep on pushing the experience boundaries, right? They will find that, okay, for me, perfect experience is that you are able to deliver it to me whenever I want, wherever I want and that is my choice, right? You are able to deliver me without contacting me even for once, right? And for our delivery executive partners, right? They would want that, okay, I want to do deliveries from this time to this time only. I want to do deliveries in this particular area only, right? So the matching or the perfect match of supply and demand is dependent from the supply partners which is our field executives as well as our customers and this is our vision. This is what way forward that we want to go to. So this brings to the concept of the allocation engine, right? Again, the idea of an allocation engine is to ensure perfect match of supply and demand, match each and every shipment, each and every order with the most convenient or the perfect delivery channel and there will be a lot of input services to it. I've already talked about FLIP and ABP, the location platform and the beat planner. The other key critical service that we are building and that will form the genesis of allocation engine, right? The most important one being customer availability service. So what do I mean by customer availability, right? Can I predict during the day or during the week, the point when the customer will be available to make a delivery attempt? Now, what do I mean by that? Many of us place orders on our office address, right? Because Monday to Friday mostly in our peak times we are in our office, right? Imagine a situation where I as a customer have placed an order, right? I have been given my office address and I've been given delivery date or I've chosen by mistake delivery date as Sunday, right? Now we know that a customer will not be available there on that particular day, right? So if we can predict for each and every address or each and every customer input when the customer will be available, right? This will become one of the important components which will again push the boundaries of customer experience. The another service that is very critical to push the boundaries of customer experience is FE scoring engine. So FE is basically the field executive or the delivery executive. What do we mean by FE scoring engine, right? Now, different FEs or different delivery executives will give different performances, right? None of the two people are similar, right? So we want to ensure that the feedback or the performance of each and every FE is given as input to the allocation engine. So as to ensure that the customer experience is not degraded. Example is that let's say one of the FEs has, one of the FE says that the customer is not available at the location. But actually the customer was available. He made what we call a fake attempt, right? So we want to get that and power that into the allocation engine. Another thing on the supply side for the perfect match is FE skill and preference. So as I mentioned that every FE would have preference of delivering certain time in delivering certain area. So we captured that. And FE skill, so what do I mean by this is that certain categories may require certain skill to do a delivery. A category such as TVs or washing machine, which would at the time of delivery require some kind of demo versus a category such as mobile accessories will require different skill levels of the FE. So we take this input and push this and other one being service and capacity engine. So for each and every delivery channel, we have different capacity and different service ability. So what we want to ensure is that every shipment is given to a certain delivery channel, which ensures a perfect matching of supply and demand. So this is the vision that we want to move towards and are working towards this. So that's pretty much. Thank you. Happy to take any questions that audience might have. Hi Aditya, my name is Santil Kumar. Hi. I'm here. Sorry. Okay. See what kind of accuracy where you guys able to attach in terms of identify the exact location in terms of distance. For example, 10 meters, 20 meters or anything of that kind. Okay. So before answering you that question, right, I'll give you one example of a live experience that I experienced on the field, right? And what I did was I went with one of my field executives, right, on the field. We have pointed him to an accuracy up to 20 meters, right? And believe me, even after making few calls and he be going into one direction, I go into another direction, we were not able to find the customer location, right? And why this was right, because customer had never mentioned his house number outside his house. And the gullies that we went into, right? I have never been to those gullies, right? So why I'm sharing this example is because this has different accuracy levels are required for different applications, right? If let's say I am doing a shipment planning, right? That which delivery hub it should land into, right? Then maybe I don't want to get into an accuracy level of 100 meters, right? I want to get into an accuracy level of one kilometer is good enough for me, right? But if I am doing a planning for the last mile delivery, right? Then we want to get it as close to as 200 meters, right? Now, how we have arrived at this number of 200 meters is we have a internal metric of, let's say how much reattempts are happening, right? So we see that, what is the sweet point at which the reattempts start flattening out, right? So we figured out that sweet point currently is 200 meters, right? Having said that, that is not the, I'll say the best number. The reason being that it will change across the geographies, right? We move into a tier three cities, that number can change again, right? So this number, I'm talking more about the metro cities as of now. So this is what we achieve towards or plan to do towards. Hello, Mike. Hi. I'm sorry, I think we have to stop right here because we're already out of time. So thanks, Aditya. Thank you. We can catch up outside, right? For any questions. I'm sorry for the time. Right after this talk, there's a, tea break. So we're running late about 10 minutes and so the talks are all shifted by 10 minutes. So the next speaker is Jairam Kasi, who is a co-founder of picole.com and he's going to talk about using visualizations for addressing fleet management problems. Over to you, Jairam. Good morning, everyone. Unlike me, this is going to be very short. So what I wanted to talk about was our approach towards solving data-centric problems first through a visualization, right? I mean, this is the typical flow that we as data scientists take. We visualize the problem, we help business users visualize the same problem that we are seeing and we understand what kind of decisions are they making? Are they choosing door one or door two, right? And then we make a study of those decisions and then we build it into some kind of either logical algorithm or some kind of machine learning optimum algorithms, right? So ideally, so this is a very dynamic data set and I will tell you how we've used this for one particular use case, which is freight matching, right? So any data set, right? We convert that into a data set of decisions which business users come up with, right? And then that gets converted into an automated algorithm. Now, what am I talking about when I'm talking about the approach, right? What we typically do is a ground up approach which relies heavily on what kind of variables are there in the data set rather than looking at it as a charting problem, right? So if you look at visualization as a charting problem you are limited by what is available to you in either the BI tool that you're using or any charting library that you're using. When you're building things from ground up using, see, there are a lot of very powerful JavaScript or Python libraries for it, right? There is D3 which is available in JavaScript. There is Py... Processing which is available in Python. What that helps is transferring the kind of insights that you want directly to a business user that it is visible to him as some sort of a attribute, some sort of a visual attribute, right? So first you look at the data set and there is a very interesting paper by Colin Ware which talks about pre-attentive attributes which basically are in four different categories which is color, form, some sort of spatial features like position, right? And movement, right? And all everything that you talk about like shape or length or width or collinearity form some sort of a subcategory of each of these, right? Or if you look at color, there are further subcategories of color like hue, saturation, lighting. So once you understand this sort of a split of pre-attentive attributes, whenever you see any visualization, you try and decode what the person who's built the visualization wanted you to read in the first place, right? Then you look at the detailing which is required. When you have to encode information for a business user to decode, you also have to know up to what grain that he wants to go. And finally, and this is one of the most key areas actually is the design choices that you're making. Are you going to use multiple hues in the color scale that you're using?  What is the kind of values which are there, right? So here it is not just a data science problem. It's also a design problem. It's also a UX problem. It is also a psychology problem. It's also a consumer behavior problem, right? So I'll talk about how we've done this for one particular use case that we had which is freight matching. Talking a little bit about pickle.com, we are a 3PL service provider for sensitive cargo. So we ship white goods, furniture and certain sensitive cargo like ATMs, servers, things like that, right? So we get a lot of mid, I mean, long haul LTL loads. When I say LTL, it means less than one truck load, right? So it is important for us to be able to visualize what kind of load, what are the kind of loads which are coming in a similar date range and in a similar territory so that we will be able to couple them and send. So this also is a purchases problem for us because purchasing team is not able to visualize what kind of loads are there which is there between two cities. So once there is a data set which is coming up which shows how costs come up, come down drastically over the larger load size in a long haul scenario. So it also gives the purchases team the ability to forecast what kind of truck loads we'll have to place, right? So roughly this is how it is going to be, like there are multiple ports where shipments keep coming in a very random Poisson process, right? So it's a chicken and egg problem for us. We cannot cut costs without volume going up. We cannot get volume without cutting the price, right? So if you look at the typical total cost which is to be for and compare it against shipment size, it comes down exponentially over time, right? And the marginal cost for a volume of shipment is almost asymptotic, right? And the curious case is that the smaller trucks can be sent only for a smaller distance. So over smaller distances, the aggregation opportunities are smaller, but over a larger distance, it becomes increasingly more, right? If you look at an international use case, there are loads that we can couple actually from multiple cities coming to a same port, then aggregate and send to the destination country and then split the shipment from there. Another problem that we have is that the demand patterns are highly skewed, right? Even though the net average demand for the company is more or less the same, but channel-wise demand is heavily dependent on projects. Let's say if we get a project suddenly to deliver 200 shipments in Delhi, it just comes in a very seasonal manner. So this is the dataset that we are talking about. We have, we map the city locations. We have the places and we have the location attributes and we have the load data between city on, we have a day. So the problem is basically find loads given that some other loads are already in, you already have loads for certain territories. So if I break down the dataset, it looks something like this, right? Now I look at the pre-attentive attributes. We look at seven of them which we very commonly use, which is color, position, movement, sizes, shapes, orientation and pattern are not, so we, these are some of the typical ones. There are others like collinearity, which do not translate very quickly on a UI. So after that, we looked at what kind of detailing we need for each of these, right? And what is it that the business users want to see? Business users wanted to see what are the loads which are going to come up in a particular channel. What are the loads which are originating from a particular port at a particular date, right? And, you know, some sort of a visualization on how the, what the type of loads which are going to come in a particular date. So this was the first step we took. What are the very obvious encodings which are possible, right? Positions can be encoded, I mean the lat-long can be encoded as a position on a 2D scale. The shape is basically a line, a curved line from point one to point two. And then ports are encoded as circles, right? So we started off with this. So this is a very iterative step-by-step process. So I'm skipping a few steps here because we're not short on time, right? So when it was a smaller data set, it was fairly easy for them to visualize. There were like four or five lines from Bangalore. But once we started operations in other cities, this became slightly cumbersome for them also, right? And so then we decided to, so they wanted to see what is the aggregation rate, right? So we encoded that as a single hue and with multiple lighting based on a scale of zero to 100%, right? What they said was that does not work for us. You either give us yes or no decision. These are go-no-go decisions for us, right? So we encoded them into a two-color scale, whereas we felt the lightness comparatively going from lighter to darker shade would give them a better view. But this was something that business came back to us and told, right? So in this context, they were also losing the context of where certain nodes are going. Is that Kolkata or is that Bhuvaneswar, right? So they wanted us to encode this whole thing inside a map. So that's when we started with this. And then what we decided was that they couldn't, see, we're not a big fan of using movement inside visualizations, but in this case, it works because it directly shows the movement of goods from point A to point B, right? So, and to add to that, we gave them more drill-down features and we also gave them a voice interface so that they can talk to it, right? Tell me all loads between Mangalore and Pune and it'll just suddenly pop up with all the loads which can be coupled, right? So once we did this, right? Once we looked at the decisions that they were taking, we got some very simple heuristics that they came and talked to us about. If they see a green line, they click it. If they see a very thick orange line, they click it. So this forms an input for us to build optimization algorithms and figure out, you know, where all can we build these? How do we go about building these things? So this was built with D3 and Dialogflow and the code is available in a GitHub repository, you can go and check that. So once we did this, we figured out, we saw that the volume was significantly going up. The cost per shipment had come down, but we were able to cut price even more than that and still got a revenue uptake. So these are the two papers that I mentioned. One was by Colin Webb and the other by Stephen Fu. Thanks, I'm off for questions. Can you also talk about how the interface and the interactions was, like the voice interaction that you said, do you have it? Can we see it? Yeah, let me just check. Just give me a minute. Excuse me? I have a question. Yeah. Yeah, here. Yeah. So you were saying that it's a chicken-eating problem about the transportation and how much you are covering. So in the starting, do we have any criteria that in the starting, if my volume is, say, 10 in this area, my cost can go up to 50% or 100% but with time it will come to 50% or 20%. Do you have any numbers around it? My target is this much and my volume will increase this much. It will be decreased by X amount, right? Yeah, yeah. So that was one of the slides that I had shown, which is basically, yeah. See, in time, actually the cost does not go up drastically or come down drastically because these are long haul shipments that we're talking about. So beyond upon, there are not a lot of visualizations, there are not a lot of optimizations that you can do on long haul logistics costs because it is just not possible to send a 120 feet container in roads in India, right? You have to split it and do three 40 foot containers if you have that bigger load, right? So over a longer period of time, it becomes very constant. So there is a very, in this particular case, right? There is a big, so between a 40 feet and the 120 feet, there is not a lot of difference in marginal cost. The cost of sending 40 feet and one, I mean the extra 80 feet of load is more or less steady but the cost between an ACE, let's say 200 cubic feet size and the 1000 cubic feet size comes down drastically, that is this area here, right? So basically the incremental cost is basically the area under that curve. So the area under that curve beyond that point is more or less constant but in the beginning portion, it comes down drastically. So when you decide the pricing for these, how do you do that? Like, because in the starting, you don't know what's the volume, right? So you would obviously take the maximum, the minimum possibility of it but then how do you, what's your margin and all? Like, what's the upscale which you take? So what we typically do is, see we know that the arrival of loads is going to be in a poison distribution, right? So we kind of, but beyond that, where is that load going to come for is basically fairly random. So we run a few simulations and try and figure out how many loads we are likely to get but we know that the load size are going to be in the top six cities in India for us, right? So once we know that distribution, we try and forecast that piece, right? So I mean, on top of this, what we are building is that kind of a prediction model which says that, you know, between 31st and 2nd of December, I'm likely to get 4,000 feet of requirements from Bangalore to Delhi channel, right? Based on that, we place the truck requirements accordingly. Yes, drastically, because I mean, that is one part of it which we cannot predict, which is there are some external factors which affects the costing, which is petrol prices for one, right? Do we have time or? Completely, thanks. Thanks, Sarah. It was an insightful talk. It's completely out of time. I think now we'll have a tea break and then we'll reconvene for a couple of talks from Zoomcar and Flipkart. And there will be a Bob's session that is sandwiched between the two talks. So we are running about 10 minutes late. So since we're starting at around 10.50, we'll reconvene at around 11.20 back here.  So we're going to kick off this part of the session with two talks and this Bob's session in between. So starting off with Arpit Agarwal, who is head of data science at Zoomcar. And he's going to talk about revenue maximization from pedal trips, which is a cycles, using network analytics and geospatial mapping. So over to you, Arpit. And start off. Thank you, Naik. Hello, everyone. Hope everyone had a good break, right? So today we'll be talking about a very different kind of business. Till now you have been hearing about e-commerce, about food deliveries, right? About different share mobility. But today we will be talking about bike rental. So how many of you have seen these green bubbly bikes around you, right? Okay, so a lot of people already know about this. Great. So just to reiterate, we are pedal. And pedal is a bike share, it's a shared mobility where you can rent a bike, go from point A to point B, right? And pay per use. Now how it works. So let me just give you a brief background about it. So you can go to a station, you can see a bike. It's QR enabled. So you scan a QR code, link your Paytm wallet first, scan the QR code and that's all, right? So you can go from one place to another. When you want to end a trip, you just lock it and on your app push the end-trip button and it ends. So as simple as that. So the purpose of starting pedal was to make shorter commutes convenient. So we have cabs from going from one place to another that are far off. But imagine that you're going to a place where you end up in a metro and now you have to go to your home. Now how do you go to your home, right? Do you want to take a cab again? That'll cost you around 100 bucks or 50 bucks or you can take a cycle from there and go to your home. So that is the whole point of starting this business. Now, just to explain a little further, if you have seen these bikes, there are two main components to it. One is this basket. And trust me, this basket is a solar panel, right? What it does it, it gets charged by the sun and it powers this IoT lock. So this lock at the back is where all the magic happens, right? So there's a small box which have all the GPS tracking. It captures the battery status. It gives signals to lock or unlock a cycle, right? It tells you the strength of the signals and everything else. So these are the two features that are put on the bike because of this is whole ecosystem works, right? And this is also the way we capture data. So let me take you through how we expanded because it's a very new business. So I thought that it'll be good to share with all of you. So it started somewhere in January 2017 where we built our minimum viable product and we set it out in HSI layout. So we had only 15 stations at that point of time and it used to be there was no IoT behind it and it was completely manual. They were fleet at all these 15 stations and people used to find these good looking bikes and they would come and ask, what are these bikes for? And they will say, I want to go, you can take this bike and go to BDA complex. You can take this bike and go to 27 Main Road. And we had stations there and people will tell, okay, I want to go from this place to another. So we would communicate to the fleet at that station that, okay, this bike will be coming there and that is how it used to work, right? But what are the challenges in it? The challenge was, obviously all the data was manually collected. There was no IoT, there was no tracking, right? So those are the major challenges but what we learned from this was that people really used to like it. There was a void in the market that there was no way to go shorter commutes. It was either through walk or either through caps. And even the buses had very fixed stop and the routes were not convenient for residential areas. So we did this expansion for around six months and then in November 2017, we expanded to 1,000 cycles. Now this is when we actually introduced the lock. This is then when we actually introduced the solar panel and we started collecting all the data. Now what happened was the reason behind it was that we want to make it manless. There was no one present at the station. Now people used to discover themselves. They used to unlock themselves. They used to go from one place to another and they used to park it back themselves. Now initially we started in Bangalore, especially HSA layout, but then we expanded to Pune and Kolkata. The reason being these are smart cities. We had a lot of government support. They wanted to go eco-friendly, right? And they wanted such initiatives to come to the city. Then we expanded in Agra, Jaipur, Gurugram and all these cities. And but we had a little setback there because there were high cases of vandalism. Now the obvious question would come, you know, why would I not see the cycle, right? How do you protect all those things? So though we had a lot of things by which we mitigated theft, so inside a lock, we have a buzzer. So if you try to move a cycle when it is locked, it will buzz off, right? If you try to shake a lock, it'll buzz off. So and it'll send an alert to the fleet or the city operations team that someone is trying to fill with the cycle. So this is how we tried to protect vandalism. Then we thought that, okay, it's maybe it's a good idea to launch in close circuit areas like college campuses. So we launched in ID Bombay, ID Chennai and IISC. And then when we had success in that, in around April, 2018, now we have a fleet of 12,000 plus bicycles. We are in 15 cities across India, New York cities like Ranchi, Raipur, Varanasi and the maximum density we have in Bangalore, Kolkata and Pune. Okay. Now what is the problem here? So we had problems of vandalism. We have problem of the GPS location not coming in the correct way. We had problem that the battery is drying off. But what is the major problem? The major problem is when you expand to so many cities, right, how many cycles do you put at a station? How do you maximize your revenue? It's a very low ticket item, right? For if you are taking a ride for 15 minutes, you hardly pay like three rupees. So how do you sustain this business? So for sustaining this business, this is the problem that we are trying to solve and this is my main focus for this talk for today. How to increase the number of trips per cycle and hence maximizing utility and revenue. Now, why do you want to do that? So these are the challenges. Right now allocation of cycles at the station for heuristic base. So when you're launching in say HSI layout, so I know the places, I would know that, okay, these BDA complex, 20 cent main road, these are areas where you have a lot of crowd, where you have a lot of people shopping around. So I should put more cycles here. But when you go to newer areas, like for example, Kudluget, Victoria layout, right? How do you recite the number of cycles you put there? It's very difficult. It cannot be heuristic base and you would know good about a city. But what about you go to Kolkata and they want to expand there? How do you recite the places? Then the trips for cycle right now was very low before we launched the experiment. The third was rebalancing of the cycles was totally fleet based and it was done only once a week. So on Saturdays or I think Sunday morning, they used to go and they used to just rebalance all the cycles there. If we have hoarding of cycles at one place because everyone took from point A to point B, no one took from point B to point A. Now, how do you solve those problems? And last was identification of new sites. So I launched an SSR layout. I launched in Kormangala but I launched in Indira Nagar. But what next? How do you expand? So to solve all this problem, we thought that it's not as easy as taking out a report or generating some statistics. We have to really visualize it. So to do that, we followed this approach. So there are two legs to it. One is, how do I optimize the current network of stations? So if I have SSR layout and I have around 15 cycles in SSR layout, how do I make sure that I have the right number of cycles at each of these stations to maximize the number of trips from each station and overall network? For example, if I have, as I said, if a lot of cycles go from point A to point B and not coming back, then how many cycles should I put at point A at the start of the day? Because I know they will get depleted. So cycle rebalancing to optimize for number of trips per cycle. Second, identifying the dead zones. So you decided to start a station somewhere, put cycles there, but then you realize, oh, no one is taking cycles from there, right? So can I relocate those cycles to somewhere else? Third, identifying frequented routes. Now, for example, there's station A. Now I take this cycle to a station B, but in between, I stop at a hypermarket, right? Because I want to buy groceries. So can I open a station at the hypermarket? Because these areas are demand aggregators, right? They will build a network. So how do I find these things? Identifying areas where people abandon cycles, these are very important point. Reason being, you can only end a trip at a station. You cannot take a cycle and leave it anywhere, right? Your money will keep deducting. So for example, we don't have station every 200 meters. That is what we want to achieve in future. But right now, what do we do? So we find out which are the areas where people took cycle from and then abandon it here. So maybe if a lot of people are abandoning there, if you open a station there, that will help people. The fifth point, I'll just touch upon a little later in the presentation. The second leg to it is expanding into new areas. Now, for example, when Uber Eats started, right? So it started with Kormangala, but how did it identify? So if I was sitting in Whitefield and I wanted to avail that service, so they would tell you which area you're coming from and then we will shortly expand to that area. So these are called empty searches. This is a concept of empty searches. That you get a search, but you don't have a product there. So we used to capture that when we started this and identifying connecting neighborhoods. So for example, you have HSA layout, you have Kormangala, but these are pretty apart. They are at least five kilometers distance from each other, right? So can we open station that is in between these two? The demand does not originate from that, but people, you know, it's like a connecting station. So it helps bridge demand between these two big stations so that the overall network density increases. So what we'll do is I'll first take you through what our federal networks look like. So this is a short video. Okay. So what we have here is these yellow dots are the stations all around Baglow. So for example, this is JNagar. Then we have around residency road. We have around IISC. We have Indranagar, Kormangala and HSA layout. Now you see blue dots coming, right? Now what are these blue dots? So blue dots are the places where the people are starting trips from and the red dots are places where people are ending the trips. So now there are some obvious observations here. So you'll see a lot of people are starting and ending here, but these are kind of empty, right? JNagar, residency road, Kaban Park. IISC is pretty good, right? So there are some obvious insights that you get if you plot it well, right? What next? Let's go dig down a little deeper. So let's go to IISC, right? So this is IISC. Now you will see all these stations are doing well. A lot of trips are starting and ending at these stations, but these three stations, no one is either taking cycles, no one is either ending at these stations. So basically all the supply at these stations is kind of dead, right? So this frees up my supply from here. Similarly, let's go to the area near Kaban Park. Okay, you see here. So this is a whole set of stations. Stations on the right-hand side, these have a lot of trips starting and ending, but station on the left-hand side, they're almost dead. Now there's so much of inventory lying idle. There are so many areas where I have a good network and areas where I have a bad network. So if I were to show you how the trips are panning out, so it'll just come in a second. So this is how the trips are happening, right? See here. All the people from this area, from residency road are not really going within. They're transversing to either Indranagar or Kormangala. ISC is a very close circuit, right? And there's a huge network density in these areas. So this is the power of visualization. Now how do you utilize this? Now we know this helped us in defining the problem that we really need to solve it now. Now, how do you do it? So next is what the major talk is, decoding a network. How do you decode it? So our objective is to identify the right number of cycles that we should deploy at the start of the day at each station so that the number of trips per cycle gets maximized and does the revenue. So to understand this, there'll be two concepts that I'll be introducing. First is the rate of outgoing trips from a station. Second is a transitional probability of going from station A to station B. Now what is the rate of going, rate of this from a station? It means that it is the expected number of trips per day from a station given X number of cycles at the start of the day. So if I have, say 10 cycles at the start of the day, how many outgoing trips can I expect? If I increase the cycles to 15, can I expect more trips, right? So what we did is we had data, so because we had launched it for around more than one year, for every station, we had data when they were different availability of cycles at the start of the day. So we figured out when the availability differed over time, what was the increase or decrease in the odd trips per day. Now, initially we thought that we'll build a linear algorithm to it and if you keep increasing the supply, the demand will keep increasing because understand this is an impulsive business. You see a cycle and you write it. It's not that you know and then you come, right? But what happened was it's like a projectile, right? It has diminishing utility over time. It demand is capped after a certain point of time. So that is why what we did is we fitted in a polynomial equation. So this becomes our rate of trips. So what it tells us is that if I deploy C cycles at the start of the day, at what rate my trips outgoing trips will increase. So we defined this function using past data for each and every station we had across Bangalore. And this is the objective function of number of trips. So the trips at the start of the day into the rate of trips expected at the station. So if you do it for every station and sum it up, it'll give you the total number of trips for the whole network. And this is what you want to maximize. Let's go to the next thing. So this is building a network chain. So say there's a station A and this station B at the start of the day, they are 10 cycles. And the rate of trips of the station is 0.5. It means that if you have 10 cycles, probably you will have five trips from that station. Now those five trips can either be a round trip. I can start from the station and that station or it can be a trip to a station B or it can be a trip to a station C. So the probability of round trip is 60% for the station A to B is 20% and A to C is 20%. So we calculated something called as cycles we are expecting at the end of the day. And I'll tell you why it is important because it helps us defining constraints. So cycle at the end of the day, cycle at the start of the day plus incoming minus outgoing, simple. What is incoming? Incoming is the cycles I expect to come from different station to station A. So incoming at station A is cycles at the start of station B into the rate of outgoing trips I'm expecting at station B into the transition probability from B to A that is 20%, similarly from station C. So this will be the total incoming cycles I'll expect at station A at the end of the day. For outgoing, again cycles at the start 10 into rate of trips into one minus probability of a round trip because if I take a round trip, it'll end up here. It'd not be outgoing. So cycles at the end of the day is like this equation and it's 14. So see you started at 10, you ended up at 14, right? And this is the most important thing to analyze the network. How much should I keep at the start of the day? So now to optimize, we define three constraints. Constraints are important, obviously. So the constraints are cycles at the start of the day at any station should be greater than equal to zero, right, logical. Why greater than equal to zero? Because we want the algorithm to tell us, right, that you don't keep any cycles at all also at a station. That is why we said greater than equal to zero. We want to remove those death stations. Second is the cycles at the end of the day at any station should be greater than equal to zero. It cannot be negative, right? It has to be positive. And the sum of cycles at all stations is equal to the total cycles. So this is a macro constraint. So this is what it looked like before. This is HSL layout. This is how the trips look like. And after we run the optimizer, this is how it looked like. You can clearly see the density of trips have increased. Now, how much they have increased? Let's see. So we had around 150 total cycles. The uplift in trips per cycle was 20%. The uplift in revenue was 15%. Why the revenue uplift is less than the overall uplift in trips per cycle? Because there's a rebalancing cost also. So you have to pay the fleet to move a cycle from one place to another. But even after factoring in the rebalancing cost, the uplift in revenue was significantly higher. So that is the use of doing such kind of things. Now, this solves for the first case that how do you optimize within a network? But how do you identify new network? That is the second problem. Again, three legs to it. Identifying the frequented routes as I talked about the hypermarket. Identifying areas with no station and high abandonment and identifying areas with high empty searches. This is a route map. So what we did is we collected all the GPS traces when you're going on a cycle and we plotted it as a heat map. So this is HSA layout. You can see these places marked in red that this is HSA flyover. Where a lot of people are going and stopping but there's no station. Just Sandra, no station. Silverboard, no station. So these give us probable areas where we can open new station because they already demand aggregators. We call it at the founding graph. So this is Jacsandra. A lot of strips are starting from nearby areas in HSR and Kaur Mangala, ending up at Jacsandra but there's no station. So these people are manning here. So this makes a use case for creating a station here. And then we plotted the empty searches. You will see in Marthali Bridge, Outer Ring Road, Cabin Park metro station where we don't have any network at all. People are searching but they do not find the product. So by this, we expand to newer areas. So these are three use cases where you, how you can expand. These are tools and techniques you can use. We use Kepler and Deck.gl. We use Folium Mapbox. Techniques are heat mapping, network analysis and operational research, right? Then other initiatives that we took after we did this is that we launched subscription. So I don't think you have heard about it or not but we lost subscription at 49 and 199 where you can take unlimited trips in a month, right? And why we did this is so that we increase the frequency of trips from a particular user. So how we utilize it in mapping is the areas from where we get more subscribers, we make sure we have more number of cycles in those areas. So we put a layer on top of a maps and we also plan to reduce our rebalancing costs. We also plan to incentivize users. We'll give them the credits to take a cycle from one area to another, right? So that ways we don't take the burden and the user also benefits and makes money out of it. So implementation was not a cakewalk, right? It was really difficult. It took us several months. We started this initiative somewhere around six months back where we went and talked to the operations team and they said, you know, we don't wanna do it. We don't see value into it. And then we attended various conferences, we talked to various people and got to know about these tools and techniques. So these are learnings. Start with small experiments. We started with HSL layout, we proved it to them and then pushed it to them that, you know, why aren't you using it when you are seeing the value? Keep measuring it and keep flashing the results, right? Send them a report every day that if you do this, this is the result. If you do this, this is the result. There's no way they can deny that. Build map to highlight actions and not just describe data. So tell them that these are the number of cycles, you know, required at the station at the start of the day and don't just tell them how the trips are moving around and don't underestimate the power of making it look good. So you might see that it looks a little fancy, but that is one of the reasons people are using it, right? Initially we used Folium, but then we switched to Kepler.gn and it really looks fancy to us too. So we also like working on it. So how can you guys benefit from this? So I've listed down some of the use cases that you can use, identifying areas to expand your operations using app search data in terms of food deliveries, groceries, medicines, e-commerce, area where they don't have right now. Second is recruitment or allocation of free persons by areas to optimize delivery time. So if you already know you have delivery orders from these areas, how many persons should be present at the start of the day? Second is decentralizing warehouses and distribution centers across the city to minimize the time of delivery. If you know that you are getting a lot of orders from this area, why don't not have a warehouse or distribution center near it? And tracking of fraud during delivery. I think Aditya talked about FE scores, right? Fleet executive scores where they're making fake attempts. So we can know that what is the distance of the GPS location the fleet executive went to and what was the geocode of the actual house and was it close enough? If it is not close enough, it's a fake attempt. So all these other things that we can use it. So that summarizes my talk and we are open to Q and A. Yeah, but okay, very interesting talk. That curve that you showed, right? The rate of outgoing as a function of the number of cycles. Yeah. Now to the extent that it fits well, even if assuming it fits well, it's dependent on the properties of the other nodes. It's not something that's just independent of that station, right? The thing is that, so you're sort of doing something local, which is applicable only if you hold other things fixed. Yes. But then you're doing everything local there as well, in each of the nodes. So there's no reason to assume that the same coefficients to the extent that, as I said, they fit well. They don't fit particularly well, but let's ignore that. Yeah. That no longer is going to stay the same. Yes, absolutely true. Yeah. So I'll tell you what we do is that that equation keep changes every day. So what we do is we base that equation basis on the last month of date, last month data, and we filter out to make that equation that, you know, we have, for example, holidays, we would filter out, we would filter out when we had very less cycle availability and all cycles were damaged. So we would know that in the recent time, the equation is as true as possible. And in future, when we'll have more data, we'll actually build a prediction algorithm to predict the number of trips for the cycle availability for each station. So right now, we start with very less data in HSI layout, and that is why we, when we plotted the data, it looked like a polynomial equation. That is why we fitted a polynomial equation to it. We'll start with. I think we'll start off with the buff, but meanwhile, while getting the chairs on the dice, I think maybe we can take a couple more questions. Yeah, sure. Hi. Sure. Why do you take a start of the day and the end of the day are the only two relevant milestones? Okay, it's operation challenges. So why is the start of the day? I could do it at every time of the day that in the evening, you should have these many cycles, they're starting here, these many cycles, but we have limited resources. We live in a practical world. So when we talked to the business team, they said, right now I'm doing rebalancing once a week. So for us to convince them to do once a day was a big job. No, no, no, it's not about rebalancing. Say, what if in the middle of the day, the number of cycles at a station goes to zero, you'll not be able to collect data on what would have happened if the cycles were there. Yeah, so if it goes to zero, we cannot do much. See, but what we are trying to do is we try to build a optimizer in such a way that it should not go to zero. So we over index the cycles that we keep at the start of the day, right? And we try to, for example, one of the constraint you said, we said that the cycles at the end of there should be greater than equal to zero, right? So what we can do is we can do greater than equal to five so that it predicts to keep more cycles so that there's a minimum viability at any point of time. So these are things that we can tweak. We started with this, we can always improve. I think that was the last question. Can I call the participants in the one stage? Sankur Goyal from Swiggy, Jeram Kasi from Pickle, and then we have Aditya Madan who spoke before from Flipkart. So the next speaker, so the next speaker we have is Senthil Lem, who is director of products at Flipkart. And he's going to talk about supply chain and supply chain and using network intelligence and orchestration techniques as well.  Can I remove this one? Can you hear me? Hello, welcome. So this talk is more about the, so far we have heard about conversations on localized problem solving around hyperlocal problem statements or in the lost mail delivery problems or even the vehicle routing problems in the lost mail. So this talk is more about the background before entering into the lost mail and it will be heavily on the context of the e-commerce or a marketplace kind of scenario. So my name is Senthil, a quick introduction would be. My name is Senthil, I'm a product manager in Flipkart. I have worked in several supply chain problems all the way from the very start of Flipkart having its own supply chain till now. A quick update on the flow of the conversation will be like first is about talking about the landscape that we operate, what are the dynamics of the landscape? What are the dynamics of the landscape that is coming outside as a demand and what is the dynamics of the landscape that we operate within the business? Second is about what is the key problem statements in this domain? So there is a bunch of problem statements that we look at it and how the network intelligence has a subject or a concept is well positioned in this overall scheme of things. And finally, if time permits, we'll also talk about an illustration, our particular use case or particular problem statement and see how we have evolved in that direction. That's a overall journey for this conversation. First, we'll start with an operating landscape. Step one is from a Flipkart or E-commerce marketplace scenario, the categories that we operate is humongous. So these are some of the typical examples that I can quote here is like books, which is very different from the way it operate for which we operate, it's very different from the way we operate books to furniture or it could be larger plants or it could be grocery and so on and entering into jewelry and new subjects like that. So the product categories comes with different dynamics altogether. The dynamics in terms of working capital management, the margin that it operates, the consumer demand it generates and the kind of consumer expectation that it generates is very, very different. Not only that, this product also has very different types of attributes. For example, if I want to deliver furniture to a house, it's not one product that need to be delivered, it could be multiple parts that need to be delivered or it could be some of the damaged parts that need to be delivered with this, which could be a replacement of a part rather than the whole product. Or it could be, some of the products could be fragile, for example, it's a wall clock. It need to be handled with care. Also the stacking norms of the product differs across the categories, right? And so on and so forth. The managing of products could be in lots or it could be in heaters or it could be high value and inflammation or it could be a hazardous product and so on and so forth. The third dynamic that we talk about is customer segments. The customer segment that we operate is pan India, with a variety of customer categories they come from. For example, we just launched a plus program, which is our loyalty program. So there's a difference between the plus and non-plus customers. There's a tier one, tier two, tier three customers. There's metro customers. There's million years that we operate. There's a women population that we operate with different age groups and so on and so forth. The important subject here is that these customers have different needs when they look at the e-commerce platform. And when you intermingle that with the products and its kind of dynamics the product brings in, the e-commerce platform is pushed to deliver a lot of new services. It's not just vanilla delivery that we do place and order, get it delivered. It opens up a variety of new supply chain services that is required. It could be schedule delivery, next day delivery or it could be faster speed like same day delivery, slaughter delivery. We talked about some of the in the morning conference, we talked about schedule delivery in the last mail areas. It's also could be installation. We do furniture and other stuff like it's records installation, reverse pickups, open box delivery, so on and so forth. It could be a very different thing if we enter into the house and deliver things, right? Compared to something else. So the variety of supply chain services not only that, it also can since some of the deliveries could be much, much longer in lead time, like it could be three days or five days and so forth. The customer needs also change between that order journey from the time of order placement to all the way to deliver. He can change the address or it could be changing the delivery location, date, place and so on and so forth. So the variety of supply chain services get intermingled. And finally, to operate all these things, the fulfillment models that we work in a e-commerce marketplaces, very different. It is not always an inventory and we deliver to the location. It is also about sellers managing their own inventory and partnering with the sellers to deliver the products. It could be brands who is managing the inventory for a variety of marketplaces, not only for Flipkart. How do you interplay with them? Are ready to make orders. For example, if we are launching jewelry, it could be ready to make orders that we want to deliver to the customer and so on and so forth. Homely channel, hyper-local. So Flipkart is in grocery these days. So we are in hyper-local. We are looking at hyper-local and homely channel business in a very close fashion. So there are multiple fulfillment models that can be operated for this kind of customer demand. The all this thing comes with the one important part of demand volatility. What a demand volatility here is that the demand variation that we see in a marketplace scenario or in a e-commerce scenario is very high, very, very high in terms of, so it is also induced as well as I received. The induced part is that we run a lot of sale events. We recently finished our big billion days and when we, so that the scale that we operate on a big billion is maybe five X or six X of the range that we operate on a BA scenario. So it comes with a very different demand volatility into the picture. The second, given this operating landscape, right? When we look at supply chain, how does the supply chain look like? We operate hundreds of warehouses with millions of products in the warehouses. We have hundreds and thousands of sellers who is part of the entire e-commerce story for us. These partners not only spread across the country and the customers also across the country. So we, the supply chain here is not catering to a very specific location. It is from all the way from warehouse to seller to any number of pin codes in the country, right? So it is from all the possibility, all the 20 K pin codes, the source could be all the 20 K pin codes and the customer or the destination could be all the 20 K pin codes. That's the kind of supply chain network that we are talking about here. So all these things are delivered through people, vehicles and those are the currencies of operations. So if I look at the people part, we manage a large fleet force, co-owned, yeah, partnered and so on and so forth, right? So the number of fleet force that we manage is also human. Among us with different skillset. It's not a specific, it's not only a delivery skillset. We look at installation. If you look at people etiquette, there's a gross delivery where we are doing delivery inside the warehouse, inside the house of the customer with the very different things. While a book delivery requires a very different etiquette in front of the customer, right? So the skillset of this field force varies a lot. And second, the next part is about the partners and vendors. The entire supply chain, when you connect all this 20 K pin codes to all the other 20 K pin codes in the country, it's not only a job that Flipkart can march forward. We also need the partners and vendors who can play a very key role in taking us forward in the journey, right? So Aditya also mentioned about the millions of packets that we deal in a network, right? So if you look at our network at any point in time, there's more than a million of parcels that's moving around. And from all these sources and all these distinctions, the routing of this parcel become much more important. We operate across multiple operating methods. So today Jairam was talking about the truck testing. So we operate on more than thousands in the scale of thousands of trucks that we manage, bikes, our own large line-all vehicles. We also partner with all the cargo movers through flight and train and all those vehicle modes, all the transportation modes is also part of the story. Finally, it's not only about the physics that we move around, there's also a lot of cash that moves around this entire network. It's in tens of rows of cash is getting dealt every day. It's also closer to a bank supply chain, right? So that's the amount of cash because of the COD or the cash on delivery nature of the business, that's the amount of cash that we deliver. So another interesting part is that this also comes with supply value volatility, right? So for example, a vehicle can get broke down or it could be an external climatic condition that is changing or it could be the absenteeism that we are seeing in a particular location or it could be festivals and holidays and so on and so forth. So it all brings up the overall supply volatility picture to it along with the demand volatility picture that we saw in the previous slide. What does all indicate to us? It indicates, so here, this is the point I want to take a step back and look at what is network. Network can be defined in various contests. In a supply chain, a network means it is the operator. So all the element that we saw in the previous slide, right? The sellers, warehouses, vehicles, people, partners, vendors, and all the stuff that is included along with our own facilities, the delivery hubs, people called dispatch centers and so on and so forth. So all these things form the part of the network. Now in the, as Flipkart grew up, Flipkart also had a very fast scaling of things. So it is like, when do you employ intelligence? Vis-a-vis, how do you fast scale? So that's a trade-off conversation we usually have. So in the initial days when we had this growth, what we did is that we operated mostly from the inventory model. So if the incoming demand in a variation form, when it comes to us, every order is pushed into a warehouse. So remember, we talked about millions of packet and this is very close to how our warehouse looks like. From warehouse, it has to get sorted all the way to the 20K pin codes that we talked about. So it's a sortation in itself, it's a very huge problem. So sortation, let me give you one snapshot about sortation. It's not about connecting one product to 20,000 pin codes. Every product has different nature. So we talked about furniture, we talked about grocery. Every product has, it requires a different level of sortation. Above that we also apply new services to customer, right? We talked about next day delivery. We talked about same day delivery installation, all those things when they couple together, the sortation in itself is a huge subject that opens up a lot of complexity to us. So if we push orders to a warehouse and we start processing the orders, the orders get piled up, right? Waiting for a transport connection to arrive at some point in time. And when you see the piling orders and when you design a transport connection, even a piling orders, your transport network looks much more complex. And if you're doing it in an instantaneous manner, it will always lead to a load. It's all in the industry term as LTL. We use load truck load, which reduces our efficiency and cost utilization, significantly down. While we are managing this, we also have implications because of not employing intelligence into this way of working, which is customers screaming at us and cost increasing exponentially. So there was a few snapshots about how customer concerns comes with, right? Most of the customer's problem is where is my order, right? And when you look at this piling network and we say where it is stuck, and if I'm not able to give him a right answer, he's going to scream at me back every now and then, right? The second problem is that most of the time it's also coupled with all the last-minute problems that Aditya talked about, fake attempt and so on and so forth. So managing the entire network is in itself a complex update, right? So then that's the first point I want to do. And second step is that when we step back and look at this entire network, which we talked about connecting all the hundreds of thousands of sellers and along with our warehouse to all the way to the customer. So it's not a push-based model where you get an order, you operate your push into warehouse and process this works. We need to step back and look at what are our push-ins or what are the problem statements that we need to rethink to develop an intelligent module about this. So that's Albert Einstein talking about how important it is to stay with the problem. It's more about thinking about the problem and getting in the right frame of the problem statement much more important than actually getting into the solving. Solving it could be much more simpler when you think about the problem statement of this kind that we talked about. So let me talk about some of the directional problems that we as an organization started thinking about. Step one, for every order, what is a full-fledged model that will be rightly operated? Should I engage a marketplace model here or should I engage into an inventory model? How does this frame of what full-fledged model need to be operated for an order comes out? The second is how should the inventory be reserved in a network?  So where should I position my inventory or where should I reserve my inventory for a given order? If I am understanding the inventory reservation part, when should I release the inventory? Should I release immediately like the thing that we saw previously where we saw the inventory get reserved in a warehouse and it can immediately choke into a sortation or it can lead to a very inefficient transportation mechanism. So should the orders be processed in a real-time basis or should we batch it, wait for some information and start processing it? What should be the shipment flow path? So we have a variety of node, for example, if I want to connect from Bangalore to all the way to Guwahati, what should be the path that they should... Should I stop in Kolkata and go all the way to Guwahati or should I employ a transport from all the way from Bangalore to Guwahati or should we fly to Guwahati? There are a lot of options that we have, right? So assessing this shipment flow path is much more important for me. And then across, we talked about the exception that can happen, which is the variability. For example, a customer can say that I am, I don't want this order anymore. Or you can say that I want the order to be delivered to some other day or it could be a climatic condition playing a role in its part where we need to be answerable to customer in a more deterministic manner, right? So how do we take this exception? How do we build insights about this exception and answer the customer query in a more predictable manner? And other things would be is that when should it start a transport connection vendor? Should it start a tug immediately from a Bangalore or from a Bangalore virus to, let's say, on its expedition to Hyderabad? Should it start it now or should it start it later? What should be the transport connection? It opens up a plethora of problem statement along with and other could be is that what kind of flexibilities can I offer to the customer at given point in time or given point in time of the order journey? So we say just adding to that that could be other problems like which is beyond my conversation here. It'll be about forecast, demand planning, supply planning, inventory positioning, inventory planning and so on and so forth, which is not part of this conversation though. So how our journey started? The journey started with building workflows because we are a scaling organization at one point where our orders are increasing at 10x, 3x, 2x and so on and so forth. So one end we are building workflows. We are building our network. We are scaling our network in a very fast manner. So building workflows becomes a critical part, but while we are building workflows, the previous problem statement that we talked about orders getting piled up in a big network and you're getting stuck everywhere and your customers are getting a little bit angry about stuff of product not reaching their warehouse every time, right? So it's about extracting right data. So we've been, so looking at this problem statement, we started from workflows. We want to instrument a lot of information. Instrumentation, some of the instrumentation, we talked about the lost mail, where how a fee is traversing, what is the geo data that we are getting? Apart from that, how are we managing our vendor relationship? What are our vendors performing? How is our sellers performing? What is their operating hours? How do they model their information access? So we get into a, we were in a journey of modeling and a plethora of data across the notes or the factors that we talked about in the supply network. Then building awareness. It's an integrated awareness that become much more internet. Important to us. The integrated awareness is that from all the way from lost mail doing, in a lost mail, if you're allocating an FE, how it replicates and come back to when should an order be released in a warehouse. So that awareness has to be integrated across the network. And that was one of the key pointed. And then employ some control levers in the network, right? Well, if I am able to be awareness, I need to be employ some control levers in the network. And if we need to deliver a product on a particular day, if 30 days, 30 products is its capacity, that is some amount of levers and tools need to be provided to him for him to employ it. Otherwise, whatever that I do as an intelligent part will become shallow. Then the next part is about the building the intelligence itself, right? So we'll talk about more on the intelligence, but the overall goal of this team is first is to become more an orderly and predictable execution. That's a goal that we want to achieve while we solve all these problems. So that we will be able to provide right answers to customer whenever we, whenever customer walk in to walk to us. So now let me think about the logical view of it, right? So how does, how did we go about building such amount of network intelligence? Step one is that we were in stop building workflows. We stepped up and looked at building systems and processes in the, in the, in the, and model systems and process in the, in the language of lead time and throughput. Every processes in the supply chain is modeled as a service entity, as a service entity and above that lead time and throughput of that is constantly defined. And every time there isn't, there is a separate team that works on refining this lead time, making it much more efficient and feeding back to the lead time and increasing capacity part of it. Once we have this active activities and process and lead time in our pocket, the second step is to build this into a customer view. Customer view is the next day delivery. Varo's doing an operation of picking and packing a product. How does it reflect as in terms of next day delivery or same day delivery to a customer? Then about that business and customer intelligence need to be coupled. So what services should be offered to what customers? What business is much more pruned to what services? So it opens up that area for us. And having all these things lead to us in providing right service offerings and pricing to customer. So pricing is a very vast subject. We'll maybe may discuss in subsequent sessions if possible. Here the idea is that having services, understanding customer need, understanding business need will enable us to offer right services with the element of pricing into it. So that leads to customer choices. Now, when you look into the other thing that we talked about is about the events and disruption that can happen across the network. So we need to build a real-time engine which can publish all the events and disruption that can happen across the network. One could be predictable, one could be unpredictable or it could be scheduled like a band or so on and so forth. So all this information comes through us. We started building a logistic inside module which looks at all these disruptions possible in the world and funnel that information to any decision-making layer. So this is one important concept. It's about demand prediction, right? In the context of Flipkart or in the context of Flipkart when we take a decision for a given order, right? It is an opportunity cost for the upcoming orders. So it is not only taking a decision for that particular order. It has to be treated holistically. I can give you an example for example. Let's say we have one product in an inventory and there are two customers walking in at time T1 and T2 and first customer could be a new customer and second customer could be a very loyal customer to us because it's very high on the plus. How do we, if I am taking a decision at T1 for the incoming customer, I would have reserved that order to the customer but may not be the right thing to do. So keeping a demand prediction becomes much more important to us and that's one area where we are investing heavily. All these things lead to generating some real-time fulfillment decisions. In the subsequent slide we talk about or maybe we take a talk one subject and see how the real-time fulfillment decision has been designed. Then once you have a real-time fulfillment decision we also have to operate those levers that we generated in the network by creating an orchestration across the network. So what are orchestration elements that you have? You have arrows, you have people working on the floor or you have your lost mail hubs, your transportation nodes, your partners and all these people are players in the network. And once you take a decision or a plan when it's to create a plan for an order then you need to orchestrate with these players in the node so that this can be, the goal can be achieved. And that's an example of the execution system. The execution system here could be a VAROS management system or it could be a lost mail management system or it could be a transportation management system or it could be all the way to the inventory planning all the way. So this is the area what we call as network intelligence altogether. And the execution system, so as we progress in our journey, in the initial days we were heavy on the execution system, modeling those execution systems and as we scale now and we look at with the power of more data in our hands we, our investment goes heavy on the network intelligence part.  So there are a lot of building blocks in the entire plethora of FSG technology, which is supply chain technology in Flipkart. You will see a lot of other systems like VAROS and all those things. And also you will also see location platform, location intelligence, network intelligence. We talked about logistics inside. We talked about how to get real-time events and funnel that between that we have scheduled and unscheduled. We have people management, like we have a bunch of people who need to be skilled at various levels. So the skill management itself is a very big subject altogether. So all this information get funneled by various modules and come to a box called real-time fulfillment decision maker. And that's why I called this fulfillment decision cockpit. From there the decision and the plan for an order is created and it comes down through a network orchestrator to all the way across to the execution systems. So there's a high level system, quick view of it. So now let me design what is network intelligence and orchestration means. Given that we have this subject in the background. In a simple sense we have the constraint of our planning system. So what are the constraints? We talked about systems process lead time throughput. Those are the constraints that we hear and being able to plan on knowing this constraint itself is a big subject altogether. The second thing is that the decisions are need to be taken in the subject of visibility of the entire network of all the nodes, how they are moving, what are the things that's happening around the network and also a notion of understanding what capacity they can do. If an FE walks into our hub, how many shipments can he handle? If he's a new FE, he could have handled very less number of shipments or if it's a old FE, he can have much more shipments based on location, et cetera. That's a capacity notion. All this information is much more, it is much needed in order to take a real-time fulfillment. It also goes from iterative planning. There are multiple events and distribution and disruption that's happening either from the customer side or from the supply side. So all these events has to be funneled back to in order to take a right decision. So this defines what is network intelligence in English. Now if you flow the orders again, let's say we have this concept of network intelligence and if you want to flow this orders again, how does it usually look like, right? So when the incoming demand, like the same kind of variation, it can come with a high level of variation. But what we do is that we don't push orders to the arrows. We hold orders. We hold orders and take a decision whether it need to be filled at the real-time manner or it should be fulfilled in a batch manner. This is done along with the batch order is not only with the orders that is accumulated over till time, it also includes all the future orders that can be predicted based on our all changes that we are doing in the network. The second thing is about once we are able to understand the batch, the example of a batch could be is that I pick orders from arrows only for the next transport connection, right? Or I could pick orders from the arrows only for the particular zonal areas where the products are located very close by so that the picker's efficiency increases. So these are the multitude of signals that goes in before deciding a batch. And once a batch is decided, that goes for a planned picking. So the arrows executive knows exactly what he need to pick at what location, right? And when he picks, it forms a story for the entire order path. And the sortation become much more simpler because I'm able to pick the orders in a very sequence manner. It is for a particular sortation plan. If I look at the overall decision that I made, the decision is made for a overall order. The order scenario considers all the factors. So whenever I pick a product, it is going to need for a certain sortation plan that is going to get, the sortation plan gets much more simplified in this thing. And also I can, since I'm taking a holistic decision, the routing becomes much more informed and much more educated and I can always achieve a full truck load whenever I need it, right? The implication is always better customer experience and significant reduction of cost. So that is the story that we are marching towards. And in the next few slides, what we will do is that we will see how a barrows of an order get selected or a batch get formed.  And we will not have time to cover everything. So I want to talk more about how we do inventory reservation and release in the barrows. So the question is which barrows to select given an order, right? So the first step that we do is that we don't take that point in time decision anymore. We hold order, we also have the orders that is accumulated till time. We also look at what are the future orders comes in. Then we prioritize among these orders. The prioritization comes from all the available barrows and inventory, all the available barrows and the inventory available in this barrows across the seller included. So look at the list of this thing, identify flow pod choices. So given a batch, given this order segments, what are the multiple choices that is possible? So it is only an, it's a divergent problem thinking here. So taking an order, we look at all the choices of barrows, from the choice of barrows, we look at all the choices of flow pod. So it is getting diverged. And then we look at, so every part has a cost as a SLA trade-off. Either I can minimize the cost or I can minimize the time to reach the trade-off across every orders that can be taken. And this orders has to be treated very specifically because one order, so for example, if you have ordered iPhone X in Flipkart, you will demand fast delivery as a customer. Or if you have ordered a T-shirt which could be, which could come in three, four days, you don't wait for a T-shirt to come into your doorstep immediately. So there is an order wise and customer wise, all the parameters that we talked about, the category wise, particular order wise, particular customer wise, gathering this context enables us to set the right priority for an order to take in cost versus SLA trade-off. Then there is a risk in the supply chain, right? So we may have new partners who are new to the system or it could be an evolved partner, they give better SLA, but 50% of times. Or it could be a well-established broader partner and they may give a longer lead time, but with the high reliability. So assessing the risk along with that and finally, before doing an inventory allocation, we also think about what inventory, whether to allocate the inventory right away or not. So one is that the case that we talked about, if my match is prepared for a future, maybe tomorrow, I don't have to allocate right away because I can still get more information and decide the later point in time what need to be allocated. Or it could be the other way around, it's a plus customer and I do not want to derail this experience. I will allocate the inventory right away for that customer. Or it could be pre-orders. Pre-orders is a concept in e-commerce where a book like Harry Potter book getting launched in future. Customers have placed order right away. So I allocate orders right away for them because there's no deviation in his mind in terms of whether we'll get it or not. Now, if this concept lead to VARO selection, how to batch an orders, right? But as usual, we determine the flow path for an order. Now the important thing is that once you determine the flow path, now there are various, there are areas where we have levers to place our transport connection on a network. So how do you balance your transfer? Should we, should from Bangalore, should I operate all the south zone, south destinations in the morning or should I operate in the evening? How do I balance this network? Once I do the balancing of the network from Bangalore, I'm connected to all the way across the country. So if I'm balancing the network, how will I group this network so that the sortations plan can be devised properly? If I'm able to do the sortation plan, now I do a backward propagation across the hall. So starting from the last mail, we think about when the customer, when the product has to reach the customer, then work backwards and figure out what is the latest time I need to release this order inventory into the warehouse. Once I determined that, I also do a forward propagation because releasing at the latest point means there is no queues in the network or no piling up in the network, but it can, any disruption can affect this order much more. And also, if there is no enough demand for a particular day, I am making people, I say tidal, right? So which means that utilization can go down. So one is the backward propagation, then also we do a forward propagation. Forward propagation, the goal of forward propagation is to figure out what is the earliest time I need to release an order into the warehouse, which includes where the goal here is to see how I can maximize the utilization of the current resources that I have, right? And also the minimized risk. So this is the pointers of pointing question to us about how to select a warehouse or how to batch an order in a warehouse. All these things lead to us building custom algorithms. So we have defined a lot of algorithms in every subject. In the next slide, we may talk about one area, what are the parameters going inside it, right? So this has led to us build a lot of custom algorithms in the network intelligence layer. Now, if I think about only modeling warehouse selection as one of the problem statement, what are, how did we go about solving that problem? Maybe talk about what are the parameters lead to selecting a warehouse. Now, if I think about, how will I model this in a real time scenario? First is that everything has a business value. So what are the operating levers here? Either it is speed in terms of delivery SLA or it could be cost in the actual opportunity cost that we are looking at. And it is also the risk involved in managing any of the product across our network. So all this thing has to be modeled to a common business value, right? An organization may take a step up, increasing the speed so that it increases and increases GMB or reduce costs so that I increase my CEM, right? All this parameter. So the business value is a point in time or a point in time strategic decision where the prioritization of any of these things happen and come to a common unit of business value. The objective function is to maximize the value of a batch of orders. If we're creating a batch of orders, it has a maximum value. The parameters that we consider is that for example, if an order is given an order, what is the cost curve of an order? If it flow through multiple paths, if I decide a path, what is the cost of serving the path? If I don't decide then if I take an order and if I ask the order to wait for some more time, what is the cost of losing that order or the future value of the order? So that is a cost curve of an order that we determine. And then cost of serving an order determined from the common one is that I can delay the order as much as possible so that I can increase, I can reduce the cost of serving this order. But there's a probability that the order can get canceled or it can derail some customer experience. The other end of this spectrum is that I can go only looking at order and look at the minimum cost of serving the order. Now there's a commonality between these two points and that determines our minimum cost of serving an order. The opportunity cost versus actually serving that order, that commonality comes as a cost of an order or flow path. Once we identify this cost of the flow path, we start modeling the risks associated with this. Then the second two steps are much more simpler, identification of path, which is just an orchestration of path and identification of arrows, which is again following the simple plan. So this is how we took, so just to summarize some of the conversations that we had, right? We talked about the landscape of e-commerce, we talked about different products that get operated. We also talked about the supply nuances, what is supply chain network means. We also talked about what are the, what is the problem with scale when we don't have an intelligent network orchestration. So we also defined what is the network intelligence and how did we, how a overall network intelligence has a concept sits into overall scheme of things in the technology stack. Then we also looked at a lot of problems that need to be addressed before serving an order. We zoomed into one particular problem statement, which is arrow selection as such. And then we talked about what are the parameters that gets into before selecting an arrows, right? So that's it from my side folks. So my question is slightly tangential, but I feel like you're the right person to ask. Is that in terms of the whole supply chain that you described, there's also the key element of people management that you touched upon at some point. Now, my concern or the question is that there's regulatory compliance in terms of labor laws and there's also a human resource need in terms of making sure that all of the people working for you are in a good state to work. So at a very basic simplistic level, if you could tell me how many hours are FE is required to work and how do you cap it? Like what drives the decision and what other kinds of people or human centered constraints are put into consideration? So let me start with the first problem statement that you mentioned about the human constraint that we face. So our arrows are kept at very different locations. It's not part of the center of the city. So it's all outside the city just because of the space cost that is involved in it. So everywhere for everywhere also that is operating outside. There is a working timing that need to be defined as per the compliance law. It cannot be 24 bar seven. If it is 24 bar seven, there is a rate the salary increase has to be significantly higher for the remaining part of the day. And also there should be transportation solutions should be there for this employees to go up and down. And second thing is about the safety nature includes employing medication facilities, medical facilities near the large varos that we operate. So that and also other laws applies in a virus scenario for example, that could be recreational facilities for a longer continuous work time. We not a law, but it is our way of encouraging to reduce the fatigue of this employees. We also have recreational facilities and other things that become considered the part of the layouting of a varos itself. Example of a varos. The second is about when you look at the employee timing in the logic side, it's a usual eight hour shift that we manage. We have a eight hour shift and there is a OT over time paid for the remaining two to three hours that we extend the thing as per the laws defined by various geographies of India. So we follow that thing. Like how do you measure an FE's efficiency for example? So given time, so it's about not about the number of products that we d