Module · Guest Feedback

Restaurant Guest Feedback Software

Ask them before they tell Google. A private question after the meal, answered without an account — and the only feedback anywhere that knows which dishes they actually ate.

Why it matters

A guest who had a disappointing night has two realistic options: say nothing, or write it on Google. Almost everyone takes the first, which means the venue never finds out and never gets the chance to fix it — and the small number who take the second do it in public, permanently, to an audience of strangers.

A private channel catches the complaint while it is still worth something to everybody. The guest gets a reply instead of a shrug. The kitchen finds out on Monday rather than in a paragraph nobody can edit. And the thing that went wrong gets attached to the order it happened on, which is the difference between "service was slow" and knowing which table, which night and which shift.

This is deliberately not a review system. Nobody reads reviews on a restaurant's own app and Google already owns that surface. What this does instead is the one thing a review site structurally cannot: it knows what was on the plate.

Guest feedback list showing each response with its overall rating, the food, service and speed scores, and the dishes from that order
Every response arrives attached to the order it came from — including what was on the table.

How the ask works

01

It arrives about forty minutes after the order

Late enough that the meal is finished, early enough that it is still the evening they are describing. Asked on the guest's own phone, on the same screen they ordered from.

02

Anonymous by default, and that stays ordinary

Most orders come from a QR menu with no account behind them, so the order's own session is the authorisation. Requiring a login would lose most of the answers, and the answers are the entire point.

03

One required question

Overall, one to five. Somebody who taps the stars and closes the page has still told you something, and a form that refuses to submit is a form that gets abandoned.

04

Three optional ones

Food, service, speed. Three things a venue can actually change on a Monday, and separating them is what turns "it was fine" into a decision.

05

One question per dish

Not a rating — "would you order this again?" A five-point scale per dish across a four-course order is how a form gets abandoned halfway. A yes or a no is answerable in the second somebody gives it.

06

Once per order, and that is the end of it

One response per order, enforced. The ask is a moment, not a thread, and a venue that follows up twice is a venue people stop answering.

The question only you can ask

Google can tell an owner that somebody gave the place three stars. Only the system that took the order knows they ate the sea bass. That single fact is what this module exists for, and nothing else in the product can produce it — not sales, not margin, not popularity.

Popularity is the trap in particular. The dish people order most is very often the dish people order once: it reads well on a menu, it photographs well, and it does not survive contact with the table. Sales data cannot distinguish that from a favourite, because both look like a lot of orders.

A dish with forty orders and four would-order-agains is a dish to take off. You will not find that number anywhere else, and once you have seen it on one item you will want it on the whole menu.

What you do with a bad night

01

Reply, with something attached

An owner can answer a piece of feedback and put a code with it. It reaches the guest as a code rather than as a sentence about one, because a code is the only apology anybody can actually spend.

02

Rewards only where there is somewhere to put them

A reward needs an account to live in, so it exists for guests who happened to be signed in. Anonymous feedback stays first-class and is never treated as worth less — the moment it is, the bias that introduces is worse than the data it buys.

03

Server ratings are shown, never averaged

A guest can rate who served them, and the owner sees it attached to that one response. It is deliberately not turned into a per-staff score: on a small team with tables allocated more or less at random, most of the variation between servers is noise, and a leaderboard built on noise gets read as fact.

04

Small samples say so

Three responses averaging 4.7 is not a rating. Every average arrives with the count behind it, and below a threshold the report declines to state a number rather than printing a confident one.

Common questions

When exactly is the guest asked?

About forty minutes after the order, on the phone they ordered from. The timing is the meal, not the day after.

Do guests need an account to leave feedback?

No, and most will not have one. The order's own session is what authorises the response, the same way it authorises reading the bill.

Is this a review system?

No. Nothing here is public and nothing is shown to other guests. It is a private question whose answers only you see.

What can it tell us that Google reviews cannot?

Which dishes were eaten, and whether the person who ate them would order them again. A review site never knows what was on the plate.

Can we reply to somebody who complained?

Yes, and you can attach a code to the reply. It shows up for them as a code, on their rewards list, rather than as a paragraph.

Will it rank our waiters against each other?

No, on purpose. A server rating is shown on the response it belongs to and never averaged into a score, because on a small team most of that variation is which tables somebody happened to get.

See it in action

See what your guests would have told you.

Book a demo