QR Codes for Reviews and Feedback: Asking at the Right Moment

Nobody has ever written a review because a square was printed on the receipt. The code does not persuade anyone. What it removes is the part that actually loses you the review: the customer who genuinely meant to leave one, opened their phone at home four hours later, searched your business name, found three places with almost the same name, and gave up. That gap is most of the shortfall, and it is the only part of this a QR code can fix.

Which means everything worth deciding here is about when you ask and what the scan lands on — not about the code. This is the same argument as where should a QR code point, applied to the one destination that is hardest to get right.

Timing is the whole thing, and it is shorter than you think

The window is while the person still feels whatever they felt. It closes fast. A code that is in front of someone during that window will out-perform a better-designed one that is in front of them an hour later, and no amount of design fixes being late.

The good moments are the ones where something has just finished and the person is standing still:

• The receipt or the card machine, at the point the transaction closes.
• The hand-off — the counter, the door, the moment the job is signed off.
• Inside the box, on the top layer, so it is the first thing seen on opening rather than the last.
• The end of an appointment, on the card that confirms the next one.

The bad ones are all the same mistake in different clothes: asking before the thing has happened. A code on a table tent gets scanned mid-meal by someone who has no idea yet whether they enjoyed it. A code on the packaging of a product nobody has used yet is asking for a review of a box. If the ask arrives before the experience finishes, you are not collecting an opinion — you are interrupting one.

There is one placement that cannot work at all, and it gets designed constantly: a review QR code on your own website. The device reading the page is the device that would have to scan it. Put a link there instead, and keep the code for surfaces a phone can look at.

Do not sort people by how happy they are

This is the single most common build, it is sold as a feature by plenty of tools, and it is worth being blunt about: the flow that asks "how was your experience?" and then sends the happy people to a public review site while quietly routing the unhappy ones into a private complaint form is review gating, and it is against Google's review policy — which prohibits discouraging or preventing negative reviews. Other platforms have their own wording on the same idea. Go and read the current policy of whichever platform you are pointing at before you build the fork; it is their rule, it is written down publicly, and it changes without telling you.

The version that does the same job honestly is one destination that offers both routes as equals: leave a public review, or tell us privately. No question in front of it deciding who sees which. People who want to complain will take the private door on their own — the difference is that you are not the one hiding the public one from them.

There is a practical argument as well as a rules one. A page of reviews with no criticism in it reads as bought, and the business that never hears its complaints is the business that keeps making them.

Land on the box, not on the profile

The most common wasted scan lands somewhere that is about your business rather than somewhere the person can type. A profile page, a map pin, a homepage with a reviews link in the footer — each of those is one more decision between the intention and the keyboard, and every extra step sheds people.

Point the code at the write-a-review form itself, so the scan ends with a cursor in a box. Most platforms expose a direct link for exactly this; find yours and use it rather than the address that appears in your browser bar when you are logged in as the owner, which is often an admin URL that does nothing useful for a customer.

Two things follow from that:

Test it signed out. On a phone that has never seen your business, on mobile data, not on the shop wi-fi and not while logged into an account that owns the listing. A review link behaves differently for an owner, and the version you can see is not the version your customer gets.

Assume the link will break. Review URLs are not yours. Platforms restructure them, listings get merged, and the format that works today is a format somebody else controls. That is the strongest argument here for a code whose destination is a setting rather than a print run — see static vs dynamic QR codes. A stack of 500 review cards encoding a URL you cannot edit is a stack of paper with an expiry date you do not know.

Reviews and feedback are two different jobs

They get collapsed into one code constantly and they want opposite things. A review is public, it is for people who have not bought yet, and its value is that a stranger wrote it. Feedback is private, it is for you, and its value is the detail — which is exactly what nobody puts in a public star rating.

If you want both, that is two asks in two places, not one fork. The review ask belongs at the moment of the good experience. The feedback ask belongs where somebody has a reason to tell you something: a follow-up card, a hosted page with a form on it, the bottom of the review destination as a genuine alternative. On this site the second one is a Smart Destination Page, which is a page you can point a code at and change afterwards.

What you should not do is dress a feedback form up as a review ask. Someone who scanned expecting to praise you publicly and got a survey has been mildly conned, and they close it.

Say what happens after the scan

A bare square with no line beside it gets ignored, and a vague one ("scan for more") gets ignored slightly less. The line does the persuading; the code just carries the address. What to put next to a QR code covers this properly, but three things matter more here than almost anywhere else:

• Name the platform. "Leave us a Google review" sets an expectation the destination can meet. "Rate your experience" does not, and the mismatch is what makes people bounce off the landing page.
• Say how long it takes. Someone standing at a counter is deciding whether this is a thirty-second thing or a form.
• Ask like a person. The ask that works is the one a member of staff says out loud while pointing at the card. The printed line is a reminder of that, not a substitute for it.

What the scan count proves, and what it does not

Be exact about this, because it is the easiest number on this page to fool yourself with. Scan analytics record that a code was scanned — how many times, roughly when, roughly where, on what kind of device. Everything after the scan happens on somebody else's platform. Nothing here can tell you that a review was written. Any tool that reports a review conversion rate is inferring it from the two numbers at either end.

What the count is genuinely good for is comparing your own surfaces against each other, which is a question nothing else can answer. Give the receipt a different code from the box insert and from the counter card, and after a month you know which physical thing gets people to lift a phone. That is entirely on your side of the scan and it is a real finding. How to track QR code scans covers the mechanics.

The other honest read is the ratio you can get for free: your own review count on the platform, before and after. It is noisy, it is not attributable to the code alone, and it is still more informative than a scan number — because it measures the thing you actually wanted.

Where this fits for a business with a counter

The pattern is at its strongest where the customer is physically present at the moment the experience ends, which is why it belongs on the same shortlist as the rest of the front-of-house work in QR codes for restaurants and across restaurants and bars generally. The review template is the starting design; the decisions above are the part the design cannot make for you.

The short version

• Ask at the end of the experience, not during it. Late is the default failure.
• Never fork people by sentiment. It breaks platform policy and it hides the complaints you need.
• Land the scan in the review box itself, and test it signed out on mobile data.
• Assume the review URL will change — use a destination you can re-point.
• Keep the public ask and the private feedback ask separate and honest about which is which.
• Name the platform and the time cost on the line beside the code.
• Scans are not reviews. Use scan counts to compare your own surfaces, and the platform's own count to judge the result.