Used POS systems for restaurants: what actually transfers
The hardware is the cheap part and it is the only part that actually transfers. Everything that makes it work belongs to somebody else.
Home / Blog / Menu qr code: how the square ends the forty-message order
Taking orders in a chat window works right up to the Saturday it does not, and the failure is always the same three messages back.
Agha Shah Zaman · Co-founder, Get Menu · 2 September 2026
Saturday, twenty past eight, and there are sixty unread conversations on one phone. Three of them are asking whether the kitchen is still open. Two are photographs of a printed card somebody sent last spring, with old prices on it. One is a thread of about 40 messages that has produced a complete order for four people, and their street address is still missing. Somebody has to read all of this and write it out again for the kitchen.
A menu qr code is a printed square that opens a restaurant's live, orderable menu on the customer's own phone. The square itself is the QR code Denso Wave invented in 1994 for tracking car parts; the restaurant trade borrowed it because any phone camera now reads it. In practice its main job in Brazil is not to replace paper. It is to replace the typed conversation, by giving the customer a structured place to build an order before they ever message anybody.
The distinction matters because it decides what you are buying. A code that shows a menu removes a printing cost. A code that takes the order removes a transcription step, a category of mistakes, and the twenty minutes an evening somebody spends assembling other people's orders by hand.
Three things, none of which show up in any report. First, the labour: somebody senior is reading, interpreting and retyping, usually during the busiest part of the evening. Second, the errors (a missing modifier, a size assumed, an address abbreviated) which arrive back later as a remake or a complaint. Third, the record: a chat thread cannot be counted, so at the end of the month nobody can say what sold.
There is a fourth, quieter cost. A conversation has no rules. A customer can ask for a price from last week and get it, because nobody wants to argue at nine at night. An ordering page re-prices every line from the live menu at checkout, so the discussion never starts. Options and add-ons carry their own prices, so an extra portion is charged by the system rather than remembered. And a double tap cannot place the same order twice, which a chat thread has no way of preventing at all.
It moves the assembly work to the person who actually knows what they want. The customer scans, reads a page built for one thumb on a phone, chooses, and the cart takes their name and number before checkout. What arrives is a finished order rather than a negotiation.
The messaging then goes the other way, which is the part restaurants underestimate. Instead of a person typing confirmations, 3 messages leave automatically in about 2 seconds. The customer gets a confirmation with a real time on it, the kitchen's ticket reaches the managers' group, and whoever is delivering gets a dispatch with the pin attached. There is a log of every message and whether it arrived, so the argument about whether somebody was told is settled by looking rather than remembering. This split is the one Meta itself designs for in the WhatsApp Business Platform: the chat carries confirmations and updates, not data entry.
For delivery, the address stops being free text. The building and unit are picked from a list, a fee can be set per building, and free delivery over a threshold you choose stops being a promise somebody has to apply by hand.
WhatsApp is where the order should be confirmed and the worst possible place to assemble one. The customer is doing data entry into a chat window and your staff are doing it again at the other end. Keep the conversation and delete the typing. That is the whole design.
— Tanzeel ur Rehman, co-founder of Get Menu
Marketplace commission is charged as a percentage of every ticket, and where the platform also supplies the courier it sits at the top of a band commonly quoted between 25% and 30%. A restaurant putting R$ 50,000 through an app in a month at 25% is leaving R$ 12,500 behind before it pays for rent, gas or the food itself.
That is a fair price for discovery and a poor one for a regular. The customer the app introduced stays the app's customer: their number lives there, so the second order, and the fortieth, get charged the same finder's fee as the first. A direct channel does not replace the marketplaces. It moves the people who already know you off the meter.
The move is cheap to attempt. A code on the delivery bag costs the price of a sticker, and the customer who scans it next time arrives on your own address on getmenu.ae, where the whole ticket stays yours.
Four placements do most of the work. On the tables, where a code generated for every table means the table is the address and nothing about location gets typed. On the counter, for the queue. In the window, for people reading it from the pavement while the shop is shut. And on the bag, where it converts a marketplace order into a direct one.
Each placement wants a different destination behind the same product. A table code should open the dine-in menu; a bag sticker should open the delivery menu with the fees and the minimum in place. Getting that right at print time is far cheaper than reprinting, and it is the question most operators only think about after the cards arrive.
The point of owning the order is owning the record that follows it. Once a name and number sit in your own list, the second visit costs nothing to win. Stamps are counted automatically without anybody marking an order delivered by hand, and birthday and anniversary rewards send themselves. The card is carried in Google Wallet with no app to install, and Apple Wallet is built, awaiting a certificate.
Abandoned-cart nudges and referral programmes sit on the same list, with a weekly cap per customer so nobody is pestered into blocking you. And the boring end works too. The invoice total is always the sum of its lines, the sales dashboard splits by day, item and channel, and the whole customer list exports on any day you ask, including your last.
They solve different problems, and plenty of small operations run only the ordering side. A cash register is for accuracy at the counter and the cash drawer at close; an ordering page is for the order arriving structured, the customer record and the paperwork. Buy the one that matches the loss you can actually name.
No. The order is settled in cash or on the restaurant's card machine at the door, and that is deliberate. With nothing charged inside the page, no card details exist anywhere in the system to be stolen, and no processor takes a slice of the ticket.
Yes, and they should. A chat is the right place for questions and confirmations. What changes is that the order itself arrives assembled, so the conversation is about the food rather than about spelling a street name. The threads that disappear are the long ones where a qr menu would have done the typing.
Usually the same week. The menu can be uploaded from a spreadsheet rather than typed, codes are generated and a print pack is emailed ready for the printer, and the trial runs 15 days with no card asked for. Detailed order contents are cleared automatically after 120 days.
Further reading
The hardware is the cheap part and it is the only part that actually transfers. Everything that makes it work belongs to somebody else.
Commission is the only software bill that grows every time the kitchen has a good night, and most owners have never worked out the month's total on paper.
One city wrote the fees into law, which makes them the clearest public numbers available on what delivery actually costs a restaurant.
Fifteen days with everything switched on. No card, no commission, ever.
Questions from other owners are answered in the community.