By ReputeLabs editorial · ReputeLabs is a JC TechLabs brand
Most review gating isn't planned. Nobody writes a spec that says "hide the review link from unhappy customers". It creeps in through a reasonable-sounding product idea:
"Let's ask customers how we did first. If they say 4 or 5, send them to the review page. If not, open a support ticket."
It sounds like good customer service. It is also exactly what Google's Maps content policy calls out. Among the things merchants are not allowed to do, the policy lists: "Discourage or prohibit negative reviews, or selectively solicit positive reviews from customers", along with offering "incentives – such as payment, discounts, free goods and/or services" in exchange for a review. (Google Maps User Generated Content Policy)
If you build CRMs, booking systems or post-purchase flows, you are often the person who decides whether a business stays on the right side of that line. This post covers how to design a review-request flow where gating cannot happen, by construction rather than by good intentions.
The one rule for a review request workflow
The decision to send a review invitation must not depend on anything that predicts the rating.
That rules out satisfaction scores, NPS answers, sentiment analysis of support tickets, "VIP" flags and refund history. Every one of them is a proxy for "will this person be positive?"
What it allows is facts about whether a genuine experience happened: an order was delivered, an appointment was completed, a project was signed off.
Model eligibility as an event, not a judgement
Trigger invitations from a completed-experience event and keep the eligibility function deliberately small:
type CompletedExperience = { customerId: string; experienceId: string; // order, appointment, job completedAt: Date; channelConsent: ("email" | "sms" | "whatsapp")[]; }; // Deliberately narrow inputs: nothing here can predict a rating. function isEligibleForInvite(e: CompletedExperience, alreadyInvited: boolean): boolean { return e.channelConsent.length > 0 && !alreadyInvited; } The type is doing the ethics work. If satisfactionScore isn't in the input, nobody can branch on it later without a visible code change. When a future pull request adds it, a reviewer should ask why.
Separate feedback from reviews, and never chain them
Private feedback forms are fine and often useful. The problem is sequencing: if the public review link appears only after a positive private answer, the private form has become a filter.
Two patterns that stay neutral:
- Parallel, not serial. One message offers both options side by side: "Tell us privately" and "Leave a public review". Both are always shown, to everyone.
- Separate moments. Send the review invitation on its own schedule, unaffected by any feedback response.
Write a test for it, because this is the kind of regression that slips in quietly:
test("review link is present regardless of private feedback score", () => { for (const score of [1, 2, 3, 4, 5, null]) { const msg = buildFollowUp({ privateScore: score }); expect(msg.reviewUrl).toBeDefined(); } }); Keep the wording neutral, and lint it
Copy can gate as effectively as code. "If you loved your visit, leave us 5 stars!" is a selective request. Keep templates in version control and run a simple check on them:
const BANNED = [/5[- ]?stars?/i, /if you (loved|enjoyed)/i, /discount|voucher|reward|free/i]; export const lintTemplate = (t: string) => BANNED.filter(r => r.test(t)).map(String); A good neutral template reads something like: "Thank you for choosing us. If you'd like to share your experience, honest feedback helps other customers and helps us improve: {link}".
It's crude, but it catches the obvious mistakes before a marketer ships them, and it documents the intent in code.
Google review policy: no incentives, anywhere in the pipeline
Watch for incentives that leak in from other systems: a loyalty engine awarding points for "posting a review", or a coupon module triggered by the same completion event. Keep review invitations out of reward rules entirely. That also covers asking someone to change or remove a review in exchange for anything. The same policy section prohibits it.
Don't pressure on the premises
If you build tablet or kiosk flows, note that the policy also says merchants "should not require or pressure users to leave ratings or write reviews while on the premises", or ask for specific content such as naming a staff member. A QR code on a receipt is an invitation. A staff member standing over a tablet is pressure. Also avoid staff quotas for review counts. The policy mentions those explicitly.
Ethical review management: measure the process, not the stars
The metrics you put on a dashboard shape behaviour. Report on things the team controls:
- invitations sent, as a share of completed experiences (consistency)
- reviews received and responded to (care)
- median time to reply to a critical review
- recurring themes in feedback (what to fix)
Leave average rating off the team's targets. Ratings are the customer's choice. Making them a KPI is how people end up rebuilding the gate.
A short checklist for your next PR
- [ ] Eligibility depends only on a completed experience and consent
- [ ] Public review link shown to everyone, never conditional on feedback
- [ ] Templates are neutral and linted (no stars, no "if you loved", no rewards)
- [ ] No loyalty or coupon rules attached to reviews
- [ ] Dashboards track consistency and response, not rating targets
Build it this way and you get a review profile that actually means something, to customers and to the business reading it.
ReputeLabs helps businesses plan honest review requests: neutral templates, review links, QR materials and response guidance. If you're designing one of these flows and want a second opinion, you can **plan honest review requests* with us at reputelabs.tech/services/genuine-reviews, or read what we will and won't do. For responding, reporting and tracking, see JC TechLabs' Google review management guide. ReputeLabs is not affiliated with or endorsed by Google. This article describes general practice, not legal advice. Check the current platform policy before you ship.*
