THE SHORT VERSION
- Never send a public review link unconditionally. Ask a satisfaction question first and branch on the answer.
- The trigger is job completion, not invoice payment — payment often lags the experience by weeks.
- Two channels and three touches over a week beats one perfectly written text.
- The unhappy path is the point of the whole system: catch it privately, resolve it, and it never becomes public.
Most review automation is one workflow: job marked complete, send a Google link, done.
It works until the first customer whose job went badly receives it. Then it works extremely well, in the wrong direction — because you have just invited the one person with a grievance to publish it, at the exact moment they are most annoyed, with a direct link.
The fix is not to send fewer requests. It is to ask one question first.
The gated pattern
Every review system worth building has the same shape.
1. Trigger on completion. The job is done, the visit finished, the matter closed. Not invoice payment — payment can lag the experience by weeks in trade verticals, and by then the customer no longer remembers the detail that would have made a good review.
2. Wait a short while. Long enough that the work is genuinely finished and the customer is not still standing in their hallway; short enough that the experience is vivid. A couple of hours suits most service businesses. A dental practice and a roofing company want different intervals, which is why it is a variable in every one of our snapshots rather than a fixed number.
3. Ask one satisfaction question. Not “leave us a review”. Something answerable in one tap — a rating, or a yes/no on whether everything went well. This is the gate, and it is the whole design.
4a. Satisfied → public links. Now send the Google and Facebook links, with a short line making the ask explicit and easy. This customer has already told you the answer; you are just handing them the pen.
4b. Not satisfied → internal escalation. No public link. A private “tell us what went wrong” reply path, a notification to the owner, and a task with a name against it. This is not suppression — the customer can still review you anywhere they like, and nothing stops them. It is triage: the business finds out today, privately, and gets a chance to fix it before it is a public one-star with no reply.
5. Follow up on the non-responders. Most people who ignore the first message are not unhappy, they are busy.
Step 4b is the part that justifies the whole system. An unhappy customer you never contacted writes a review anyway, in their own time, with nobody having tried to fix it. An unhappy customer you routed into a private conversation frequently becomes a satisfied one.
Where the line actually is
Worth being precise, because “review gating” has become a loaded phrase.
Fine: asking how it went before deciding what to send. Sending public links to people who said it went well. Routing complaints to a human. Following up on non-responders. Making it easy.
Not fine: preventing anyone from leaving a public review. Incentivising positive reviews with a discount or entry. Writing reviews yourself or having staff do it. Presenting invented reviews as genuine anywhere on a website.
The distinction is between deciding which message a customer receives and interfering with what a customer is able to say. The first is ordinary marketing. The second is a platform violation, and in many markets a consumer-protection one.
The same principle applies to how reviews are displayed, which is why our own review sections carry a visible marker while they hold sample entries, and no rating structured data is emitted until real, permissioned reviews exist. Anything else is fabricated social proof wearing a schema tag.
The cadence
One message is not a system. Three touches across two channels over about a week is:
- Touch 1 — SMS, a couple of hours after completion. The satisfaction question. Short.
- Touch 2 — email, next day, for anyone who did not answer. Slightly more context, same question, still one tap.
- Touch 3 — SMS, three or four days later, last ask. Explicitly the last one.
Then stop. A fourth request is pestering, and it costs more goodwill than the review was worth.
For customers who answered “satisfied” but did not go on to leave the review, one reminder with the direct link is worth sending — that group has the highest conversion of any segment in the whole sequence, because they have already stated the opinion and simply did not get round to publishing it.
The volume this produces varies enormously by vertical and by how many jobs a business completes. Our snapshots are designed around a target of 5 to 10 reviews a month for a typical single-location service business running the full cadence. That is a design target rather than a measured average, and a busier business should expect more.
What to automate beyond the request
The request is the start of it.
Replies. Every review deserves one, and the ones that most need a good reply are the negative ones. Automate positive acknowledgement, and route anything negative to a human with a draft rather than an automatic response — an auto-reply to a serious complaint reads exactly as badly as it sounds.
Recycling. A five-star review with a specific sentence in it is a piece of marketing copy. Surfacing recent ones on the site is a genuine conversion lever, and it costs nothing once the pipeline exists.
Reporting. Count of requests sent, satisfaction responses, public reviews landed, and escalations opened. Without the last number, nobody knows whether the negative path is working or whether the workflow just stopped.
The three timing mistakes
Almost every underperforming review system has one of these, and all three are timing rather than copy.
Asking too late. A request that goes out a week after the job asks the customer to reconstruct an experience they have stopped thinking about. What comes back, if anything, is generic — “great service, would recommend” — which is worth much less than a review naming what actually happened. The specific detail is perishable and it expires within a day or two.
Asking too early. Firing the request the instant a job is marked complete catches people who are still standing in the room with the technician, or who have not yet seen the finished work. In trades where the result is visible only after something dries, sets or is cleaned up, the completion tick and the customer’s judgement are hours apart.
Asking on the wrong event. The most common version is triggering on invoice payment. Payment is an accounting event, not an experience, and in trade and professional verticals it can trail the work by weeks. By the time the request lands, the customer has moved on and the message reads as a bill follow-up.
The fix in every case is the same: trigger on the completion event that most closely tracks the customer’s actual experience, and put the delay on a custom value so it can be tuned per client rather than per rebuild. In a law firm that event is a matter closing and the right delay is longer; in a cleaning company it is the visit finishing and the right delay is a couple of hours.
Building it once instead of per client
If you run more than one client, this belongs in a snapshot rather than being rebuilt each time. The pieces that stay identical are the pieces worth centralising: the branch structure, the timing intervals, the escalation path, the reporting.
The pieces that vary — business name, review links, the wording, the interval — are custom values. That split is the whole discipline in how to create a GoHighLevel snapshot, and getting it right here is what lets you change the cadence across twenty accounts in one push rather than twenty edits. The push mechanics are in how to update a GoHighLevel snapshot.
In our own library, this is two of the nine components rather than one, and the split is deliberate: review harvesting is the trigger and capture at the moment a job completes, and review automation is the ongoing engine — the cadence, the multi-platform links, the escalation path and the reply handling. They are a trigger and a machine, and treating them as one thing is why so many implementations have a request and no follow-through.
Every snapshot in the library ships both, written in that vertical’s own vocabulary — post-job for a cleaning service, post-treatment for a spa, post-visit for a dental practice. If you would rather it were installed and tuned for you, snapshot installation covers it, and full white-glove onboarding covers the account it sits in.
Whatever you build: ask the question first. Everything else in this article is detail, and that one decision is the system.