A Shipt product owner explains how the company groups orders for shoppers and plans their routes. Batching must balance store location and delivery windows against shopper limits like vehicle capacity and checkout time. Routing algorithms deliberately under-optimize to avoid reverse detours that frustrate customers, similar to Lyft Pool.
Chapters
I was kind of researching it a little bit in advance and, you know, saw that you do, as far as routing and kind of batching orders. Could you maybe, you know, share a little bit more about that?
Yeah, couple things here. This is a, it's a very big topic. Routing in and of itself, vehicle routing, or, you know, routing somebody along a path is a deep topic, not only in business, but also a deep topic in computer science, right? Like from my academic training, how do you design algorithms which, uh, can do that very efficiently? And it's generally, uh, it's supposed to be a hard problem in computer science to solve, to get all the routes exactly right, you know, within a, within a reasonable amount of time. There's— without geeking out too much on that, uh, there are 2 things that I can— I think I can cover in routing, uh, and batching, like you said. So one part is I do— I own the product at Shipt, which is responsible for batching orders together. So I think essentially, just to paint the context, the use case is simple. An order comes into— is placed into your, let's call it a marketplace. So your order is placed into the marketplace, and now there are many, many orders. There's a pool of orders. And what you are trying to do is, do you want to give one order to one shopper at one time? You know, let's say that it is at a store. and it is— and it needs to be delivered around a neighborhood at a certain time. Do you want to just do that one-on-one, or do you want to maybe find— try and find other orders which are at the same store, need to be delivered around the same place at the same time? What do you— how do you kind of like manage that use case? So one part is batching, which is how do you kind of club those orders together? And then the second part is actually routing and actually going and delivering them, right? So Both are hard problems, but for batching, we do take the, the what comes, what comes into account, which— so, so, so thinking of it in terms of, in terms of the 2 sides, in this case, uh, as I said, right, there are 3 sides. So in this case, the orders are already in the marketplace. So let's say that the, the inventory side is off the table because let's say that you have forecasted properly, you know that this items that somebody's ordering are in stock right now or expected to be in stock when they will be shopped, right? Let's just say that that side of the marketplace is off the table. Now let's talk about the other 2 sides, right? So batching. So if you batch, there are 2 things. Let's go over it one by one. So let's look at the shoppers and let's look at the customers. If you batch, one of 2 things can happen with the shoppers. It might just take them too long because there are sometimes, you know, your algorithms could go amok. and you might batch what, like, you know, 5, 10, 20 orders. You have to draw a reasonable amount of, a reasonable boundary somewhere because remember that there is a certain time as we set the context, there is a time, there's a 6 to 7 PM window, let's say, that you want the orders to be delivered. Now, if the shopper is going to spend 5 hours in just shopping so many orders, they're not going to be able to deliver it in a reasonable amount of time. So that is a limitation. So, you know, a shop, we do hear this from our shoppers, by the way, that Sometimes it's like the orders are too big, that I had to stand in checkout line multiple times. Everybody wants their own receipt, right? I mean, whether the orders are batched or unbatched, you and I as a customer, if our orders get batched, we will need our independent receipts in case we want to make returns or anything like that, exchanges or returns. So that needs to— so checkouts are separate. So all of that needs to happen, right? You know, just to walk you through the use case. So now it becomes— one of the things is how do we What do we actually club? What do we batch together? Like, do we batch many orders together? Do we batch something with a very, very heavy item load? For example, it's not uncommon. For example, this is how some sort of, I guess, abuse or some sort of exploitation of the marketplace happens. It's not uncommon for people to order like 20 bags of mulch. Through Shipt, right? For example, and you know, they're just paying for shipping, for example. It's just a very, very heavy order. And then how do you motivate shoppers to actually— how do you compensate them fairly? And if there is 20 bags of mulch, you're probably not going to be able to fit anything else physically in your car. How do we make sure we understand what is— how much the car can hold? Can it even hold 20 bags before we match this order with the shopper or before we batch the orders together? So all these problems we have to think of hard. at the time of batching. So that's one part. And as I was saying, so one part is whether the shopper can do it, whether this is feasible for the shopper. And the second part is if they don't do it, if we overcommit or overpromise due to the batching, you know, when we batch, then the members will not get their orders in time and then they will not be satisfied. And, you know, retail is one of the things, one of the gold standards of retail is if you promise something will be delivered at a certain time, you have to actually stick with that promise. So You know, otherwise, that's just how retail works today. That's just the precedent for Amazon and everybody, you know, USPS, you take anything, when it's promised, the delivery is promised, you have to meet the delivery promise. So that could suffer, they could suffer on that side as well. So just taking batching, right? These are, this is one example where it can go really south. And then very quickly covering routing, which was the other thing we talked about. One of the things that we saw at Lyft, And there is a blog about this. I encourage people to read it. It's from the data science team at Lyft. But if you think about Uber Pool, or Lyft Line was the same equivalent product at Lyft called Lyft Line, which is— it's the same idea as batching, which is a rider or a couple of riders are actually going in a certain direction. Can we actually utilize the capacity more? Can we actually pull more riders into the same car, up to 4 riders, let's say, you know, in a small car or in a sedan? Can we pull up to 4 people in a sedan so that, you know, we can actually increase capacity of that and we don't just have like empty vehicles routing around because it creates traffic and so on and so forth? One of the problems that came up at Lyft, which we actually see here as well sometimes come about at Shift, and we work on constantly. So for shared rides, a simple problem was users— the, the first person who's in the car would be extremely disappointed, uh, if the car went in an opposite direction to do the second pickup compared to the direction that they wanted to go. So let's say if the car— if they were south and the car wanted to go north, and if the car went like a minute south 1 more minute south to pick up the second party and then started going north. Now, you know, let's say that the sort— the, the north— their original journey was, let's say, 10 minutes, and then going, you know, south 1 minute and then coming back. So that takes it 12 minutes. That makes it to 12 minutes. They were extremely dissatisfied. They were okay if you went in the same direction 5 minutes away, like 5, 10, 15 minutes away sometimes. You know, you could go like— you could take a tangent like somewhere else. but not reverse. If you went anywhere reverse, that would actually create, you know, that would actually dissatisfy them. It's something similar that we see in our marketplace as well. Sometimes what happens is that there is a store where a shopper will pick up an order and then we would actually route them. This happens sometimes, you know, we would route them in one direction to drop off one and then they have to cross the store and go and drop off because the other person is actually across the store. Now there are no other orders in the store at the time. You already batched the orders that we had. But the shoppers are dissatisfied that you made me cross the store. Why couldn't you give me another order? Well, there wasn't any, right? So these type of problems that we see, and we have to actually program our algorithms for user experience. The way we say it is, you know, we almost under-optimize. So if we knew that this was the shortest distance, that this was the fastest time that the shopper could take, sometimes we would actually make it a little bit we would actually under-optimize and make it a little bit longer so that we can take the user experience into account, if that answers the question. These are all fascinating problems to solve in the marketplace.
