How Automated Review-Request Triggers Actually Decide When to Ask

Two of the systems published on this site — The Derm Lounge and Maid in Dallas Cleaning — list an automated review-request trigger as a standard component, sitting next to the booking calendar and the intake form. It reads like the simplest piece of the build: job finishes, message goes out, review lands. In practice it's the piece most likely to put a business on the wrong side of Google's policy or a federal rule, because both changed in 2024 and neither is about whether you can ask — they're about who gets asked.

//The naive version, and why it fails

The naive version fires on completion: invoice marked paid, or job marked closed, triggers an SMS or email asking for a review. It's the easiest version to build, and it's also the exact shape regulators have spent two years writing rules against — not the asking itself, but the quiet second step where the trigger gets rebuilt to skip whoever complained first.

//What the rules actually cover

The FTC's trade regulation rule on consumer reviews and testimonials took effect October 21, 2024. It doesn't require a delay before asking, and it doesn't ban asking selectively by itself. What it bans is displaying reviews in a way that misrepresents them as complete when negative ones have been suppressed by rating or sentiment, buying or selling fake reviews, and using threats or intimidation to get a negative review taken down — and it gives the FTC civil-penalty authority to enforce that, not just case-by-case complaints. Google's review-solicitation policy is narrower and more specific about the ask itself: a business may not discourage or prohibit negative reviews, or selectively solicit positive reviews from customers, and may not offer any incentive in exchange for a review. The two rules overlap but aren't identical, which matters for how a trigger gets built.

//What the timing data says, and doesn't

BrightLocal's 2026 Local Consumer Review Survey, a panel of 1,002 US adults, found that 83% of consumers who are asked for a review go on to leave one, and 28% say they'll 'always' leave one when asked, up from 16% the year before. That's a solid case for asking every customer. It is not a case for any particular delay window — the survey doesn't break out same-day requests against a three-day or one-week follow-up, and no published dataset we could locate does either. A claim that there's a proven optimal window of, say, 24 or 72 hours isn't something the available research supports; treat it as a hypothesis to test against a business's own response data, not a fact to build a trigger around.

What the same survey does settle is why cadence matters more than any single delay. 74% of consumers say they only trust reviews written in the last three months, 32% want something from the last two weeks (up from 20% in 2025), and 18% won't consider anything older than a week. A trigger that fires once a month in a batch satisfies none of that. A trigger that fires per completed job, spread across the week as work actually closes, is what keeps a business's review count inside the window people are reading.

//The sequence that satisfies both constraints

• +Completion event: the trigger fires when a job is marked closed or an invoice is marked paid — never on scheduling or on job start.
• +No sentiment check runs before the request fires. The trigger doesn't consult a satisfaction score, an open support ticket, or a refund flag to decide whether to ask.
• +Channel is chosen from the customer's contact preference on file, not from a predicted rating.
• +One follow-up only, sent if there's no response inside a fixed window, then the sequence closes. Repeated asks read as pressure, which is a separate problem Google's policy flags on its own.
• +A logged complaint or refund does not cancel the request. It runs on the same schedule as every other closed job.

That last rule is the one most systems get built backwards, because asking a customer who just complained for a public review feels wrong. But a trigger that quietly exempts them from the request is the exact practice both rules exist to catch, and fixing it costs nothing to build — it's a rule inside the trigger logic, not a feature: fire on completion, skip the sentiment check, ask everyone the same way.