Google Review QR Code Mistakes Restaurants Should Avoid

Most restaurant QR review programs fail in the same five places. The underlying technology is fine. The QR code itself is fine. The destination link is usually fine. What kills the program is one or more of a small set of repeatable operational decisions made by someone trying to be helpful but optimising for the wrong thing. Below is the ranked list of mistakes, with the mechanism behind each one and the specific fix.

The most common version of this is the QR card on the wall by the entrance, or above the bar, or near the bathroom door. The intent is reasonable: "it should be visible to everyone." The problem is that visible-to-everyone is not the same as visible-during-the-review-moment. A customer who walks past your QR on the way in is not yet in a position to review anything, and the same customer on the way out has already mentally moved on.

The fix is to put the QR exactly where the customer is during the seven-minute window between dessert and the bill. For sit-down restaurants that means the bill presenter or a table tent. For counter formats it means a vertical card next to the card reader during checkout. For takeaway it means the bag itself, where the customer encounters it again at home while still eating. Visibility is necessary but not sufficient. Visibility-at-the-right-moment is what converts.

"Scan me." "Feedback." "Tap here." These are the three most common QR prompts, and all three perform poorly. They tell the customer to do something but not what they are doing or why. The customer hesitates because the cost of finding out (a scan they cannot easily undo) feels higher than the cost of just ignoring it. The result is the same printed card sitting on the table for months, generating very few scans even though the placement is fine.

The fix is short, specific, benefit-oriented copy. "Loved your meal? Leave a quick Google review" outperforms "Scan me" by a wide margin because it does four things in seven words: ties the ask to a positive moment, names the platform, signals low effort, and tells the customer exactly what they are doing. Avoid asking for a five-star review specifically; that is against Google's review content policy and can get reviews filtered or removed.

Even when placement and prompt are correct, the QR can still die at the destination. Pointing directly at Google's review form puts the customer in front of an empty text box, and a meaningful percentage freeze, write "food was good," feel embarrassed by how short it sounds, and close the tab. The owner sees scans in their analytics and almost no posted reviews, and assumes the QR is broken. It is not broken. The customer is.

The fix is a short prompt sequence between scan and Google. Two or three quick questions about the meal (what they ordered, what stood out, would they come back) get answered in 30 seconds, and the answers assemble into an editable draft the customer can post in one tap. The customer goes from staring at a blank form to looking at a draft they recognise as their own. Modern review tools (Kaisah included) handle this automatically, but the principle works whether you build it yourself or buy it.

What works for a casual sit-down restaurant does not work for a cafe with counter pickup, a dessert bar with five-minute visits, or a takeaway-heavy operation that never sees the customer in person. Generic QR advice often gets copied from a sit-down playbook to a quick-service one without anyone asking whether the customer journey is the same. The QR ends up in a placement that made sense for one format and is wrong for the actual one in use.

The fix is to start with the customer journey for your specific format and design the QR program around the moment the meal ends in that journey. For sit-down: the bill presenter is the moment. For cafes: the card reader at checkout. For takeaway: the bag. For delivery: the receipt and any post-order WhatsApp message. The QR card on the wall might be the right call for one of these formats and completely wrong for another, and the difference is not subtle.

Most restaurants run their QR program for months without ever knowing which placement is producing reviews. They have a card on the bill presenter, a sticker on the takeaway bag, and a poster near the door, and the analytics show "35 reviews this month" without breaking down the source. Without that breakdown, every decision about the QR program is a guess. Whitespark's Local Search Ranking Factors consistently ranks review velocity (the steady drip of new reviews) as one of the strongest local pack signals, so doubling down on whichever channel is actually generating posted reviews compounds far faster than spreading effort evenly across all of them.

The fix is unique tracking links behind each QR placement. Most modern review tools (Kaisah included) attribute scans and posted reviews back to source automatically. Two to four weeks of data is usually enough to see one channel pulling clearly ahead. The next decision is obvious: print more of whatever is winning and stop printing whatever is not.

• Coloured QR codes or QRs with a logo embedded in the centre: these scan less reliably across the wide range of phones and lighting conditions a real restaurant has. Stick with high-contrast black on white.
• Tiny QR codes squeezed into a busy menu design: smaller than one inch square is genuinely hard to scan in dim lighting. Make it bigger, even if the design suffers.
• Multiple competing prompts on the same card (Google review + Instagram + newsletter): the customer often does none of them. Pick one ask per surface.
• QRs printed in a single batch and never refreshed: bill presenters get coffee-stained, takeaway bag stickers fade in the sun, table tents tear. Refresh the printed materials every two to three months or when they look tired.

If your scan rate is very low, the placement or the prompt is the problem. If you have meaningful scans but few completed reviews, the destination is the problem. If you have lots of scans and lots of reviews but most are vague "food was good" type entries, the destination flow is missing the question prompts that pull out specific detail. The diagnosis usually narrows down to one of these three layers, and the fix for each is different.

Two weeks of normal operations with proper tracking is usually enough to identify which layer is failing. Three months of running the same program without any visible improvement and the underlying review setup needs a rethink, not another tweak.