Well... they can wake up and smell the 90s by spending the cash to have a website. I'll bet that one month of paying grubdash costs more than getting a website up.
Or just complain, like most of the places around me.
Even if they have a nice, modern website, there's still credit card handling. Many customers will be put off by having to enter their CC details into yet another website. Things like Stripe alleviate this to some degree, but it's still a hurdle.
And unfortunately people trust mobile apps more than they do websites, so unless you expect every local pizza shop to have its own mobile app (and expect customers to have enough brand loyalty to install it), that's not going to change.
This is why I use these services. I’d prefer to give my CC info to a single company and not trust it to who knows how many fly by night CC processing companies in use by individual restaurants
Funny thing is, if the website/app is crap, as a someone ordering, you will still want to use the food delivery service infrastructure from the app anyways because their system is likely to be better.
More than likely to be better IMO--if it's not better then the food delivery app is going to be out-competed by some other one that is better. Providing the app and its infrastructure is the app company's core business. It's not the restaurant's core business. And network effects mean the app has a strong incentive to be a centralized platform and to commoditize its complements, which are the individual restaurants.
what ought to happen is to have the ordering/delivery tranaction be under some open protocol (i.e., each restaurant runs their own ordering service/api that talks on an open protocol, pehaps even just delegate this to a B2B SaaS for a monthly cost, like a telephone line!).
Then you can allow open competition between different delivery platforms, which effectively makes ordering and delivery more commoditized. This will allow restaurants to run more efficiently - they only need to be good at their core competency of making the best food, at the lowest possible price. The delivery will cost the minimum (as each app that compete on price of delivery cost will get more customers).
The delivery part is where all the overhead occurs. Developers think these services are trivial and making a killing on the markup because they can imagine writing the app and backend themselves. That’s not the hard part!
The hard part is recruiting, training, and managing the drivers. This requires you to hire lots of employees to communicate with the drivers and support them in real time during peak periods (around supper time and weekend evenings).
You can’t automate this stuff away because the drivers are dealing with all kinds of complex, real-world problems. Stuff like addresses of houses that don’t exist, drivers getting lost trying to find apartment suites or even restaurants within a complicated building, aggressive dogs or angry/drunk people, people denying they ordered anything and their contact numbers pointing to a different city...
The Google model of seeing customer support as a problem and automating it into nonexistence doesn’t work here. You’re dealing with hot food that’s cooling fast and hungry people who can’t wait very long and drivers who need to complete a bunch of deliveries in a night in order to make it worth their time.
> i.e., each restaurant runs their own ordering service/api that talks on an open protocol
> which effectively makes ordering and delivery more commoditized.
It would be great, but I'm not holding my breath for this to happen anytime soon, though maybe restaurants will be more amenable to something like this now because of the current investor/debt funded platforms.
And unfortunately people trust mobile apps more than they do websites, so unless you expect every local pizza shop to have its own mobile app (and expect customers to have enough brand loyalty to install it), that's not going to change.