 Great. So, I'm Venkatesh and I'm a data scientist at Swiggy. Those of you who got a chance to attend the last session by Nitin will probably have an understanding of the way in which recommendation systems work at Swiggy and how relevance to ranking is being done. What I'm going to talk about is sort of the other side of things. The delivery system, like how do orders get delivered? What are the issues that are being faced? The topic is serviceability under high demand, which refers to the need, the requirement to maintain reasonable serviceability even when the customer demands are high. Okay, so I'm sure most of you here are familiar with how Swiggy works. It's basically an online on-demand platform where the customer orders food from the restaurant, subsequent to which delivery agent is assigned to the order who goes to the restaurant and waits for the order to get prepared if it already hasn't been, picks it up and then delivers it to the customer. That's the order cycle. Imagine what the ideal scenario for an on-demand company, on-demand delivery company like Swiggy would be. To make things a little bit more definite, imagine there were infinite resources both unlimited on-demand delivery fleet as well as complete information about the future. Let's not discount that. Complete information about the future, right? Then we would be able to service, we would ideally like to be able to service any customer ordering from any restaurant at any time of the day in any situation, rain or shine, thunderstorms, no, it doesn't matter. In any sort of patterns, unpredictable patterns like traffic and promise a reasonable amount of time for delivery and ensure that the order gets delivered within that promised time. That's sort of the ideal thing that we would hope for. Unfortunately, we have to deal with real-world constraints. We have finite delivery fleet. We have unpredictable scenarios like a hinted bad weather or a competitor server is done which leads to a spike in customer demand to our platform. Even on normal times, leave out bad weather. Even normal times, the customer demand is significantly variable. And so are restaurant preparation times. Part of it is because like restaurant preparation times aren't carefully instrumented and also because restaurants don't provide clear information about how much time they require to prepare a particular type of dish. In addition, you also have variations coming from the actual delivery agent for the same restaurant customer pair because a delivery agent who's more familiar with the neighborhood would be able to take shortcuts and get to the destination earlier. And this happens sort of more often than you might think. And even if it's not really shortcuts, like if you're just more familiar with the neighborhood, I'm sure from your own experience of like getting from point A to point B, if you're just more familiar, you'd sort of know, say, which lane to be on and stuff, right? So it just makes things different. So there's significant variability coming there as well. And then the fleet itself is only partially on demand. I mean, if we know in advance that we need something, say a week, a week in advance, then yes, probably get there or get very close to that. But then if I need like a sudden surge and say, the delivery fleet in the next half an hour, the chances of actually reaching the target are quite slim. So it's partially on demand. Now, what are some ways in which so we can address these real-world constraints? Now, I'm just going to go through every one of them. They're going to sound a bit disconnected. And I'll sort of expand on them as we go along. And hopefully at the end of the talk, you'll be able to see how these things sort of lie together. But here I'll just very briefly describe them. The first step here is, of course, that, you know, we're talking about situations of stress. We're talking about situations of high demand. But we need to sort of quantify that, preferably with a single metric, quantify the load on the delivery system. That's like the first thing. Then we can represent at any given time the undelivered orders, the orders that have entered into the system, the orders that we've accepted, orders we're obligated to fulfill, but we haven't delivered yet. Treat the undelivered orders as a queue. And just without any other queuing thing, you have an inflow and outflow. You have new orders coming in and you have an outflow of orders, which is basically the orders getting delivered. So you use queuing model abstractions on top of that. Then, of course, as you can all imagine, and I kept referring to it earlier as well, you need predictive models. Predictive models everywhere. Predictive models for the orders that are going to come in, say, the next 10 minutes of time. Predictive models for the preparation time of the restaurant. Predictive models for, say, the time it takes for the delivery agent to go from pick up the order from the restaurant and actually delivering it to the customer. So we also need real-time strategies to reduce demand. That's the whole point. So we have serviceability and you have demand and you want to sort of reduce the demand. And with everything else, we'll get into the details in a bit. But it's not just about reducing demand. It's also about which... How should I reduce the orders? How can I allocate my demand? How can I shape my demand? Not all orders are created equal. Maybe I might want to prioritize certain orders based on, say, which restaurant the customer is or the location of the restaurant is. So it's also about intelligent demand allocation. Okay, now, so that, you know, you sort of... So that I can sort of intuitively formulate the problem statement. Let's consider a somewhat hypothetical scenario. Let's say that the orders could get arbitrarily delayed. Let's say we give us the permission for the orders to get arbitrarily delayed. Now, in principle, then, all incoming orders can be accepted and they can be delivered in due course. Now, the simple reason for this is because even if you consider, like, a peak time, like dinner, right? So imagine between 7 p.m. and 9.30 p.m. where there's going to be, like, a surge in demand. Eventually, the peak is going to... You're going to go past the peak and the demand's going to come down and then the orders that have been backed up over time will eventually get delivered, right, through the night. So you can certainly, in principle, control the orders, right? If you have the condition that you don't care about how delayed they get. Naturally, the problem is that this creates a terrible customer experience because a lot of the orders are going to get delayed immensely. So when you put it in these terms, when I structure it in these terms, then naturally the question then becomes that I want to take just as many orders, real time, right? I need to make real time decisions about the number of orders I want to take in the next interval such that they get serviced reasonably, right? And like I said, also be smart about which specific demands to take. Which specific orders to take. Okay, so let's just give you a sense of the difficulty involved in this thing. So let me just point this out. Like I said, we need to limit the orders. That's clear. We need to somehow choke on the orders at some level. So that we can, the ones that we accept, we can deliver it within reasonable time. Now for the orders that we do accept the question is what strategy to be used so that we can deliver it within the promised times. So one, you want to limit orders so that the ones you take, you deliver it within the thing, promise times. And then once the order actually comes and what strategy do you actually adopt that becomes a reality, right? Now on a temporal axis, one proceeds to, you need to first get to one, the filtering stage and then you get to two. But the solution to one depends on the solution to two. So if you were to think purely at an order level, in a certain sense there's a circular dependency and you can't actually even solve it, right? But that's only a theoretical thing. In reality, of course, you use approximations and assumptions. Specifically, you think in terms of averages and you think in terms of fluctuations about the averages. You talk about, say, error margins and how error margins will affect decision making. So let's study this thing that I talked about, the quantification of the load, right? What is a metric that captures a load on the delivery system? One straightforward metric is what you see there. Yeah. So it's just the ratio of the number of undelivered orders divided by the number of delivery agents. I'll call it the stress ratio, right? Now before we sort of study this a little bit further, it's intuitively appealing because if you keep the number of delivery agents constant and increase the number of undelivered orders, you naturally expect that the system is under greater stress. Likewise, if your undelivered orders are kept constant and you increase the number of delivery agents, then the resources is better spread out, right? I mean, the orders are better spread out among the resources. So you're under lesser stress. So it's kind of, it has an immediate intuitive appeal. Now, one very important thing is that everything that I'm going to talk about, everything that I have talked about and everything I am going to talk about deals with scenarios where s is greater than 1. We do certainly have situations where s is less than 1. But for all practical purpose, that's a trivial situation. When s is less than 1, in most cases the serviceability is pretty good. We're able to get the orders in the promise times and yes, even there we can do optimization, we can improve. But the gains from that are much less. The real problem occurs when s is greater than 1. And most of the times when you're ordering at say weekend dinner or even weekend lunch, you're talking about s significantly being greater than 1. And everything else I'm going to talk about will concern that scenario. There's less than 1. You can think of it as a trivial case. Now we have a stress factor. Let's also say that we somehow arrive at an s max. Some threshold on the stress factor beyond which serviceability drops below acceptable levels. Now let's set aside the question of how we get to the s max. Let's just say that we have some s max for a given area. And we want to make sure that s doesn't breach s max. So let's see how that can, how we could possibly do that. I want to take a quick detour now to sort of queuing model abstraction. It's really simple. It's just very straightforward. But we'll be sort of referring back to this. Like I said, your undelivered orders kind of is the queue. That's the undelivered orders. Now consider interval of time delta t. A short interval of time delta t. And let delta a be the number of orders coming in. And delta b the number of orders getting delivered within that interval of time delta t. Now your change in the number of undelivered orders is nothing but the inflow delta a minus the outflow delta b. Just simple arithmetic. So this is change equal to change in inflow change in outflow. Now the problem is that we want the stress factor to remain under s max. So you can think of a situation where s is approaching s max. So that's when you want to like throttle the orders. But we need to be careful about what it is we are throttling and when we are throttling. So in that there is a customer who spent a lot of time looking at the home page, biggy home page, browsing through the restaurants, finally decides on the restaurant and then consults with four or five of his friends, comes with a bunch of items and then adds it to the cart and just about, when he is about to make a payment something flashing on the screen saying that the order cannot be processed because all the delivery agents are busy. It's a terrible customer experience. So added problem is that you want to throttle the orders but you don't want to throttle the orders when users are there just about to make the order. At least you want to minimize that. If you cannot completely eliminate it you want to really minimize that. So the thing then is that you want to apply this intervention whatever your throttling intervention is upstream before you get to that state. You want to apply it preferably at listing. It's much better that the customer didn't see the restaurant in the first place. Dance the restaurant and then add items to the cart and then discover that well this order can't be processed. Okay. So now let's kind of like dive a little bit deeper into this thing. So imagine that you are at 90% of the S-Max, your threshold stress. You don't want to cross it. If you're at 90% of it, you want to do something. You want to take some real-time strategies. The thing is that how much orders do we, how much should we do the orders and for how long. And in general this is quite a difficult question to answer. Okay. But here are a few things. Here are a few facts that will sort of help us in terms of arriving at a solution or an approximate solution. The first is that the delivery fleet is more or less constant. And the delivery rate is also almost fixed. It's a constant. This can be kind of shown analytically but also empirically you can see that this is true. And you can think of that as some sort of quasi-static assumption that over the period of time things are not changing so dramatically that the delivery rate is changing. Fact number two is that if order acceptance rate inflow is equal to the delivery rate outflow then your stress levels don't change which goes back to the queuing thing. Your undelivered orders is equal change in undelivered orders is inflow minus outflow. The inflow is equal to outflow then your undelivered orders don't change and you're assuming that in that quasi-static assumption the delivery fleet doesn't change and so your stress factor also stays the same. Fact three is that if you can actually predict if I'm here and say this is at 8pm and if I can predict what's going to happen between 8pm and 810pm for that particular region I can specifically predict the number of unconstrained orders and I know what I need to actually what how many orders I can take based on the delivery rate because the delivery rate is fixed determine purely a deterministic function of the on an average deterministic function of the fleet size so I know how many orders I should accept in the next 10 minutes and if I can predict the number of unconstrained orders unconstrained being that I didn't intervene I didn't use any strategy then I know what fraction of the orders to accept which sort of naturally brings us to demand prediction so predict the number of incoming orders in a rolling horizon of say 10 minutes and as you can imagine the features that we would use are order rate in recent times but also like the order rate at a similar time previous week because if you look at the order rate it's sort of going to go like this it's going to reach its peak and it's going to go it's going to decrease at say dinner peak or lunch peak and I think this is without even knowing any data you sort of intuitively that's going to be true more or less right so if you want to know what's going to happen in 8 and 810 you want to know whether 8 to 810 is that point where it's still increasing on an average or it is at the point where you already crossed the peak and you're sort of going down and of course if you clearly have an established trend of going down at the point then of course you probably may not need the historical data so much but then if you want to know where the point of where the changes of the inflection is then you certainly need to know the historical data so you also use historical data at a similar time at a similar zone in a previous week maybe like a whole bunch of other several weeks put together in addition you also want to know sort of what's the activity on the app or the browser or whatever platform people are using to order right you want to know how many people are enlisting because then these are the people that will actually well the screen seems to have gone blank okay so while this is getting fixed here so you sort of want to know like what the activity is and then you take that also as a feature and in order to predict the demand now one crucial thing is this time t right I told you want to predict for the next interval of time ten minutes and this is kind of a crucial thing now there's a tradeoff involved in this prediction of time t on the one hand I want t to be large enough so that the numbers the raw numbers are going to be higher simple thing right if I take it a longer time more number of orders so my error as a fraction of the number of orders is going to be smaller the reason being that statistical fluctuations for larger numbers is going to be smaller some of you understand say for instance if you think of this as a Poisson process then if n is the number then the standard coefficient standard deviation is root n and so root n over n is 1 over square root of n so then it becomes larger your error is a fraction decreases so you want to keep t large so that your fractional error is smaller but at the same time we want to work under the quasi-static assumption so you don't want t to be large enough the situation on the ground is completely changed specifically the number of delivery agents has changed dramatically or that you have sudden thunderstorms that you're encountering so t is a trade-off there between how much, how accurate you want your predictions to be and how much of your quasi-static assumption you sort of want to maintain or to retain right and in general it depends on the properties of the area so far I've told you like what have we done so far we've said that here we get multiple orders we have some stress factor and we get a threshold for the stress factor we don't want the s to cross the stress factor to cross that threshold and so we are kind of throttling the orders and then we're throttling the orders by predicting what's going to happen in the next 10 minutes and then sort of limiting things at listing or which we will sort of discuss maybe in a little bit more detail but now the question is which orders do we actually limit and which ones do we allow should we treat them all in equal footing now a standard approach in these kinds of things is that you use some sort of a customer segmentation you divide your customer base into some sort of segments based on say revenue, based on loyalty like the premium customers the not so premium customers the people who order frequently, the people who don't order frequently whatever you do that it doesn't matter what exactly you do you have now some sort of segments some sort of slots based on your whatever calculations you did earlier and then you say that we allocate that to the premium customers and then to the next category and then when they fill up you move on to the next one so that way you sort of like prioritize your higher people who are higher up in the segment that's one thing now a problem here is that like I said we're talking here about errors right we're talking about errors and demand prediction now if I were to implement something like this it also means that I have to predict not just the total demand I have to predict the probability the composition probability of each of the segments in that upcoming demand and because these are the composition itself it's going to be smaller than the total the fraction of errors are going to be greater in each so that's something to keep in mind an alternative approach is that you make your decision purely based on the location of customers restaurant customer distance let me rephrase this this is probably a little bit opaque let me rephrase this imagine you have restaurant right and for every restaurant there's a radius there's a radius over which any customer who's within that radius can actually access that restaurant can actually see that restaurant on the thing what I'm talking about here is that you shrink the radius and so you have two concentric circles with about the restaurant and so the customers who are sort of lying between those two concentric circles can no longer place the order then naturally depending on the distribution of customers you're going to sort of total the demand because just because based on how these are distributed as a function of the radius you're going to have fewer and fewer customers actually going ahead and placing the order but then there's something else over here there's something else that happens over here so we go back to the original queuing model abstraction right so you change delta n equal delta a minus delta b clearly delta a is getting affected you're reducing it you're reducing the radii fewer people order but there's something else now from the restaurant's point of view the average time it takes for the restaurant to customer travel time has reduced because you've shrunk the radius that average travel time is reduced what this means is that the average cycle time has reduced the average time between ordering and delivering has reduced which means your delivery efficiency your delivery rate your throughput increases which means that this action not only reduces delta it also increases delta b so it has it it works at both ends it decreases it throttles the orders at the same time it increases your delivery rate and when you apply it to an entire area this effect is actually it's actually really you know it's very much measurable it's not just sort of theoretical nicety something that we can actually determine okay cool right so you know we formulated the problem as take as many orders as so that real time take as many orders so that you can service them right that's kind of how I've we've gotten to this point but then of course we need to also understand what has been the loss in orders we've applied some strategy and we've gotten to a point but we also need to understand estimate how much has been the potential loss in orders to the counterfactual scenario where you didn't even impose such a strategy now again this this problem is nothing but is equivalent to estimating the unconstrained order flow unconstrained order flow over that entire interval say you apply the strategy for two hours right and you have a certain order rate you actually measure but you want to know what would have been the unconstrained order rate had you not done anything now in general estimating that unconstrained order flow is quite difficult okay I don't want you to get confused between this unconstrained flow and what I talked about for the ten minute interval that unconstrained referred to the application of the strategy for the next ten minutes I'm talking here about you applied the strategy and you're talking about the entire unconstrained order flow for the full interval of time this is rather difficult estimate the problem is that even something like AB testing is difficult because it's just way too many variables let me give you a more intuitive understanding of why this is difficult right but typically what do you do with AB testing say for example in this case what would you like to you would ideally like to pick up another similar area or you want to pick up a similar day a similar hour of time or interval of time and you want to look at how the order looks like you don't apply any strategy then you look at you apply a strategy on a different day you compare it leaving aside the fact that you know on the day that you don't apply a strategy a lot of customers are going to get pissed off let's even let that slide from purely from understanding making a comparison if you want to think of AB testing you want to have all the variables more or less similar and that's the standard understanding think about this here your variables are not just things like say some fixed set finite set of things you're talking about not just mere average you're talking about a shape talking about a curve a trajectory for the order rate you're talking about a trajectory for the number of delivery agents right so for two things to be compared your trajectories have to be similar very similar and they may not necessarily just depend upon some say F prime absolute values average right it might also depend upon the peaks the sudden spikes that occur so establishing similarity of regions over significant interval of time when in fact what we are measuring and differences we're seeing is of the order 5% and 10% we're not seeing differences of say 50% where okay fine we're okay with very different things because you know if it weighs a little bit but if our numbers are very different we can still make a statistically significant claim but then no we're talking about things that probably weigh by 5% 10% 20% okay so so far I've talked about so the demand side of things right the order flows and then throttling them and then selecting them and so on so forth there's also the supply side control the restaurant parameters right and I sort of hinted this earlier as well say that you you know you you sort of want to limit the orders but then you want to limit them in a specific way which is which is a function of the restaurant leave out the restaurant customer distance for the moment but other things for instance the preparation time this is also mentioned in the earlier talk when you when you have restaurants with high preparation times when you have a say all you have restaurants that have a lot of orders that are backed up you want orders to shape away from that right so you can basically deprioritize those kinds of restaurants or not take orders not show them at listing and towards those places or temporarily shut them down temporarily shut them down for a half an hour or something so that you can shape the demand towards restaurants with shorter preparation times and again here you need to understand and quantify the trade off between potential order laws and increase in the delivery efficiency of the system and the second part is is very important again because again restaurant preparation when you when you when you do this reallocation it not only does it ensure that you're having better service what it again does is that your cycle time is reduced you have shorter preparation times so your order gets completed quickly your cycle time is shorter your delivery rate increases so it ends up like carrying your queue faster okay so then of course there is the heart of the thing right everything I've talked about is the center of that all of this lies the assignment algorithm right what is the procedure that is used when an order comes in to assign it to a delivery agent what is it that we are optimizing it is it like do I need to optimize for the average order to deliver time being minimum or should I optimize for the 90th percentile of the order to deliver time being minimum or do I optimize for say the fraction of orders that exceeds the promise time of delivery by 10 minutes right or do I take a completely different approach so I don't know if you're sort of one common thing in the talk is that formulating a problem itself in this case is a part of the challenge right requires significant thinking and effort so but then at least you know that the things that we need are again the preparation times you want to know you want to be there when the order is prepared but not much earlier because then the delivery agent has to be waiting there right and then the restaurant to customer travel time and the time taken to travel to the restaurant itself once the delivery agent delivers an order you need to go to the restaurant for the next order for the next pickup then of course there is batching you basically batch a couple of orders two orders of the same restaurant nearby customers you want to group them together with the same D pick up both deliver one and then go ahead and deliver the second so you can imagine even again without actually getting into math and I think you just imagine how much more difficult that becomes right you now have to have two different orders when the delivery agent picks it up both orders should be completed and once it's picked up and sent to the first and delivered it should be within compliance within the within the promise time and then travel time to the next one and it should again meet that requirement that it's there in the in the sort of promise time and in some algorithms you might want to make that assignment while the DE is still completing the earlier trip so you understand the complexity of the problem then of course there is error propagation understand things like error propagation how much is errors in preparation time affecting delays and decreasing delivery efficiency okay so so then there is a whole host of issues and I've sort of addressed some of them which is probably some of these which seem like a repeat like I said there's a lot of variability there's a lot of stochastic component to the variables that limits the predictability and that's something that said pretty much every aspect of the delivery problem and then of course like I said coming up with an appropriate metric or sort of quantities will help us evaluate two comparable scenarios to do some sort of an A-B testing and the other thing is that just that not a way to not know what the sort of the global solution is the methodology for the global solution we don't know how much our solution differs deviates from the global solution right if I'm talking about say the assignment algorithm and I say I get some delivery efficiency the algorithm that I have and let's say that there is some unknown oracle given sort of globally optimal solution to the problem and I not only do not know that I also don't know how much it differs from what I currently have right then of course the challenges running carefully controlled experiments because it's like you don't want to shut off restaurants too much you don't want to like keep changing too many of the parameters connected with it so there is obviously issues connected with not upsetting the business too much and still being able to run these experiments and then of course like I said to understand the effects of unexpected delays what happens in those cases and in general it's like a system with many components many interacting components and where the effects sort of propagate so it's sort of a heart angle exactly which one leads to what so yeah and that brings us to the end of the talk and thank you for your time questions please thank you thank you please raise your hands if you have questions yeah over there let's start over there you mentioned about inflows and outflows oh hey so do you consider order value also while you are forming the strategy for throttling right so like I said order value if you're doing a customer segmentation then you need to do something like that but yes in that case yes you need to make a dimmer you need to predict the fraction of various composition of customers that come in in the back over there you can start it was a great session really nice to know all the problems and the intuition you had about it and the way you presented so one of the things that I would like to know is like the different set of model forms that you have used and what loss functions you have assumed like for example in some of the problems like did you take into account what is optimal for the customer experience or did you also take into account revenue which maximizes margin revenue and things like that from a modeling point of view and also from a business point of view so let's slightly break this down the first part is that when it comes to say the revenue the only way it enters into sort of the delivery calculation is when you're trying to throttle the orders and decide whom to show which customers will get access to viewing that restaurant or that region or some such thing that's the only place so far that we have used the actual revenue information but then the other thing is sort of more significant the idea that what is it that you sort of want to optimize for is a customer satisfaction what is customer satisfaction if I promise a delivery in 35 minutes and if I took 50 minutes clearly that is a very clear case of customer dissatisfaction but then if I had already promised you 45 minutes if I showed you 45 instead of 35 then maybe it's not so bad so the question is what I promise should I sort of change the time that I actually promise so that I can attain the delivery within that time or should I sort of minimize the overall the average time or say the 90th percentile of that maybe the focus is on ensuring that order gets delivered within the time or maybe within 10 minutes of the time that tends to be the typical focus all else being equal but they are really not always equal so hello yeah could you please explain a little detail about the assignment algorithm a little bit sure I mean so obviously I can't get into all the details but okay so the idea is that you want to make an assignment in such a way that an order comes in you have information about you know say what the promise time is you have information about say the restaurant something say it's preparation time right and you have information about prediction about again all of these are predictions right how much time it takes to go from the restaurant to the customer so think about this right one simple thing is that you want the order to reach say in 40 minutes and so you work backward and try and see like when it should get to the when the food should be prepared so that when the DE should reach it so that it can reach in 40 minutes because you have the time from the restaurant to the customer so you try to ensure that delivery agent gets there but you don't want the delivery agent to get too early there because then he has to wait right and so you sort of send the delivery agent so that this gap is a minimum that's one thing now imagine if you have more than one order simultaneously you're batching the order right now the thing is you have now the last leg is essentially the first customer to second customer restaurant to the first customer and so that has to both happen meeting compliance so you have to decide which of the two orderings is better for you and you have to also ensure that by the time you pick up both orders are actually ready and at the same time you don't want to keep them waiting so it's about combining all of these different things Hi so you mentioned the delivery radius the serviceability so how is that defined because I think that that might keep changing as the demand goes up so typically what happens is that there are some fixed parameters associated with different areas for these things ideally you keep them fixed and you don't sort of ideally we don't want to tweak any of these things but then the everything I'm talking about is dealing with scenarios where you need to apply some real-time strategy right and then you're suddenly facing a surge in demand is reaching points where you feel like you've sort of no recent prior knowledge that your serviceability numbers are going to fall so you need to throttle them so then you sort of reduce the shrink the radius I don't know if I answer the question but maybe only one okay let's go Hi apart from using the size of the delivery fleet and the average time delivery agent you takes to deliver an order do you also consider parameters like if like a very popular restaurant like Truffles or Meghna Biryani is not able to churn out that many number of orders in a small time period of time is that also a serviceability factor can you repeat that question again for like very popular restaurants where there is a very very high demand from various channels including Swiggy and other food tech companies is the serviceability factor also takes into account the capacity of them churning out those many orders so that's the thing that I talked about like the supply side control so yeah we certainly like look at say the near real time last 15 minutes last 30 minutes preparation time at the restaurant or more we might use proxies like order to picked up time right so if it's if it's too high then we deep prioritize it both like in listing like or we deep prioritize it in terms of basically shutting it down temporarily but yes those things are very much part of it especially during you know some big events and stuff any more questions okay thanks for the invitation now a round of applause for him please