How GrubHub.com confirms with restaurants that they placed a delivery order
grubhub.com
grubhub.com
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.
I think the most amusing part of this whole thing is that there's no way any user actually believes there are ~100 discrete steps to the order placement process, despite the high "progress resolution" of the progress bar.
Twenty seven seconds is how long it took one of my customers to a) click from my site to Paypal (T = 0), b) authenticate with Paypal, c) authorize the transaction, d) return to my site, and e) email me asking me why they hadn't gotten their Registration Key yet despite the fact that promised it would be delivered "instantly". (T = 27)
They eventually got their Registration Key in 33 seconds (well, that was how long it took for them to click the link in it), and a few minutes later got it resent by me, along with an apology for taking so long. (The cause was the customer winning the race back to my website with Paypal's IPN trailing behind. It happens -- their bank took a few seconds longer to authorize it than usual, it fell into a verification queue, gremlins ate an HTTP packet, whatever.)
Now, I have a certain amount of luxury in dealing with customers with high expectations as to my availability, because I clear $30 on every order and if 10% of them want to chat, well, I can deal with getting paid $300 per email I write. However, if I were running a business which processed thousands of transactions a day, and I made about a buck an order prior to paying my CS staff, I would put a significant amount of effort into making sure that you didn't become an emergency for my CS team just because you had to wait twenty-seven seconds.
That, obviously, is quite worrying. So you investigate as to why they haven't gotten a response by their fourth email, and discover that all were sent within 7 minutes of each other in the dead of night.
Yes, some customers are just too much fun.
Edit: And single data points are not convincing. How many users have emailed you in 27 seconds (or something similar)? If it was just the one, I'm pretty sure it wouldn't break your business whatever your margins.
It adds complexity but provides no value.
If you call a cab, you also accept "be there in 10 minutes", even though it's not confirmed, not "Right, tell you what, I'm gonna push this button on my radio, which closes an electrical curcuit connected to a big radio, and announce your request to our fleet of cars. Now, provided that there's no interference, and that the nearest car isn't in a garage or a tunnel or something, and if the driver isn't fighting with his wife on his cellphone, or in a place getting a coffee, he'll hear the message, and radio back confirmation. He'll then drive to your address, where, bar mechanical failure of perhaps the brakes or the pressurized oil system, he will arrive in 10 minutes. Have a good day."
> I think the most amusing part of this whole thing is that there's no way any user actually believes there are ~100 discrete steps to the order placement process, despite the high "progress resolution" of the progress bar.
Progress is often temporal, and time has infinite resolution. There may no be 4*60 distinct steps to the process of steeping a cup of tea, but we still accept the turn of the second-hand as a measure of progress.
That's not really a fair comparison to "We'll confirm that the restaurant got your order and email you".
"If you call a cab, you also accept "be there in 10 minutes", even though it's not confirmed" is, however, a fair comparison, IMHO.