Review request automation without filtering customers

Start with the rule before the automation

A review request workflow sounds simple: finish the job, send a message, remind the customer and track whether they responded. The risk appears when the workflow quietly asks only the happiest customers, rewards people for posting, or routes criticism into a private channel while positive feedback gets the public review link.

The useful version is more controlled. A customer has a genuine completed experience. The business has permission to contact them through an agreed channel. The wording asks for honest feedback, not a rating. A human still owns replies, complaints, stop requests and awkward edge cases. The automation removes forgetfulness; it does not manufacture reputation.

What the policy checks mean operationally

Google Business Profile guidance allows businesses to remind customers to leave reviews using a review link or QR code, but it also ties reviews to genuine experiences and prohibits incentives for posting, changing or removing reviews. Google Maps policy also allows merchants to solicit genuine reviews without attempting to influence the rating or contents of the review, while prohibiting selective positive-review solicitation.

For UK businesses that publish reviews or review information on their own site, CMA guidance adds another layer: publishing all genuine, relevant and lawful reviews, keeping fake and misleading review information out, and having proportionate processes and policies for review handling. This guide is not legal advice. It is a practical operating checklist for deciding whether a proposed review request system is honest enough to build.

The seven-check review request diagnostic

Run these checks before connecting a CRM, booking tool, email sequence or messaging workflow. If a check is unknown, leave it unknown and scope the investigation; do not fill the gap with a promise.

1. Define the genuine completion event. Name the event that proves the customer has had a real experience: appointment completed, job signed off, order delivered or service closed. Avoid triggers that fire before the customer can reasonably give feedback.
2. Set eligibility before sentiment is known. Decide who should receive a request using neutral rules such as completion status, duplicate prevention, channel permission and safety exclusions. Do not make the public review invitation depend on whether the customer first gave positive private feedback.
3. Keep support and review paths separate. A customer should be able to raise a problem, and the business should have a route to resolve it. That support path should not become a filter that blocks unhappy customers from seeing the same honest review request process as everyone else.
4. Use neutral wording and no rewards. Ask for an honest review of the real experience. Do not offer discounts, gifts, priority service or wording suggestions in exchange for a review, an edit or removal of criticism.
5. Limit reminders and record stop rules. Agree how many reminders are reasonable, which channel is allowed and when requests stop. The system should avoid repeated chasing, duplicate asks and messages to people who opted out or should not be contacted.
6. Assign a human response owner. Negative reviews, detailed praise, factual disputes and privacy-sensitive comments need a calm person, not an automatic public reply. Name who reviews responses, what they may say and when a matter should move to a private support conversation.
7. Measure the process, not promised five-star growth. Track neutral operating states: eligible customers, requests queued, sent, failed, stopped, reviewed by a human and responded to where appropriate. Do not sell the workflow as guaranteed stars, removals, rankings or reputation repair.

Choose the smallest safe version

If the rules above are clear, the first useful build may be small: one completed-service trigger, one approved message, one review destination, one reminder rule and one human owner. That is often safer than starting with every branch, channel and profile at once.

If the business cannot confirm permissions, profile ownership, eligible customers or who handles criticism, automate less. Start with a manual checklist and a controlled sample. A review request system is only useful if the owner can explain why each customer was asked and what happened after the request went out.

Hypothetical example: a window-cleaning business

Invented illustration — not a client case study, legal finding or claimed result.

Imagine a window-cleaning business that wants more Google reviews. In the first proposed workflow, customers receive a private one-click satisfaction question. Only customers who choose a positive answer receive the public review link. That looks efficient, but it creates a sentiment gate: public requests are being filtered toward praise.

A safer route starts after a completed job is marked finished. Eligible customers receive a neutral message asking for an honest review of their experience. The same message also gives a normal support contact for problems, but that support option does not hide the review request from unhappy customers. A short reminder can be sent only if the customer has not opted out and the agreed cap has not been reached.

The owner then reviews any public feedback before replying. The system records what was sent and what failed; it does not mark a complaint solved, promise review removal or claim the business will gain a specific rating. The improvement is operational consistency, not a fabricated reputation outcome.

Bring the workflow, not just the review link

For an audit, bring the proposed trigger, message wording, review destination, reminder rule, customer-permission assumptions and the person who owns responses. Limitless Ops AI can then help decide whether review request automation is the right first fix, what must stay manual and what should be excluded from scope.