Co-founder of https://flipdish.com here (Unicorn whitelabel online ordering provider).
We felt very similar to the author in 2015 — utterly frustrated needing to enter email address, be asked for a DOB!!, create a password etc before being allowed place an order. We set out to design an app that required a minimum number of taps from opening app to placing an order. By using geo-location, using a phone number for authentication instead of email (delivery drivers are going to want a phone number), having sensible defaults (like presuming you want to order for ASAP unless you say otherwise), we build an app where people can open it for the first time, register, order and pay in under 20s.
We initially automatically logged people in silently on Android by detecting their phone number, sending a verification SMS and intercepting it in the app. This was viewed as more spooky than good UX, so we had to reverse course a little and add another manual step in that case. But other little UX niceties remained, like extrapolating the customer’s name from the name of their iPhone (chances are you phone us called “[first name]’s iPhone”) to save them typing it in.
I think it would be quite difficult to manage a production system that lets people pay with cash but not log in, as it would be so easy for a single script kiddy to take all your restaurants offline by placing fake orders over and over.
You would be amazed (or maybe you wouldn’t) at how little business owners think about UX. We get so many requests to require a DOB before being allowed placing an order so they can send birthday messages to customers.
Co-founder of https://topchef.de here (bootstrapped whitelabel online ordering provider, focusing on the German market). We felt the same. It's truly amazing how bad the UX of many competitor apps is and how little business owners think about it.
Sometimes it's an uphill battle to even explain to business owners why being on takeaway.com is stupidly expensive - after all, at the end of the month they _receive_ money from them, instead of paying a monthly subscription fee.
You nailed it — the primary value of these marketplaces is the consumer facing ordering technology, not the fact that it’s a marketplace.
This is an excerpt of a recent article that explains my thinking on it a bit better.
There is little (or even negative) value for restaurants from marketplaces in this industry. In many industries marketplaces like this make sense.
Typically, they make sense when discovery is very important, when there is little repeat usage of the discovered service or when there are multiple disparate services involved.
Travel is a good example here: it makes good sense for a consumer to use a marketplace to discover a hotel and a car rental company when they book a trip to a city they’ve never been to and likely won’t go to again for a few years.
And it makes sense for a hotel to list on a marketplace as it’s impractical for them to market directly to consumers from around the world in the off chance that they will visit the city the hotel is in.
There are very different dynamics at play in hospitality. People tend to order from two or three takeaways in rotation as opposed to discovering a new one each time they order.
They also tend to order from one located physically close to them, and they usually can be efficiently marketed to by this takeaway directly, both via offline methods such as walking past the store each day, getting flyers in the door, and online via search and brand marketing.
It is also rare that a consumer needs to make multiple purchases from separate services to order their food (they don’t, for example, usually need to order a taxi to collect the food after ordering it).
The value that restaurants get from joining a marketplace is the consumer-facing online ordering technology that they get access to, but not from the fact that they are getting it from a marketplace.
There is a lot of negative value for a restaurant in joining a marketplace (i.e., it causes them harm) as they end up sending their existing customer base away to a 3rd party who is incentivised to move the consumers away from that restaurant and over to one who will pay the marketplace more for the orders.
Disclaimer: I’m cofounder of flipdish.com that provides direct ordering tech to restaurants.
You nailed it — the primary value of these marketplaces is the consumer facing ordering technology, not the fact that it’s a marketplace.
You’re mistaken. The primary value is the logistics of dealing with drivers. A restaurant supplying its own drivers will always be at a disadvantage to Door Dash/Uber Eats etc because they can never utilize their drivers as efficiently as the big delivery companies. During peak hours, a restaurant may receive a surge of orders that they do not have the drivers to handle. During off-peak hours, on the other hand, they may not have any orders at all so any drivers they employ will be sitting idle, on call.
The marketplace for restaurants that everyone talks about is not the hard one to build. The hard one is the marketplace for drivers. If I’m a restaurant then there’s very little value to me in an app that takes orders but does not provide drivers.
There’s definitely value in a shared driver pool but it does not need to come hand in hand with a consumer facing marketplace. Doordash offer access to their driver pool for orders placed through any channel (Doordash Drive), Uber offers on-demand drivers in a similar way. Companies like Stuart solely offer a B2B last mile delivery service with their pool of drivers.
This isn’t new either — DPD, UPS, DHL have all offered a shared delivery network (for retail) without anyone expecting that anything that is delivered by DHL must be ordered via DHL.com.
The hole in this theory is that, unlike general delivery drivers, almost every restaurant's peak hours are at the same time - meaning that there's no reason to think that the app/website would have fewer idle drivers than the restaurants.
The primary value is the logistics of dealing with governments in order to abuse workers with impunity. If a restaurant tried to claim that their drivers were independent contractors that don't need to be paid between orders, they'd be laughed at. Put a massively funded, massively lobbying intermediary between the driver and the restaurant, and it becomes fine.
edit: I'm sure there's a term for this - labor-laundering?
My father drives for one of the big delivery apps. He does not consider it an abuse of his labour. The driver app offers him 4 hour shifts which he takes or rejects as he sees fit.
During his shifts he's essentially busy driving the entire time. Because the app has a big pool of drivers it is far better equipped to accommodate the shifting demand among the restaurants. As it turns out, not every restaurant does equally well on every day's peak hours. The delivery app acts as a load balancer by distributing drivers among restaurants according to demand.
My dad used to drive a limousine for a small, local business owner. He was verbally abused and often forced to drive clients to the airport at 4am one day and other clients to a rock concert at 3pm the next day. The owner also regularly stole his tips. He VASTLY prefers delivering food. He also has no interest in picking up a 9-5 job because he's older and he simply does not want to work more than 24-28 hours per week.
It seems like payment/e-commerce companies in general are shifting towards offering "express checkout" experiences nowadays - Shopify, Paypal, Amazon Pay, are a couple prominent examples. My former employer Affirm was also very concerned about owning the checkout experience/acquiring users up-funnel. It's a smart move, really.
We always hear about how payment networks manage to nickel and dime merchants to produce lots of revenue, so it was probably only a matter of time before other players in the process wanted a piece of that action.
We are facing the issue of SMS not getting delivered and have implemented failovers (Messagebird, Nexmo, Twilio) when we detect delivery problems. However we have a problem that frequently we get sent positive delivery receipts despite the SMS not being delivered. This makes it hard to know if we should fail over.
Has anyone good solutions fur this?
Positive delivery receipts from an SMS aggregator have approximately zero diagnostic value.
If you want them to mean something, you need to have a direct connection with the carrier of your user, and you have to know that the carrier or their network doesn't just fake positive delivery receipts at some point in the system to make numbers look good. With an aggregator between you and the carrier, you have no way of knowing when the delivery path changed and the intermediary faked a delivery report.
The absence of a positive delivery receipt doesn't really mean anything either. Negative delivery reports have some information content though.
My context is sending verification codes though; receiving a code back from a user is a much better measure of successful delivery to the user than a delivery receipt. If you're sending news or something where there's no measurable direct action taken as a result of the message, I guess a delivery receipt is better than nothing, maybe?
Realtime measurement and thompson sampling or multi-armed bandit with as many credible providers as you can manage is the best way forward, don't send retries through the same provider either.
I'm surprised you'd frequently get false positives. What regions were you sending to?
They were essentially unheard of with the UK networks and very rare with European networks. It was only Middle East and African networks that were troublesome, but they represented a tiny fraction of our traffic. Even then, false positives were rare compared to messages just not getting delivered.
Super interested in this as well. I switched from Messagebird to Twilio after giving Nexmo a try and it's a lot better now but still get false positives.
For me personally it was Messagebird. Two failed demos because of this and the response from them where non-existent. I was even contacted by one of their sales people after I wrote my last "angry I'm leaving" email asking me if I was interested in using their services.
Yes, similar position with Messagebird. Lack of transparency in their reporting/insights vs Twiliio. That said, our Twilio pricing is 2-3x Messagebird.
If its something requested, the user can always re-request it. If it not something requested like news, use two different providers to send 2 messages. One the actual content, and then a minute later, a different smaller message saying "This message brought to you buy MyCompany. Please text back STOP to stop messages or AGAIN to get the latest alert again." Some end users might get better delivery results with a specific texting service, so it might be useful to set service affinities on a user specific basis.
You must be kidding. This never happened to me so far, but if it did, I would be so unhappy with YourCompany that probably would never buy anything from you again
You understand that OP is requesting a solution for a practically unfixable issue. Unless you a have relationship with the carrier itself. A provider sends you a success, but it was actually a failure. Imagine a DB sending Commit-OK, but data was never written. You probably wouldn’t buy very much from a company that uses that kind of DB as well, since it loses your orders.
Once again, if you are receiving texts that must mean you opted into them. User is expecting them and it’s different from a user receiving two texts never having signed up for them.
I do believe this technique uses some out of the box thinking and mostly DOES solve OPs problem.
We initially automatically logged people in silently on Android by detecting their phone number, sending a verification SMS and intercepting it in the app. This was viewed as more spooky than good UX, so we had to reverse course a little and add another manual step in that case. But other little UX niceties remained, like extrapolating the customer’s name from the name of their iPhone (chances are you phone us called “[first name]’s iPhone”) to save them typing it in.
I think it would be quite difficult to manage a production system that lets people pay with cash but not log in, as it would be so easy for a single script kiddy to take all your restaurants offline by placing fake orders over and over.
You would be amazed (or maybe you wouldn’t) at how little business owners think about UX. We get so many requests to require a DOB before being allowed placing an order so they can send birthday messages to customers.
A nice summary of the state of affairs by UK comedian Michael McIntyre https://youtu.be/O5FeZti1cjs