This is the topic that most readers should stop at, and the one that produces almost all the value in this course. Your customer already has an extremely capable app for your restaurant: the browser on their phone, plus the map they use to find you and the wallet they already keep their cards in. None of it needs installing, all of it reaches a hundred percent of your customers, and most restaurants are using about a third of what it offers.
⚡ Your site, on a phone, in three seconds
Do this now: open your own site on your phone, on mobile data rather than the restaurant's wifi, and count the seconds until you can read the menu. Most independent restaurant sites take between eight and twenty. That gap is the single biggest digital problem most restaurants have, and it is invisible from a laptop in an office.
What makes it slow is almost always the same four things, in this order: enormous photographs uploaded straight from a camera, a menu that is a PDF — which downloads, opens in another app and cannot be read without pinching — a slideshow on the front page, and a booking or ordering widget that loads before the content does.
The fixes are equally boring. Resize the photographs. Put the menu on the page as ordinary text, which loads instantly, can be read one-handed and — not incidentally — is the only version a search engine can read, so it is also how people find you when they search for a dish. Kill the slideshow. And make sure the four things a phone visitor actually wants are above the fold: the menu, the hours, the address with a tap-to-navigate link, and the phone number as a tap-to-call button.
That last list is worth taking literally. Nobody arrives at a restaurant site to browse. They want one of those four things, they want it in one tap, and every design decision that delays them is costing you a customer who is standing on a street corner deciding where to eat.
🗺️ The listing you do not own but do control
For most restaurants the map listing gets more traffic than the website — often several times more. It is, in practice, the app your customers use for your restaurant, and it is free.
What matters on it is unglamorous and rarely done: correct hours including holidays, a phone number that works, the menu link, photographs that look like the actual room rather than stock images, and the order or book buttons pointed at your channel rather than at whichever platform bid for them. That last one is worth a few minutes: those buttons default to whatever integration exists, and pointing them at your own booking page moves customers off a commission channel, which is exactly the argument the reservations course made about who owns the booking.
The other half of that listing is the reviews, and that belongs to the customer feedback course, which explains what to do with them. Here it is enough to say that the listing is your most-used digital property and it deserves a scheduled fifteen minutes a month, not a look every two years when something breaks.
🛒 Ordering, booking and paying without an install
Everything an app would do commercially can already be done in the browser, and the other courses in this library have covered each of them in detail.
- Ordering runs through your own online ordering system — the online ordering course builds it — and the customer never installs anything. The same course also explains why moving customers here from third-party platforms is the highest-value work in the whole channel.
- Booking goes to your own reservation page, which the previous course set up, with the link on the map listing and in every reply you send.
- Paying happens in the same flow, and a phone-based payment link for large parties or catering costs nothing extra — the payment processing course covers what it actually costs you.
- Menus at the table: if you use a QR code, it must open a fast web page, not a PDF, and the paper menu should still exist for the people who want it. A QR that opens a slow document is worse than no QR at all.
- Messaging. A WhatsApp or SMS number that a human answers does more for a small restaurant than any app feature, and it is where the difficult, valuable requests arrive.
💳 The loyalty card that lives in the phone's wallet
This is the one most restaurants have never heard of and the closest thing to an app without being one. Both major phone platforms have a built-in wallet — the place people keep boarding passes and payment cards — and it will hold a loyalty card, a coupon or a membership pass for your restaurant.
What that gets you is most of the app's advantages at a fraction of the cost. It installs in one tap with no store, no account and no download. It updates itself, so a points balance or an offer changes without the customer doing anything. It can sit on the lock screen when the customer is near the restaurant. And it can send a limited notification when the pass changes — which is the one genuine app advantage from topic 1, available here for a few dollars a month.
What it does not do is run a programme. Deciding what the points are worth, when they expire and what the reward is belongs to the loyalty course, and a wallet pass with a badly designed programme behind it is just a badly designed programme that lives in a nicer place. But if you have a working programme and were about to buy an app to carry it, try the wallet first: adoption is typically several times higher, because the customer is not being asked to install anything.