We applied the delay (restaurant notice + global delay) when generating the available timeslots for ordering. Then we filter timeslots with prep+shipping. So if you apply a delay of 30min and you have the prep+shipping default of 25min then your delay has no effect: you get [30-40] as the first available timeslot (your prep+ship filter doesn't filter anything)
2. the proposed solution
When you have a delay of 30min it means that the restaurant is 30min slower to make the order. So the delay needs to be added to the prep time when filtering. Now you get the 30min+25min -> [50-60] as first timeslot as one would expect.
The problem was not well understood. What is a misconception is that it seems (to devs) that the "delay bar" was to "slow down the whole platform". So you set 30min and then all customer ordering is delayed 30min (and restaurant prep time + rush mode comes on top of that). However it is not the business case.
The delay bar is a tool for the dispatcher. It means "A rider can not pickup things in the next 30min". The restaurant owner has his own delay (rush mode) which means "I can not start preparing an order in the next Xmin" (for now 25min).
So if prep time is 20min, a restaurant set rush mode (+25min) and dispatcher set a 20min delay. Then restaurant and dispatch are operating with the same "lateness", then the customer is just delayed 25min not 25min + 20min.
Also note that it doesn't take into account the travel time for the rider to go to the restaurant. It assumes the rider teleport to the restaurant for the pickup.
We applied the delay (restaurant notice + global delay) when generating the available timeslots for ordering. Then we filter timeslots with prep+shipping. So if you apply a delay of 30min and you have the prep+shipping default of 25min then your delay has no effect: you get [30-40] as the first available timeslot (your prep+ship filter doesn't filter anything)
2. the proposed solution When you have a delay of 30min it means that the restaurant is 30min slower to make the order. So the delay needs to be added to the prep time when filtering. Now you get the 30min+25min -> [50-60] as first timeslot as one would expect.The problem was not well understood. What is a misconception is that it seems (to devs) that the "delay bar" was to "slow down the whole platform". So you set 30min and then all customer ordering is delayed 30min (and restaurant prep time + rush mode comes on top of that). However it is not the business case.
The delay bar is a tool for the dispatcher. It means "A rider can not pickup things in the next 30min". The restaurant owner has his own delay (rush mode) which means "I can not start preparing an order in the next Xmin" (for now 25min).
So if prep time is 20min, a restaurant set rush mode (+25min) and dispatcher set a 20min delay. Then restaurant and dispatch are operating with the same "lateness", then the customer is just delayed 25min not 25min + 20min.
Also note that it doesn't take into account the travel time for the rider to go to the restaurant. It assumes the rider teleport to the restaurant for the pickup.