Hi Lauren,
Thanks for coming back to me.
Regarding the sandbox environment ETAs, we appreciate this feedback. Indeed the ETAs in this environment might not be as ‘realistic’ as we might like due to the way that driver bots are managed. We will report these issues you reported internally to see how we can improve.
Perhaps a possible workaround to avoid a 0 value for example, could be to create several jobs around the same location. This would typically cause more driver bots to spawn and this availability should then be reflected in the ETAs.
Thank you, we will continue testing on the Sandbox environment. I did notice that the values tended to be more “accurate” when multiple deliveries were being made, but they were rather fast to reset back to defaults, and the timings weren’t too clear. Any improvement to simulations and ETAs will be welcome, but I realize that can take time to change. Hence why I sought to reach out to confirm how it would / should behave in Production.
For your first question, this may depend on your order and preparation flow. Some questions that might help are:
Generally we are dealing with two kinds of scenarios:
- An ASAP delivery. At which point we would put
PickupAt = Now + PreparationTime
- A scheduled delivery, where a customer places an order for the future
Therefore, in short:
- Do you know the preparation time of each order?
Yes. Our system operates with a general Meal Preparation Time setting that is being used for all time estimate calculations our end and it is a known value for each job.
- When in the flow would you request the ETA?
In our scenarios, we would have to know ETAs at the time of customer placing order within our system in order to:
- Provide customer with earliest possible time of delivery
- Determine whether order can be sent to kitchen for preparation right away, or whether it has to be delayed so that the food isn’t prepared too early in relation to Pickup.
As such we would likely call an ETA endpoint as soon as we have an Address.
- When in the order flow will you trigger the Stuart job to be created?
In case of an ASAP delivery, we would create a delivery Job as soon as the order is placed with the site, at which point we should already have received an ETA to account for with food preparation. I’ll provide an example below.
In case of Scheduled Deliveries for later time, I admit I am not completely certain what the best route is. I imagine we would also book in delivery Job at the time the order is placed with site, so that we can “book” a job within Stuart system for requested (or closest available) Pickup time. Again, this is mostly so that we can schedule what time we should start preparing the food in such a way that it isn’t picked up too early, or too late.
Hopefully that describes our use case scenario. However, let me provide some examples, for the sake of being thorough and leaving information for anyone else having similar questions.
Example 1: ASAP Delivery Scenario
In the first scenario when customer orders food for ASAP, I imagine we would request an ETA as soon as we have customer’s address, at the time of customer placing the order. This will be used for two things:
- Provide customer with estimate time
- Determine whether we can start preparing food immediately based on driver availability, or whether we have to delay preparation of food because no driver can pick it up right away. This is fairly important to ensure that the dish is as fresh as possible.
Assuming that customer is happy with estimates, we would then create a delivery Job right at the end of customer placing the order, with reasonable PickupAt time that can satisfy both kitchen staff and driver.
To work with some values, let’s assume it’s 13:00 now, and a customer phones in and orders food for ASAP. Assuming our Meal Prep Time is 20 minutes, we would then request a PickupAt time of 13:20, and then call the /v2/jobs/eta endpoint to check if we can get an ETA that confirms that the time can be met.
If I understood the linked forum posts correctly, we would then receive either an ETA of 0, which we read as “we are likely to meet the requested PickupAt time”, or any positive integer value, which means something along the lines of “we cannot guarantee a driver to be available at this PickupAt time, we need extra time of {Eta Respone}”.
In case of ETA 0, we would send an order to the kitchen for preparation immediately, and create delivery Job right away for PickupAt 13:20.
However, if we receive an ETA of, let’s say, 20 minutes (so eta of 1,200 secods, but I’ll keep referring in minutes), I would currently interpret that as “we cannot guarantee an order to be picked up before 13:40 (13:20 + 20 minutes ETA)”. At which time we would delay sending the order to kitchen by 20 minutes, but we would still create delivery Job with PickAt 13:40.
Scheduled Delivery
For the most part I imagine this would work in similar way, except instead of working with times relative to now, we’re working with future time, which I understand makes coming up with realistic time estimates slightly harder because, as you say, they represent current state of the fleet. I suppose the valid question here is, do the ETAs server by the endpoint account for already scheduled deliveries across your customers?
I appreciate that estimates are just that, estimates. Our default approach would be to place a delivery Job at the time of accepting customer’s order our end. Say, customer places order at 13:00, but they want the food ready and delivered at 18:00. Let’s assume average delivery time of 20 minutes, this would make us request a PickupAt value of 17:40 (18:00 - avg. delivery time of 20) and internally schedule food for prep at 17:20 (18:00 - avg. delivery time - prep time).
With how I understand the system currently, I am thinking that the best approach is to call the ETA endpoint at the time of placing the order (which would be at 13:00), and send an ETA request with PickupAt 17:40. In my mind, and that is 100% assumption on my side and might be completely wrong on this, this would effectively create an ETA based on the number of scheduled deliveries across your customers around that time, to estimate whether or not that time can be met.
Like with ASAP deliveries, I imagine that if we receive ETA of 0, then that means there is currently no heavy load predicted for around that time and a driver is likely to arrive at requested PickupAt time, therefore we would create delivery Job with PickupAt of 17:40.
If we receive a positive number, we would, once again, delay the order by ETA time received. So, say, if we receive ETA of 20 back, we would relay this info back to user to make them aware of delay, and if they’re happy with that, we would then create a delivery Job with PickupAt of 18:00 (original pickup time 17:40 + 20 minutes ETA) (and consequently schedule food to be prepared at 17:40 instead of 17:20).
Summary
Apologies for a lengthy post, I I thought it best to explain how we currently understand the behaviour based on the provided documentation, since ETAs on Sandbox behave in the way they do and have left us with degree of uncertainty.
Please let me know if the above matches with the recommended usage of the system, or if not, I would appreciate if you could correct me where my understanding is incorrect / suggest alternative approach.
I appreciate your help.
Kind regards,
Sebastian