A Menu PDF Is Not an Online Ordering System
A PDF menu and a phone number is not online ordering. Here are the four things a restaurant online ordering system has to do, and the failure each one prevents.
Someone is standing at a streetcar stop at 6:40 on a Tuesday. They are hungry, they have about ninety seconds of attention, and they found your website. They tap the link that says Menu. A PDF opens. The text is the size of an ant. They pinch, they zoom, they scroll sideways to read the price of the chicken shawarma, they lose their place, and then they go back to Google and order from the place two blocks over.
Nothing about that is a failure of your food. It is a failure of a document. A PDF is a picture of a menu. It was designed to print the same way on every machine, which is a wonderful thing for a print shop and a useless thing for a hungry person on a phone. Yet a lot of restaurants genuinely believe they have online ordering because they have a menu on the site and a phone number in the header. That is a menu and a phone number. It is not a restaurant online ordering system.
Here is what an ordering page actually has to do. Each one of these is worth explaining by the specific disaster it prevents, because a feature list means nothing until you can see the order you lost.
It has to work in a phone browser with nothing to download
The failure this prevents: the customer decides ordering from you is a project.
Most of your orders start on a phone, usually from Google or Instagram, usually from someone who is already a little impatient. Every step you put between that tap and a placed order costs you some of them. An app download costs you most of them. A forced account signup — name, email, password, confirm password, verify your email — costs you a lot of them too, and it costs you the ones who were about to spend the most, because they were in a hurry.
The standard to hold yourself to is simple: a person who has never heard of you should be able to go from tapping your link to a confirmed order without installing anything, without creating a password, and without typing their email twice. Guest checkout with a phone number is enough. You can invite them to save their details after the order is paid for, when they have a reason to say yes.
Speed is part of this, not separate from it. If the page takes six seconds to show food, you have already lost people who would have ordered. We wrote about that in more detail in why your website should load before they change their mind.
It has to remember the last order and the card
The failure this prevents: your regulars drift to the app that remembers them.
A neighbourhood restaurant lives on people who order the same thing every couple of weeks. The third time someone orders the large pad thai with extra chili, they should not be re-entering their address, their unit number, their buzzer code, and their card. They should be tapping Reorder.
This is the single biggest advantage the big delivery apps have over you, and it has nothing to do with marketing budget. It is that they stored the card. When ordering from you takes forty taps and ordering from the app takes three, your own regular uses the app — and then you pay a commission on a customer you already earned. If you have not run those numbers lately, what delivery app orders actually cost you is worth ten minutes.
A saved profile also gives you something a PDF never will: a list of your own customers, with what they order and how often, that belongs to you and not to a third party.
It has to tell the truth about timing
The failure this prevents: someone standing at your counter at 7:15 while their food has not started.
Every ordering page shows a pickup time. Most of them are lying, because the number was typed in once during setup and never touched again. Twenty minutes is honest at 3 p.m. and a fantasy at 7 p.m. on a Friday.
An ordering system that respects your kitchen does three things with time. It quotes longer when you are slammed, either automatically or because you can push a button that says "we're 15 minutes behind" from the pass. It lets customers schedule for later, which is free revenue you are currently turning away — the person planning Friday dinner on Thursday night is one of the easiest orders you will ever take. And it stops taking orders when you close, including on the holiday Monday you forgot to update, because an order that arrives after the kitchen is cold turns into a refund and an angry review.
The same logic applies to your menu. If you 86 the branzino at 8 p.m., the ordering page needs to know within seconds. Selling a customer something you do not have is worse than not being open — you have taken their money and their evening and given back an apology.
The ticket has to land in the kitchen, not in someone's hands
The failure this prevents: a hand-copied ticket with the wrong modifier on it.
This is the part restaurants underestimate most. Plenty of "online ordering" setups end with an email to the info@ address, or a tablet by the host stand that chirps and needs a human to read the order out loud to the kitchen. On a slow day that works. During a rush, that tablet is unattended for eleven minutes, or someone retypes the order into the POS and drops the no-onions, and now you are remaking a burrito bowl at the busiest moment of the night.
What you want is the order printing where your other tickets print, in the same format your cooks already read, with the modifiers and the customer name on it. No extra screen to watch. No translation step. Online orders should be indistinguishable from counter orders by the time they reach the line, because the line has enough to do.
The front of house side matters too. If a customer needs to change something, they call — and if nobody can pick up during the rush, you get the cancellation instead. That problem is fixable, and what to do with the phone during your dinner rush covers how.
Test your own setup in ten minutes
Do this tonight, on your own phone, over cell data and not your restaurant's wifi.
- Search your restaurant name on Google. Tap through to your site. Count the seconds until you can read menu prices.
- Try to place a real order for pickup. Pay for it. Note every screen where you had to think.
- Check what happened in the kitchen. Did a ticket print, or did something chirp somewhere?
- Now place a second order as the same customer. Did it remember you, or did you type the card again?
- Look at the quoted pickup time. Would it have been true at 7:30 on Friday?
If any of those five steps made you wince, that is where your lost orders are going. Not to a competitor with better food — to a competitor with a shorter checkout.
Keep the PDF, by the way. It is fine for printing, fine for emailing to an office booking a catering order, fine to hand to a supplier. It is just not a place where money can change hands.
If you want to see what an ordering page that meets all four of these looks like on a real restaurant site — including how the tickets reach the kitchen — that is what we build at Webonology for restaurants. We run a restaurant ourselves, so the ticket printer question is not theoretical for us either.