This was originally a Twitter thread, but long-form text is way less painful. Tonight’s rant sponsored by lukewarm Thai food that should have been inside me about 3 hours ago.
UberNoEats: A Real-Life Example of Customer Disservice.
So it seems like Uber / UberEats had some server issues tonight — their driver tracking tool was pretty messed up at first (as in, not loading), tons of product photos weren’t loading etc. Apparently, this also managed to somehow break order status.
So tonight, I was craving Thai. I normally order through DoorDash, who’s not perfect but generally delivers a great customer obsession and makes things right when things aren’t. Sadly, they didn’t deliver from the local Thai place so I made the very sad mistake of ordering through UberEats instead. I don’t use them often, this being my second food order through Uber ever, and now I definitely know why to avoid them.
So, anyways, I placed an order for some Thai at 5:39PM. Their app wasn’t really great, but whatever, it worked. App says it’ll take about an hour to complete. “Cool,” I thought, “it’s some pretty great Thai, it’s worth that wait.”
I get a call from the driver a 5:49, 10 minutes later; he apparently had to place the order manually (as in, in-person) at the restaurant, and they asked for a clarifications on some things — for some reason I wasn’t able to specify meat choice in the app, although both entrees I ordered come with a choice of different meats, so that needed clarified. Weird that the app didn’t do that right, but again not a big deal, not ever restaurant is in food delivery apps right every time.
Imagine my surprise when about 10 minutes later, at roughly 6PM, the UberEats app says my order’s almost arrived. Now, I’ve been to this restaurant in person a good few times, so I know it takes more than 10m to prepare a couple of entrees and a couple of appetizers; plus, the “arriving soon” notification doesn’t really mean a ton when the in-app driver location map is showing the driver a good few miles away. “Weird,” I thought, “but whatever, I know the order’s in the works at least.”
Regardless, I send the driver a message through the app clarifying how to find my apartment complex, since sometimes it’s not super obvious and I’ve had delivery drivers / ride-hailing services mess up before. The driver lets me know that he hasn’t even picked up the order yet, so I go back to hangrily watching Netflix.
Nothing much else happens for a while; I occasionally look back at the map and watch the driver’s icon move around a few miles away while ignoring the app’s insistence that my food is “arriving soon.” The, around 6:45, the order updates to say Order completed. Sort of weird, since I’d normally expect a delivery driver to call or text when they get to the apartment complex, since it has locked entry doors, but hey, they could have just left it outside on the porch, right?
Nope! I go outside, look around both the front and back entrances to the apartment complex, take a quick walk past the doors for some other buildings in the same lot, then go back inside and about 10 minutes later I use the app to give the delivery driver a call.
Real good thing I did, too. While the UberEats app told me the order was complete, it told the driver that the order was cancelled… even though the payment had been completed, and the restaurant had (by then) finished making the food. Well, it wasn’t cancelled by me so now both the driver and I are pretty confused. He lets me know he’s going to try connecting with UberEats support on his end and let me know what’s up.
About 15 minutes after that, he calls me back to let me know he wasn’t able to connect with UberEats support at all but he’d been able to connect with the restaurant, who was going to let the order go out (sensibly, since, you know, on their end the order was paid for, cooked up, etc). Driver’s sorting out his other active UberEats orders but lets me know he’s going to pick up mine and get it to me — huge props to the driver, at least Uber’s “independent contractors” are sane and helpful.
Finally, at 7:59PM, I get the best possible call. It’s the driver, letting me know he’s arrived. I go down and grab my food, shovel some of it down my gullet, then open the app back up to connect with UberEats’ support since, well, five phone calls and lukewarm food showing up 2 1/2 hours later isn’t quite what I expected when I decided I wanted some Thai food, seven BoJack Horseman episodes ago.
I go through the prompt and explain the issue and… get met with what seems like a canned response that can be tl;dr’d best as “Sorry that happened, now go away.” — More specifically, the immediate response was (paraphrased) “We’re sorry you had a poor experience. We’ll work with the merchant to improve in the future. We cannot offer any price adjustments or compensation for this. There is no other team to escalate this issue to.”
Needless to say, I’m not particularly thrilled with UberEats today. While technically they did do what they said they’d do and made food from a restaurant show up at my doorstep, the convolution, issues, and problems involved serve to highlight exactly how to not handle customer issues.
Turning Stumbles into Satisfaction
Now that we’ve read an account of some top-notch customer disservice, what could have been done to make this problem, at best, a less painful issue?
To start, let’s address the technical side of things. If you’re building out a platform that has direct client interactions, admit when things are broken, and display it prominently. Being open about content looking weird, or some components not working correctly due to a known issue already offers a significantly better experience than parts of your client-interactable application just being broken for unknown reasons leaving the client concerned and very confused.
Now assuming your application is broken in a way that causes an issue, the next way to help the situation is make support available to your frontline. If your platform has a category of workers who interact directly with clients but aren’t support agents themselves, make sure they have consistent, easy access to backend support teams. When things go wrong, nothing is more frustrating for a customer than having to get a “Yep something’s broke, no clue why, and I can’t talk to anyone who can tell me what’s up either” from the person functioning, in that moment, as the face of your platform.
Lastly, even if your frontline employees can say what’s wrong, if the issue is something that’s deeply impacting the expected experience when using the product, do what you can to make the situation right for the customer. Every business is “sorry for the unpleasant experience” but a quickly sloshed together “Sorry, anyway moving on” type response is hollow and very underwhelming. If you want customers to 1. continue their business with your product, and 2. promote/recommend/at least not actively argue against using your product, you need to make sure they leave from a situation where issues happen with at least some feeling of “The company wants to do right for me.” This doesn’t mean you have to give away the farm, but whether it be a breakdown of why things broke, some amount of future credit for your product/service, an actual refund, etc., you should do what is viable and reasonable to resolve the issue — not only in situations of a full service failure (e.g., entirely not delivering the food, to use my above example), but also in situations where the provided experience is drastically different from how your platform should be experienced (e.g. two and a half hours, and five phone calls, before food arrives, instead of one hour and maybe one phone call).