Grubhub for Drivers:
Order is not Ready
Discovery
Looking at contact data from Driver Care, we were seeing an increase in calls at a particular point in the delivery flow— when the driver arrives to the restaurant. Parsing through all of the reasons for the calls, we honed in on a specific scenario that could potentially be automated. A lot of the calls were coming from drivers who arrive at a restaurant, discover that the order they’re picking up isn’t ready and contact Care to:
Vent frustration about the order not being ready (rightfully so). Theoretically, this could be either because the restaurant is really busy and needs more time making the food, or because our dispatch algorithm sent the driver to the restaurant to soon. Either way, the only resolution here is for the driver to wait for the food
Express concern that they would be negatively affected if the delivery ETA needed to be pushed back due to something out of their control—the restaurant’s delay.
These calls made up a high majority of contacts from this point in the delivery flow, the second-highest majority being from drivers whose orders were reported missing.
We discovered these contacts could be parsed even further, so that on one hand we could preserve the ability for the driver to contact Care in scenarios when only a Care agent could solve the issue. In other scenarios, the conversation a driver would have had with an agent could be automated via the app, allowing the driver to self-solve and GH to collect useful data about the delivery in the process.
Methodology
Driver Care process flows
The first step to figuring out which processes could be automated and which could only be solved by an agent, was working with Care directly to understand the existing SOP. Having eyes on what happens on the other end of a phone when a driver contacts Care helped me avoid redundancies in the design and make sure I was only focusing on the two major scenarios which were causing the most contacts— order is not ready and order is missing.
An evaluation of our existing in-app flow (above) revealed that at a restaurant, a driver could indicate an order not being ready and we would direct them to a Care contact without doing any further investigation.
Ideal flow
Our ideal flow would instead ask the driver whether the order is not ready or if the order is missing, before giving them the option to contact Care. This allowed us to isolate contacts coming in to only those cases when an agent would need to solve. In the case of an order not being ready, there’s nothing an agent can do to speed up the process and most times the driver just needs to wait. The driver of course has the option of not waiting and dropping the order, but this is something we could automate as well.
As a value add, we wanted to use this opportunity to collect a bit of data from the driver so that we could form a case for improving our ETA models in the future. If we saw that under the same conditions, orders were repeatedly behind by 10 or 20 mins, we could adjust our models to account for that difference and send our drivers to pick up orders later.
Final flow
Solution & Outcomes
The final solution gives our drivers the reassurance they were looking for, but also lets them ‘vent’ in a way that is productive and helps us to better prevent the scenario in the future. It also alleviates the load on our Care teams so they can focus on other issues.
Figma prototype
We saw high adoption by a month after launch, with driver contacts regarding late orders being down about 40%. Most drivers (about 60%) using the feature reported delays of 10-20 mins, the main reason being the order was still being prepared when they arrived at the restaurant.
In collecting this data we hoped we could build a case for not penalizing drivers in the event they choose to drop an order that is late on the restaurants part. We’d also want to hold our restaurant partners accountable in the event we’re receiving repeated reports of their orders not being ready by the driver’s pickup time.