How GrubHub.com confirms with restaurants that they placed a delivery order(grubhub.com)
grubhub.com
How GrubHub.com confirms with restaurants that they placed a delivery order
https://www.grubhub.com/img/orderStatusBar.gif
23 comments
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.
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.
This is directionally pretty accurate based on my understandng. What's amazing is that Mike Evans, the tech co-founder, built it all himself back in 2005-2006. I've sent him a link to this thread to see if he wants to chime in.
Thanks, that was interesting and thoughtful, and I agree in general. However, in this case, I don't think it would be so bad to say something like, "Your order is in our system. We'll confirm that the restaurant got it correctly and email you in a couple minutes."
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.
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.
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.
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.
My favorite are customers that email in a problem, then email in again, then email in again... Then email in that "THEY'VE EMAILED THREE TIMES AND HAVEN'T GOTTEN A RESPONSE!".
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.
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.
To be fair, you shouldn't have promised instant delivery. And saying "a couple minutes" (or even "a few") is a lot fuzzier. The kind of person who calls in after 180 seconds because a few minutes have passed in the kind of person who is going to call you anyway because s/he's just neurotic.
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.
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.
> I don't think it would be so bad to say something like, "Your order is in our system. We'll confirm that the restaurant got it correctly and email you in a couple minutes."
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.
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.
>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."
That's not really a fair comparison to "We'll confirm that the restaurant got your order and email you".
That's not really a fair comparison to "We'll confirm that the restaurant got your order and email you".
How long are you supposed to wait for the email? Why not just call the restaurant and cut the email-sending middleman out of the loop? It costs the same and takes less of your time.
It doesn't take less of my time, because I can do other things while I wait for the confirmation. In fact, inducing me to sit and stare at a fake progress bar probably takes more of my time. And in any case, it saves me having to repeat my order to someone who doesn't speak great English, etc.
No, it's not, I was going for a bit of satire, I'm sorry.
"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.
"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.
Heh, maybe I'm neurotic, but I actually hate it when they do that. I'd much rather they tell me something like "We can probably get you a car in about ten minutes, and we'll call to confirm or update that in two," if it were more reliable.
I agree completely. I noticed a while back that the order bar was a fake -- I especially love that it slows down and jerks around a bit for authenticity -- but what a great way to stave off hundreds of customer calls saying "I didn't get the confirmation email". This GIF tells them to wait a while, because real-world processes take time, without actually forcing them to sit in a browser with a spinning progress bar.
"This call may be monitored to check for awesomeness" always makes me smile. It's the little things...
I wonder if they check for anything else if it counts as a violation of ones privacy.
The link is pointing to an image. This is the actual link
https://www.grubhub.com/
https://www.grubhub.com/
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.
Oh thanks.. now I've just placed an order I didn't want. Don't click. It orders food.
Well whaddyaknow, I have a guy at my door with a vat of falafel. It's quick; I'll give it that.