Asking guests how it went
One email after the visit, an answer that stays with you, and why the public-review link is shown to everyone regardless of what they scored you.
Post-visit feedback is off until you switch it on, and it is worth understanding what you are switching on before you do: a second automated email to every guest who ate with you. That is why the default is "don't ask" and why the choice is per venue.
Switching it on
The control lives in your venue's settings.
Four choices: don't ask, four hours after, the next morning, or the day after. There is no "every guest, immediately" — the shortest gap is deliberate, because a request that arrives while the guest is still paying reads as a demand rather than a question.
Pick the next morning if you are unsure. It is late enough that the meal is over and early enough that the evening is still the thing they remember.
It only fires on bookings you have marked completed
This is the part that surprises people, so it is worth being plain about it.
The request is sent against bookings whose status is completed — the state you put a booking in once the party has been and gone. If your team does not close bookings out at the end of service, nothing is ever marked completed, and no feedback request is ever sent. The setting will look on and the emails will not exist.
If you switch this on and see no responses after a week, check how many of last week's bookings are sitting in seated or confirmed rather than completed. That is almost always the answer, and it is a service-habit fix rather than a settings one.
A booking that leaves completed before the delay elapses — cancelled after the fact, or corrected to a no-show — gets nothing. The status is read again at the moment the request is due, not when the booking was made, so a correction you make the next morning still takes effect.
Each booking is asked once. There is no follow-up, no reminder, and no second request if they ignore the first.
What the guest sees
They open a link on your own booking page. No account, no app, and it is in their language, not yours.
They pick a rating from one to five — labelled Poor, Not great, Fine, Good, Excellent — and can add a comment if they want to. The comment is optional and most people skip it; the ones who write are usually telling you something specific.
Underneath the comment box it says, in their language: "Optional — the kitchen and the floor both read these." That is a promise you are making on your team's behalf. It is a good promise. Keep it.
Where the answer lands
On the booking, in your book.
Open any past booking and the rating and comment sit with it, next to who came, when, and for how many. That is the point of putting it there rather than in a separate inbox: a comment about a cold main is worth more when you can see it was table nine on a Saturday at eight.
Only your team sees it. The guest is told this too — their screen says "Only the restaurant sees this. It isn't published anywhere." — so neither of you is confused about where it goes.
The public-review link is shown to everyone
After a guest sends their feedback, they are offered a link to leave a public review on Google or Tripadvisor, if your link hub has one set.
Everyone gets that link. A guest who scored you one out of five sees exactly the same invitation as a guest who scored you five.
This is not an oversight, and it is not something you can configure. Showing the public-review invitation only to guests who rated you well is called review gating, and it is against Google's and Tripadvisor's own policies as well as consumer-protection rules in most of the markets we operate in. Platforms remove listings over it.
So the software does not offer it. The component that renders the invitation is never given the rating in the first place — there is no value in scope for anyone to branch on later, which is a cheaper guarantee than remembering not to.
The upside is worth naming: your private feedback and your public reviews stop being in tension. You are asking every guest the same question in the same order, so what you read privately is a fair sample of what people think — not a filtered one that flatters you.
Changing the setting affects future bookings, not tonight's
The delay behaves differently from the status above, and the difference catches people out.
Your choice is read once, when a booking is confirmed, and held for that booking's whole life. The status is re-read at the end; the delay is not. So:
- Switch it on this afternoon and tonight's bookings — confirmed while it was still off — send nothing. Bookings taken from now on will.
- Switch it off this afternoon and bookings already confirmed still send. The ones taken from now on will not.
There is a reason it works this way rather than the way you would guess: reading the setting a second time, later, would let a booking's schedule change underneath it mid-run. One snapshot per booking is what makes the timing predictable.
The practical version: give it a day. If you turn it on before service and see nothing the next morning, that is not a fault — it is last night's bookings behaving correctly. If you turn it off because something is wrong, expect a short tail of requests from bookings already in flight, and do not turn it on and off again while you wait.