Automated Review Request Workflow: Ask at the Right Moment

An automated review request workflow is a system that sends a review ask to every customer who had a genuine, completed experience with the business, at a fixed point after the job closes, using the same message regardless of what the system predicts that customer will say. The moment a workflow starts deciding who gets asked based on predicted sentiment, it stops being a review request system and becomes a review gating system, which is the specific pattern both Google and the FTC treat as a problem, not a growth tactic.

TaskChad designs and sells automation like the workflow described here, so this page is a vendor's explanation of a system it profits from building, not independent research and not a summary of client outcomes. This page is not legal advice. Every rule below is a design pattern to check against your own process and, where it touches consumer protection law, against current counsel.

The workflow, described end to end

The trigger is a job or transaction reaching a genuinely completed state, not a form submission, not a scheduled appointment, and not a quote sent. Once that state is confirmed, the system checks the customer against eligibility rules, primarily that a real service was delivered and no duplicate request is already pending, then sends a single review request through the customer's preferred channel at a fixed, defined delay after completion. The message links to the review platform directly and asks an open, neutral question, never a question phrased to filter for a positive answer before the customer even reaches the platform. If there is no response, the system sends exactly one reminder after a defined interval, then stops permanently for that job.

The state model

• JOB_COMPLETED: The underlying job or transaction reaches a defined completion state in the source system.
• ELIGIBLE: The completed job passes eligibility checks, primarily that a genuine service was delivered to a real customer.
• REQUEST_SENT: The review request goes out; a response window timer starts.
• RESPONDED: The customer took some action, clicking through, leaving a review, or replying to the message directly.
• NO_ACTION: The response window elapsed with no click or reply.
• REMINDER_SENT: The single defined reminder has gone out.
• OPTED_OUT: The customer requested no further contact; suppression applies immediately and permanently for this channel.
• CLOSED: The thread reaches a terminal state, whether responded, reminded with no further action, or opted out.

Eligibility is about a genuine experience, not predicted sentiment

Eligibility and gating look similar from a distance and are opposites up close. Eligibility asks one question: did this customer have a real, completed experience with the business. Gating asks a different question: does this customer seem likely to leave a positive review. Google's Maps content policy is direct about what gating looks like in practice: merchants may not "discourage or prohibit negative reviews, or selectively solicit positive reviews from customers" (Prohibited & restricted content). The FTC's staff guidance on its Consumer Reviews and Testimonials Rule addresses the same pattern directly: asked whether a business can request reviews only from customers it thinks are happy, FTC staff answered that "the rule does not contain a specific prohibition against such conduct," but added that "this practice could violate the FTC Act" (Consumer Reviews and Testimonials Rule: Questions and Answers). A workflow that filters eligibility by anything other than "did this happen" is building the exact pattern both agencies are describing as a problem.

Required fields and idempotency

Every request needs a job or customer identifier, the completion timestamp that triggered eligibility, the channel and exact timestamp the request was sent, the template version used, and the current state. Idempotency has a specific, common failure case here: a customer with more than one completed job in a short window should not receive a stacked pile of separate review requests, one per job. The correct rule is a request cap tied to the customer, not the job count, for example no more than one active request per customer within a defined window, with additional completed jobs logged but not triggering a second simultaneous ask. This is a frequency control, not a sentiment filter, and the distinction matters enough to document explicitly so a future reviewer of the system can tell the two apart.

Timeouts, the retry boundary, and what must never happen

The response window and the single reminder are both fixed, defined values, not open-ended nudging. After the one reminder, the thread closes permanently regardless of outcome; a system that keeps asking is functionally pressuring a customer to leave a review, and pressure is a separate problem from gating but just as damaging to trust. The system must never offer an incentive, monetary or otherwise, conditioned on leaving a review, must never suggest or imply the review should be positive, must never write or suggest wording for the customer, and must never route a customer away from the public review link based on any predicted or measured sentiment signal.

Observed workflow state: a hypothetical draft system routes customers through a short internal satisfaction check first, and only sends the public review link to customers who answered positively. Policy: merchants may not "selectively solicit positive reviews from customers" (Prohibited & restricted content), and FTC staff guidance confirms asking only customers believed to be happy "could violate the FTC Act" even without a rule specifically naming the practice (Consumer Reviews and Testimonials Rule: Questions and Answers). TaskChad interpretation: any pre-screening step placed before the public review link, regardless of intent, reproduces the gating pattern both sources describe, and should be removed from the workflow design entirely rather than adjusted. Operator action: send the same request, through the same channel, on the same schedule, to every customer who passes the genuine-completion eligibility check, with no branch based on predicted response.

Human handoff and audit events

Every send, reminder, click-through, review posted, opt-out, and any reply the customer sends back needs a timestamped audit event. A reply that contains a complaint or a dispute, rather than a review, routes directly to a person for resolution, separate from and unrelated to the review request itself; the request already went out equally to that customer, so routing their complaint to a human is service recovery, not gating. An opt-out request, in any wording a person would reasonably recognize as "stop contacting me," suppresses all future requests to that contact immediately, not just for the current job.

A worked hypothetical example

Consider a hypothetical HVAC company where a furnace repair job closes on a Tuesday afternoon. The workflow marks the job eligible, waits a defined 24 hours, then sends a text with a direct review link and a single neutral line: "Thanks for choosing [business] for your furnace repair. If you have a minute, we would appreciate a review: [link]." No survey, no pre-screening question, no mention of a reward. A second hypothetical customer from the same batch of completed jobs never responds; the system sends one reminder five days later, then closes the thread permanently, with no further messages sent regardless of what happens afterward.

Failure-path tests before launch

Test the workflow against a customer with three completed jobs in one week, confirming only one active request is ever pending. Test an opt-out reply worded informally rather than with the word "stop" alone, confirming suppression still triggers. Test a reply containing a complaint, confirming it routes to a person rather than being treated as a review response. Test the eligibility check against a job that was cancelled or refunded partway through, confirming it correctly does not trigger a request for a service that was never actually completed. And audit a sample of sent requests directly against the completed-jobs log to confirm every eligible job received exactly one request, with no unexplained gaps that might indicate a hidden filter.

NIST's framework as a structure, not a certification

The NIST AI Risk Management Framework is voluntary guidance for reasoning through the trustworthiness of an AI-involved system, organized around four functions: Govern, Map, Measure, and Manage (NIST, AI Risk Management Framework). It carries no legal force, is not a certification, and citing it here does not mean this workflow has been independently verified as compliant with any law. Its use is as a structure for the questions this page keeps returning to: who owns the eligibility rule, what happens if a filter creeps in unnoticed, how that gets measured, and what the correction process looks like.

The launch gate

A review request workflow should not go live until the eligibility rule has been reviewed line by line for any sentiment-based branch, the opt-out path has been tested end to end, the request cap has been confirmed against a multi-job customer, and someone has confirmed the message wording contains no incentive, no suggested star rating, and no pressure language. The Consumer Reviews and Testimonials Rule took effect October 21, 2024, and its staff guidance says plainly that it "isn't definitive or comprehensive, and it doesn't provide a safe harbor from potential liability" (same source), so a specific program should be reviewed by qualified counsel before launch, not assumed compliant because it avoids the patterns named on this page.

Monitoring metrics and the 30-day operator review

Track completed jobs, eligible jobs, requests sent, response rate, and opt-out rate, and confirm the count of requests sent matches the count of eligible completed jobs with no unexplained shortfall. At 30 days, read a sample of actual customer replies, not just the summary numbers, looking specifically for complaints that were misrouted or opt-outs that were not honored cleanly. This review shows whether the rules are working as designed; it does not, on its own, prove the workflow caused any change in review volume or rating, which requires a defined, fixed-in-advance measurement window, not a one-time read of recent activity.

Keep an eligibility ledger that proves the request was neutral

For every completed job evaluated by the workflow, store the job identifier, completion timestamp, customer-contact channel, eligibility result, reason code, request version, send result, and suppression status. The reason code should describe neutral conditions such as "completed and contactable," "duplicate request window," "no permitted channel," or "customer opted out." It should never encode a prediction that the customer is happy, likely to leave five stars, or safe to ask while another customer is routed to a private feedback form.

Review the ledger by comparing requested and not-requested jobs across the same neutral rules. If a manager can find completed customers excluded because they complained, requested a correction, or were expected to leave a negative review, the workflow has become review gating and should stop until corrected. Keep the customer's actual review, if any, outside the eligibility decision; the system's job ends when it sends a policy-safe request and records the delivery state.

The ledger also needs an auditable suppression test. Select a synthetic internal test contact, record an opt-out through the same ingress used by real replies, and verify that a scheduled retry does not send. Label and remove the test record under the business's retention policy. A dashboard flag alone is not proof if the provider queue still releases the message.

Where this fits into the rest of your intake

Review requests sit downstream of the same job-completion event that other workflows key off. AI lead qualification workflow and service dispatch automation cover the stages before a job closes, and Google Business Profile review management covers the manual side of asking, responding, and reporting on the same platform this workflow sends customers to. Speed-to-Lead covers the broader intake system this fits inside, the receptionist page covers live and AI-assisted call coverage, and Marketing Automation covers what happens to a contact after this specific request closes.

If you want a clear look at how your current review-request habits actually work, not just how they are supposed to work, run the Revenue Leak Score. The score runs on the page without booking and returns a ranked starting point before you decide what to fix.