Uber Eats' Swapped Order Problem

Things may be a bit more complicated than this simplistic blog would suggest.

Every restaurant seems to have its own receipt format. Some don't have a name field and uber puts it in the "phone number" field (eg instead of "Name: Arianna" you see "Phone: ARI-IANN-A".

Uber has certain information they need to give the restaurant (its different for each one). The receipt has certain fields (these don't match up all the time). It isn't a simple matter of an identifier that can be fixed.

"It's so fixable! Here are 150 lines of code that solve the problem! How come it exists?"

If only everything could be fixed by a pull request.

A better set of characters and ensuring that two order numbers in the same restaurant are very different would be a much better solution.

The post suggests using all the letters in the alphabet, but then you run into the problem where once in a while someone will wind up with order #F*CK and complain. So you have to add logic to avoid naughty words, but then you get #FOU in France and realize you need to localize your naughty word list.

Or, you could stick with numerals, which everyone understands and which everyone is familiar with (and which are obviously order numbers!). Extending to hex is already a bit of a stretch, but at least there's not that many naughty words using only hex digits.

Not really.

For swapping to occur, two orders have to be sitting there at the same time with the same last 3 digits and the wrong one has to be picked. So thats one in 2x4096. Every time there is only one order sitting there, the propability drops to 0%. And once there are more orders sitting there, it increases beyond one in 2x4096.

Where the total ends up is heavily dependent on how often multiple orders are sitting there, waiting. It's hard to quantify, but qualitatively we can certainly conclude that the more busy a place and time is, the more likely this is to occur.

With 0 insight into what drove Uber Eats design for tickets my wild speculation would be something to do with receipt printer standards (e.g. width/legibility), information density, and restaurant asks - assuming any were polled on what would help them.

So it's possible what they arrived at is best or near-best, though imperfect, for their situation. That is, granted, a charitable conclusion but it's reasonable to assume no one there set out to make a bad product.

But it's also very possible they got to their first workable state and decided the juice/squeeze ratio of any investment in improvements was nil. "Good enough" strikes in a lot of companies all the time.

And, frankly, I agree with other commenters that the swap problem has more to do with imperfections in humans that can't be overcome with better receipts.

* Integrating with restaurant point-of-sale systems was an ongoing issue. There is a wide variety of capabilities and APIs. Often with varying degrees of reliability and quality. There's no baseline standard for receipt printers. Regardless a significant percentage of restaurants just do things by hand. It seems to me like the author of this article came to these conclusions with a restaurant sample size of one.

* The issue of swapped orders is pretty much exclusively a human one. There's a lot of work ongoing to mitigate this, but receipt code collision is absolutely not related. I would also guess that when an order is generated its code is checked with other ongoing orders.

* I like his suggestions to make codes easier to pronounce/hear, but again this is not a common point of failure. He is correct though that when you're operating at Uber's scale, extreme corner case situations happen thousands of times per day.

(Although including the word "cock" on the word list may not have been the best idea, given how much it opens up the scope for humorous or offensive word sequences - but this was almost 30 years ago).

[1] https://www.rfc-editor.org/rfc/rfc1751

[2] https://www.rfc-editor.org/rfc/rfc1760

This encodes region-specific assumptions as part of the code logic.

This might even differ due to dialects/regional differences in pronouncation and will fail at latest when it comes to completely different languages (for which one doesn't even have to leave the US, given e.g. the huge Spanish speaking community).

I don't know whether Uber Eats is available in other countries than the US, but this would bite them in the ass as soon as they're expanding internationally.

My most-frequent swapped-order experience is from couriers running for multiple dispatchers. Rather than getting my order from DoorDash for Jake A, I got one from UberEats which was for Jack H…

My name gets read incorrectly as “Jack” all the time, for whatever reason, and I imagine something like that happened with that one.

Until/unless it’s economically viable for couriers to run one order at a time, for one dispatcher at a time, these kind of swaps are going to happen.

Also, add redundancy so that if something is read out wrong then there is guaranteed to be no match. Error-correcting codes have been around for centuries (well, almost). Simplest way to do this is to add a fourth digit which acts as a checksum. Nobody needs to know this, but it will make the legal combinations very few in the space of total combinations, so if something is read out wrong you'll notice right away.

In my experience working with platforms for restaurants, any interaction with customer service could take 10 minutes to 45 minutes depending on the problem—security, separation of departments/concerns, investigation of details, approval, resolution.

Is that what it means? I read it as "the courier will walk or use a bike" eg. not a car. Not that I see how that would be relevant for the reciept either.