Hi,
Currently, there is no way for us to check which orders were sent from our side and were:
not accepted by Stuart (based on no riders available, or any other reason for which driver assignment doesn’t take place) and
were accepted and then cancelled by the rider/courier.
How can we have visibility on that? The dashboard currently only shows successful deliveries, which does not present the correct picture
Moreoever, for the first point, the following query was raised by our internal support staff:
“An order was meant to be delivered at 12:02 AM on Sunday by Stuart. When we checked on Stuart’s dashboard, no courier had been assigned till then (which should have been as it had been a long time since the order was pending). We then tried to manually assign a rider through the Stuart dashboard, by clicking on ‘delivery request’ but the page was not loading and remained blank. We reloaded the page numerous times but no good and as such the order failed.”
This probably suggests that there were no riders available during that time, and unfortunately, we had zero visibility on what the issue may have been. How can we have visibility on that?
In the dashboard, you have three tabs (Ongoing deliveries, Scheduled and History).
In the History tab, you should see the list of all orders (successful or not).
You can see in the screenshot below the difference between successful and cancelled deliveries (rating available, invoice available):
For your first example, I can see in our logs that you cancelled this delivery (#180582194) a few seconds after a driver accepted it, so it was not delivered by Stuart.
But then you created a new delivery with the same id (#180584478), which was successfully delivered, that’s why it appears as such in your system.
I don’t find your second example in our systems, but I guess it might be the same behaviour.
Also please notice that the courrier supply can be low at some points due to many reasons (high demand, bad weather conditions…), and that it can sometimes take time to find an available driver, and that reloading the page won’t help.
In that case, there should be a notification/some sort of communication, whereby we have visibility of the situation so that the same could be communicated to the customers. Currently, we have zero visibility and that is an issue.
About cancelled deliveries, we do send a cancel event via webhooks, so you should be able to see it in your system (based on the “clientReference” ideally). We are also working at improving the interface to handle these cases in a better way.
About the package, the driver accepted at “07/01/2022, 20:50:46”, and the delivery was cancelled by api at “07/01/2022, 20:50:54” with the reason “no_supply”, so you probably didn’t received the event on your system at that time.
This is an issue. Firstly, we’re delivering freshly-cooked food, so if a rider is not found/assigned AFTER a restaurant has cooked the food, then that is a significant issue. Secondly, what is more worrying is that in such instances, we have ZERO visibility of a cancellation/failed assignment/rejection from the rider. If orders are paid for by card by the customer and the restaurant prepares the food and then Stuart rejects/cancels/fails to assign a rider, we are responsible to compensate both the customer and restaurant.
If the API is cancelling a delivery with no intimation/notification, we have a VERY serious problem.
We are continuously working on improving the dashboard, thank you for your message telling us how important it is for you.
If I understand your implementation:
restaurants follow the deliveries on Stuart’s dashboard?
you receive the webhooks events in your system?
If so, you will receive in your system the events about cancelled (or timeout) deliveries, even if the cancellation comes from your side, as in your examples, and you should be able to at least have the correct statuses in your system, and maybe display it to your customers ?
