What do you think about guest checkout in a web app for pre-order food for a certain time in a restaurant?

Question

Usability guidelines about e-commerce say that in an e-commerce platform, guest checkout is a must. Not providing this alienates any customer who just wants to get in and out.

What would you do in this situation? Do you force users to register before placing an order or do you ask for registration after the order has been placed? And what if the user closes the browser on the thank you page (likely the page where you ask for registration)?

Personally, I'd create an account during the order process, when users have to fill in data about payment and arrival time in restaurant (in this case). So, users fill in forms about their data (email, password, mobile phone, name and surname) and then they place the order. In this way the registration process is embedded in the order process and is not in another page which drives off the user from his goal.

But, there's a problem. What if the email provided is not valid? How will the user receive important communications? Asking them to register before the checkout forces the user to check his email to confirm the registration and then proceed to checkout.

I need your feedback on this scenario, but I think asking for registration after the order has been placed could lead to the problems I describe above.

UPDATE

After the order has been placed this is sent to the restaurant that has to prepare meals for that time. I want to avoid a order's confirmation link sent to the user's email (because the user before placing the order checks it, so there already is a confirmation of my order) and I don't want to block the user's order (especially because the order is for a precise time) as long as they do not confirm their registration.

Answer 1

The primary risk, I think, with a guest checkout for a restaurant, is the "anonymous" person reserving / buying food but not showing (and the company both losing the sale and also the stock).

Some (many?) people do not trust other people/companies with their personal information, or do not want to sign up for email advertisements. Forcing them to sign up will result in bounces.

Required information to collect is a name, some form of contact info, and payment information. Tell them that the email address is used one time to confirm they are real, and will not be retained for anything else.

You can work out a phone-validation workflow if the user gives a phone instead, the restaurant calls the number to verbally confirm the order (again, confirming that they are real), then marks it as confirmed in the system. Include in your TOC with stores that they will not save phone numbers after an order is either canceled or completed if that is possible. Or, at least that they will never use that information for promotional purposes or sell it. Be vicious with restaurants that break this clause.

You'll probably want to just require an email address for #1 as #2 has many pitfalls.

After that, no other information is needed. Everyone understands the need to give a phone or email, and it can be clear in your purchase page that if they give incorrect info and the pre-order can't be confirmed, that the order will be canceled. This is CYA for you/the restaurants when the person comes yelling that their order wasn't processed.

As to when to ask for registration, make it a passively available option throughout the experience, and offer them the option to provide email and password during the point they are entering payment information (along with the choice whether to save or discard their payment information).

Update:

For guest purchases, you need the customer to make a response to a confirmation verification action. You want them to either click a link in an email, or answer the phone when the end restaurant calls. Paragraphs 3 and 4 think on a few ways to go about supporting that.

Update 2:

To clarify, the confirmation email or call is not to confirm the order, but to confirm the user is real. I've updated above to be less ambiguous about that.

You really have two choices if you're offering a guest ordering system - confirm they exist or don't. If the user doesn't want to have to confirm who they are with a validation email, they can register.

Answer 2

I would imagine that for guest checkout, you will want to collect the payment at the point of checkout, so as to mitigate the risk of the customer not showing up to collect? So, you'll only accept payment by credit and debit cards for guest checkouts. You can entice your customer to create an online account by enabling more payment options such as cash-on-delivery for registered customers.

Given that payment is collected up-front, the customer will likely ensure their contact information is valid, if you provide good reasons on why contact information are collected. For example, "Your food may be ready for collection within five minutes of your requested time. If you provide a mobile phone number, we can SMS you once your food is ready for collection."

I suspect that a customer may choose to checkout as a guest because he doesn't have too much trust in your business yet. Having to verify that contact information without being provided with a valid reason ("We want to email you with new marketing deals" is not a valid reason) will only further erode that trust.

Answer 3

Keeping the "friction" low is vital.

Amazon worked out early on that every additional click in their check-out process cost them something close to 50% of their sales - hence their development of a very smooth sales process.

Here in New Zealand all of the major pizza delivery franchises chains have a similar approach:

User registration is offered at the end of the process.

Almost everything needed for user registration has already been entered - including delivery address and confirmation phone number. The only things left are username and password - making registration also low friction.

Try them yourself:

• Hells Pizza (www.hell.co.nz)
• Pizza Hut (www.0800838383.co.nz)
• Dominos Pizza (www.dominospizza.co.nz)

In terms of avoiding friction, this works well - when someone goes to their site, the users's goal isn't "register a username and password", it's "Order Dinner". Deferring actual registration until after ordering dinner is complete allows the user to concentrate on their immediate goal until it is complete. In other words, inviting them to create a user account while they wait for delivery catches the user when they're idle and have nothing else to do.