5 ms·

How GrubHub.com confirms with restaurants that they placed a delivery order

70 points by enki 17y ago

Tichy 17y ago
So they are faking it? I don't completely understand what this is about? Who is GrubHub?
- leej 17y ago
  It's online food delivery site. It gets orders from customers, routes back to the restaurant and gets a cut from the process. Basically it's a middleman.
lexx12 17y ago
OMG, can't believe their progress bar is just a bling-bling.
- deleted 17y ago
  [deleted]
petercooper 17y ago
Oh thanks.. now I've just placed an order I didn't want. Don't click. It orders food.
- petercooper 17y ago
  Well whaddyaknow, I have a guy at my door with a vat of falafel. It's quick; I'll give it that.
sbhat7 17y ago
The link is pointing to an image. This is the actual link https://www.grubhub.com/ https://www.grubhub.com/
- dylanz 17y ago
  Not sure why you got down voted. I was a bit confused why when I clicked the title of the post, I was looking at an animated gif. I actually watched the entire animation waiting for something to happen.
patio11 17y ago
Covered on their blog here: http://74.125.153.132/search?q=cache:ZKDGeJv_cpoJ:blog.grubhub.com/inside-the-order-trail-at-grubhubcom+grubhub+progress+bar&cd=1&hl=en&ct=clnk http://74.125.153.132/search?q=cache:ZKDGeJv_cpoJ:blog.grubh... Actual process: 1) Customer hits submit. 2) Order gets added to outgoing queue. (It will be faxed.) (I don't know that they do it with a queue, but that is the obvious way to do it.) 3) Customer sees next page in flow, including progress bar. 4) Possibly before or after #3, order gets faxed to restaurant. 5) A computer system telephones the restaurant and asks "Did you get that?" If yes, the order is updated with a timestamp, and a confirmation email is sent to the customer including the timestamp of when the order was manually confirmed by the restaurunt. If not, the customer service team gets involved. So that's what we know. Here's my conjecture: there was a business desire to tell customers their orders were Good To Go but this could not be done conveniently within the standard expectation of the HTTP cycle (i.e. really freaking fast). Since if you call a restaurant yourself you get what most customers consider 100% assurance that the order is Good To Go (even though, hypothetically, the kitchen could still throw a FatalOutOfCheeseError), doing the 100% literally accurate thing and telling the customer "Your order has been put on the fax queue. It will probably be confirmed within a minute or two." makes you look less than competitive with the most competitive option, which is doing the phone call yourself, and will confuse users who do not understand what status their order is in. They're going to do things like e.g. call to check, which duplicate effort and cause problems for both GrubHub and the restaraunt. Still hypothesizing: some bright person said "Look, everyone knows it sometimes takes a minute to get an email when you ask for it on a website. The overwhelming majority of our orders get successfully confirmed by the restaurant within 2 minutes of hitting the submit button. How about we tell them its confirmed, meaning that it is on our outgoing queue? We're positive of that because we can guarantee it in the HTTP request/response timeframe ourselves. After it goes on the queue, it will get delivered to a human at the restaurant -- either the employee picks up the phone and confirms it, and the customer gets an email saying so in the window they expect, or our CS call them and manually place the order. Is it possible that for reasons beyond our control that the order could not be placed even with one of our humans on the line? Yes. But that is the same as the FatalOutOfCheeseException. In that case, we'll call them back and apologize, tell them this essentially never happens (which is true), and possibly offer to buy them dinner if they're upset." I am about to say something heretical: I do not believe that telling users untrue things is necessarily a bad thing. For example: most of us understand that a when our systems say "File deleted!" it really means "File looks like it is deleted to you!" I don't think that is a bad thing -- it abstracts away implementation details which most of our users wouldn't understand and can't be bothered with. Imagine what would happen if we said, e.g., "We have deallocated the space for the file and it may be deleted at a nondeterministic time in the future depending on your particular disk usage patterns. Confused? Here's the number for support." Let he who accurately and completely explains to a user what deleting a $RECORD_APPROPRIATE_TO_YOUR_APP actually does cast the first stone.
maxniederhofer 17y ago
"This call may be monitored to check for awesomeness" always makes me smile. It's the little things...
- pbhjpbhj 17y ago
  I wonder if they check for anything else if it counts as a violation of ones privacy.

70 points by enki 17y ago

Tichy 17y ago

So they are faking it? I don't completely understand what this is about? Who is GrubHub?

leej 17y ago
It's online food delivery site. It gets orders from customers, routes back to the restaurant and gets a cut from the process. Basically it's a middleman.

lexx12 17y ago

OMG, can't believe their progress bar is just a bling-bling.

deleted 17y ago
[deleted]

petercooper 17y ago

Oh thanks.. now I've just placed an order I didn't want. Don't click. It orders food.

petercooper 17y ago
Well whaddyaknow, I have a guy at my door with a vat of falafel. It's quick; I'll give it that.

sbhat7 17y ago

The link is pointing to an image. This is the actual link https://www.grubhub.com/ https://www.grubhub.com/

dylanz 17y ago
Not sure why you got down voted. I was a bit confused why when I clicked the title of the post, I was looking at an animated gif. I actually watched the entire animation waiting for something to happen.

patio11 17y ago

Covered on their blog here: http://74.125.153.132/search?q=cache:ZKDGeJv_cpoJ:blog.grubhub.com/inside-the-order-trail-at-grubhubcom+grubhub+progress+bar&cd=1&hl=en&ct=clnk http://74.125.153.132/search?q=cache:ZKDGeJv_cpoJ:blog.grubh... Actual process: 1) Customer hits submit. 2) Order gets added to outgoing queue. (It will be faxed.) (I don't know that they do it with a queue, but that is the obvious way to do it.) 3) Customer sees next page in flow, including progress bar. 4) Possibly before or after #3, order gets faxed to restaurant. 5) A computer system telephones the restaurant and asks "Did you get that?" If yes, the order is updated with a timestamp, and a confirmation email is sent to the customer including the timestamp of when the order was manually confirmed by the restaurunt. If not, the customer service team gets involved. So that's what we know. Here's my conjecture: there was a business desire to tell customers their orders were Good To Go but this could not be done conveniently within the standard expectation of the HTTP cycle (i.e. really freaking fast). Since if you call a restaurant yourself you get what most customers consider 100% assurance that the order is Good To Go (even though, hypothetically, the kitchen could still throw a FatalOutOfCheeseError), doing the 100% literally accurate thing and telling the customer "Your order has been put on the fax queue. It will probably be confirmed within a minute or two." makes you look less than competitive with the most competitive option, which is doing the phone call yourself, and will confuse users who do not understand what status their order is in. They're going to do things like e.g. call to check, which duplicate effort and cause problems for both GrubHub and the restaraunt. Still hypothesizing: some bright person said "Look, everyone knows it sometimes takes a minute to get an email when you ask for it on a website. The overwhelming majority of our orders get successfully confirmed by the restaurant within 2 minutes of hitting the submit button. How about we tell them its confirmed, meaning that it is on our outgoing queue? We're positive of that because we can guarantee it in the HTTP request/response timeframe ourselves. After it goes on the queue, it will get delivered to a human at the restaurant -- either the employee picks up the phone and confirms it, and the customer gets an email saying so in the window they expect, or our CS call them and manually place the order. Is it possible that for reasons beyond our control that the order could not be placed even with one of our humans on the line? Yes. But that is the same as the FatalOutOfCheeseException. In that case, we'll call them back and apologize, tell them this essentially never happens (which is true), and possibly offer to buy them dinner if they're upset." I am about to say something heretical: I do not believe that telling users untrue things is necessarily a bad thing. For example: most of us understand that a when our systems say "File deleted!" it really means "File looks like it is deleted to you!" I don't think that is a bad thing -- it abstracts away implementation details which most of our users wouldn't understand and can't be bothered with. Imagine what would happen if we said, e.g., "We have deallocated the space for the file and it may be deleted at a nondeterministic time in the future depending on your particular disk usage patterns. Confused? Here's the number for support." Let he who accurately and completely explains to a user what deleting a $RECORD_APPROPRIATE_TO_YOUR_APP actually does cast the first stone.

maxniederhofer 17y ago

"This call may be monitored to check for awesomeness" always makes me smile. It's the little things...

pbhjpbhj 17y ago
I wonder if they check for anything else if it counts as a violation of ones privacy.