How To Build A Review Request Automation

A review request automation is a triggered message programme that invites customers to share an honest account of their experience after they have had a fair opportunity to use a product or service. Its purpose is not to manufacture praise. Done well, it creates a dependable flow of genuine feedback, gives prospective customers useful evidence and helps the business spot recurring problems.

The distinction matters. A programme that only seeks five-star reviews, filters out unhappy people or pressures customers to revise criticism may create a short-term lift in ratings while damaging trust and creating legal, platform and deliverability risk. Build the automation around a simpler standard: invite eligible customers to give an honest review, regardless of what they are likely to say.

Start with the outcome you actually need

“Review request” often describes several different jobs. Separate them before building a journey:

• Public business reviews help people choose a local provider or service business, often on Google or an industry platform.
• Product reviews help a shopper assess a particular item on a retailer’s own site or marketplace listing.
• Private feedback helps a business understand the customer experience, resolve a problem or improve a process.
• Testimonials and case studies need a separate permission and approval process if a business wants to reuse a customer’s words in advertising.

These can share data and infrastructure, but they should not be treated as the same message. For example, a post-delivery product-review invitation might be appropriate seven days after a consumable arrives, whereas a review of a complex B2B implementation should wait until the customer has reached a meaningful milestone.

Choose one primary destination for each automation. Sending customers to three different review sites in one email raises effort and usually produces little useful feedback. If a customer has bought several products, decide whether the request is for the overall purchase or for individual items, rather than presenting an unmanageable list.

Use an eligibility event, not a calendar batch

The strongest review programmes are event-led. A monthly campaign to everyone who bought something in the previous month is easy to configure, but it inevitably asks some people too early, some too late and some while their issue is still unresolved.

Instead, define an eligibility event: the point at which the customer has genuinely experienced enough of the product or service to form a view. The event varies by model:

The trigger should arrive from the system that knows the event happened: order management, booking software, product analytics, helpdesk or CRM. Do not infer delivery from a “shipped” email, or account adoption from a welcome-email open. Those are proxies, and weak proxies create badly timed requests.

Keep the event record with a unique transaction, booking or account identifier. It lets the automation prevent duplicates, attribute replies and stop an invitation when a later event makes it unsuitable.

Design the decision logic before writing the email

A reliable workflow is a controlled decision tree rather than simply “event occurred, send email”. A basic version might look like this:

1. A qualifying event is received, such as delivery confirmation or completed appointment.
2. The platform waits for the product- or service-appropriate experience window.
3. Immediately before sending, it checks that the recipient is contactable and has not already completed or recently received the relevant request.
4. It checks for exclusions that mean there was no genuine experience: cancelled orders before fulfilment, test transactions, fraudulent orders or internal staff test accounts.
5. If there is an open support case, the request is deferred. Once the case closes, apply a consistent rule rather than permanently excluding customers whose experience may have been poor.
6. The invitation is sent with one clear route to the selected review destination.
7. Any completion signal, where available, ends the journey. A reminder is sent only to non-completers who remain eligible.

The key is consistency. Excluding all orders cancelled before delivery is sensible because there was no completed experience to review. Excluding customers because they gave a low satisfaction score, complained, returned an item or seem unlikely to leave praise is a different matter: it can turn the programme into selective solicitation.

Google expressly prohibits merchants from discouraging negative reviews or selectively soliciting positive ones. Its policies also prohibit incentives in exchange for a review and pressure to write a review while on the premises. Policy breaches can lead to removed content and restrictions on a Business Profile. Google’s prohibited and restricted content policy and its explanation of possible Business Profile restrictions are worth making part of the automation specification, not an afterthought.

Choose timing based on experience, not wishful thinking

There is no universal best delay. The appropriate moment is when the recipient can answer the question properly with minimal effort.

For a straightforward, low-consideration product, that might be shortly after confirmed delivery plus a few days. For skincare, supplements, software, furniture or financial advice, a longer delay may be needed. For a restaurant or salon, the request can follow the completed visit quite quickly. For ongoing services, use a value event such as a successfully completed first project, a renewal, or a predefined usage threshold.

Use a short experiment only when the core eligibility logic is already sound. Compare, for example, two reasonable delays for otherwise similar customers. Judge the result by completed, genuine reviews and downstream customer signals, not opens alone. An earlier message may earn more clicks simply because it arrives before the customer has formed an opinion.

Also consider local time and adjacent communications. A request sent just after a delivery confirmation, a renewal notice and a promotional campaign can feel like a barrage. Apply contact-pressure rules across the whole programme, not only within the review flow. A customer who received a service-recovery email yesterday should not receive a cheery review request today because the automation runs in a separate tool.

Keep the email neutral and easy to act on

The email needs little persuasion. Its job is to identify the experience, explain why feedback is useful and make the next step clear.

A practical structure is:

• a recognisable sender name and subject line;
• a brief reference to the order, visit, product or service;
• a neutral invitation to share an honest experience;
• one prominent button leading directly to the correct review page; and
• a visible preference or unsubscribe route where the message is marketing.

For example:

Subject: How was your experience with [product or service]?

Hi [first name], now that you have had time to use [product or service], we would appreciate an honest review. Your feedback helps other customers and helps us improve.

[Leave a review]

Avoid loaded wording such as “Tell everyone why you loved us”, preselected five-star graphics, or copy that implies only positive feedback is welcome. Do not ask customers to mention particular staff members unless that reflects the platform’s rules and the customer’s own experience.

If you need operational feedback as well as a public review, give each a clear purpose. A simple option is to send a public-review invitation to all eligible customers, then run a separate, voluntary feedback survey on a different cadence. Another is to collect private feedback first but issue the public-review invitation independently of the score or sentiment recorded. Routing only high scorers to a public platform is commonly called review gating; it produces a skewed picture and is incompatible with Google’s policy on selective solicitation.

Do not use incentives as a shortcut

Incentives introduce both platform-policy and consumer-protection problems. Google prohibits payment, discounts, free goods or services in exchange for posting, changing or removing reviews. Google’s guidance on getting more reviews recommends reminding customers and valuing honest, balanced feedback instead.

For UK businesses that publish reviews or review information themselves, the Competition and Markets Authority’s guidance is particularly relevant. Since April 2025, the CMA guidance explains duties around preventing and removing fake reviews, concealed incentivised reviews and misleading review information. The appropriate measures depend on the business and its risk, but publishers need policies and proportionate processes rather than relying blindly on a review-feed supplier. See the CMA’s short guide to publishing consumer reviews.

For customers in the United States, the FTC’s consumer-review rule also prohibits incentives conditioned on a particular sentiment. The FTC advises businesses not to solicit only people expected to be positive, and to understand the rules of the review platform involved. The FTC’s questions and answers on the Consumer Reviews and Testimonials Rule provides useful detail for organisations serving that market.

Make permission and suppression part of the build

A review request may feel like a service message to the team sending it, but it can also advance the commercial reputation of the business. Treat its legal classification carefully. In the UK, the ICO says that routine messages giving information needed about a contract or past purchase are not direct marketing, while electronic direct marketing is subject to PECR rules. Where an email is marketing, organisations generally need consent or must meet the conditions for the existing-customer “soft opt-in”, including an opt-out when details were collected and in every later message. The ICO’s electronic mail marketing guidance sets out those requirements.

That is a reason to involve privacy and legal colleagues when setting the programme rules, especially where messages cross markets or use a review platform as a processor or independent controller. It is not a reason to hide promotional review requests in transactional email streams.

Operationally, the automation should consult a live suppression layer at send time. At a minimum, suppress unsubscribed contacts, hard bounces, complaints, addresses with an active do-not-contact request, and people who have already completed the same review journey. Keep a frequency cap across marketing and lifecycle programmes. A sensible rule may differ by business, but “one review request per completed experience” is usually a better starting point than repeated chasing.

Use one restrained reminder

A reminder can be reasonable because people miss emails. It should not become a sequence of escalating pressure. Use at most one reminder unless there is a compelling, tested reason and the recipient has not received other high-pressure communications. Stop immediately when there is a completion event, an unsubscribe, a complaint, a bounce or a newly opened support case.

Some third-party review platforms do not provide a reliable completion webhook. In that case, do not pretend that clicks prove a review was posted. You can suppress clickers from the reminder if that is the least intrusive option, but record the limitation in reporting.

Measure quality as well as volume

Track the automation as a lifecycle programme, not a vanity channel. Useful measures include eligible recipients, sends, delivery rate, clicks to the review destination, known completions, unsubscribe rate, spam complaints, bounce rate and support contacts created shortly after the request. Break results down by product, service type, fulfilment method, market and delay window where volumes permit.

Review the responses themselves for operational themes. A persistent complaint about damaged packaging, unclear onboarding or missed appointment windows is more valuable than a marginal increase in review volume. If reviews are displayed on your own site, also document how reviews are collected, verified, moderated and presented. A “verified purchaser” label must mean what customers reasonably understand it to mean.

Deliverability deserves attention because review requests are often sent from the same domain and infrastructure as receipts, lifecycle email and promotions. High complaint or unsubscribe rates from a poorly timed request can affect more than this one automation. Authenticate sending domains with SPF, DKIM and DMARC, keep review traffic within a sensible contact-pressure model, and watch mailbox-provider feedback as the programme changes. If engagement or complaint patterns indicate trouble, pause expansion and investigate the trigger conditions, audience and message before increasing volume. This is the type of cross-programme issue that a deliverability audit can help identify.

A review automation should reflect the customer experience

The best automation does not try to outsmart customers or review platforms. It waits until there is a real experience to discuss, asks everyone in the eligible group the same neutral question, makes the answer easy to give and respects a customer’s decision not to engage.

That approach produces something more useful than an artificially polished rating: a review record that customers, platforms and the business itself can trust.