Covered on their blog here:

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.