The review-collection system at scale

A project has an end date. A system runs indefinitely. Operators who run review collection as a project hit a quarterly milestone, declare success, and stop — and the velocity drops to zero. Operators who run it as a system pick a baseline cadence (e.g. 4 reviews per week per location) and never let it fall below that line. The cadence is the metric; everything else is implementation.

If your customer data lives in three places — Stripe, your CRM, and a Google Sheet — your review system has three fragile dependencies, three deduplication problems, and three places where a customer can fall through. Pick one canonical customer record and route everything through it. Most operators pick their CRM or PMS; some pick Stripe. The choice matters less than the discipline of having one.

Every automated review request has four parts: the trigger event (job complete, invoice paid, appointment finished), the action (send a request), the channel (SMS, email, in-app), and the fallback (what runs if the primary channel fails or doesn't engage). Designing in this shape from the start saves you from the scramble when one channel breaks. Write each new automation as a 4-row spreadsheet before you build it.

Most automation tutorials cover the happy path: customer completes service, request fires, review lands. The harder case is the no-show: customer cancels, customer reschedules, customer's service is partial, customer gets a refund. The system has to know which of these still warrant a request and which don't. Map every status transition in your CRM/PMS to one of three actions: send, hold, or skip permanently.

Four metrics that matter. Velocity: reviews per location per week. Conversion: percentage of requests that turn into posted reviews. Edit rate: percentage of resolved 1-star reviews that get edited up (covered in /guide/respond-to-bad-reviews). Response rate: percentage of reviews that have an owner reply within 48 hours. Track all four monthly. None individually tells the whole story; together they do.

Set a 30-minute slot every Monday morning for the owner (or whoever runs review-ops) to read every review from the prior week — good, bad, neutral. Two outcomes: any unanswered review gets a reply that week; any operational pattern that surfaced (multiple complaints about wait time, multiple compliments on the same staff member) gets surfaced to the team. The ritual is what keeps reviews from becoming background noise.

Once a quarter, audit the actual system — not just the metrics. Pull a sample of 20 customers from the prior quarter and trace each one through your system: did the trigger fire, did the request send, did the customer engage, was the follow-up correct. The audits surface broken integrations, stale templates, and edge cases the metrics dashboard misses. An hour per quarter; catches problems that compound for months otherwise.

Review systems that work are boring. Same templates, same cadence, same channels, year after year. The instinct to redesign — new copy! new channels! new automation! — is almost always counterproductive. Stable systems compound; redesigned systems lose their tuning. The right cadence for system changes is yearly, not monthly, and only when the metrics justify it. Boring is the goal, not a problem.

The most reliable trigger isn't 'invoice paid' or 'appointment confirmed' — it's the completion event. Job marked done in your dispatch system. Service ticket closed in your CRM. Cart shipped in your e-commerce platform. Triggering on payment fires too early for service businesses (the work hasn't started yet); triggering on confirmation fires way too early. Always trigger on the event that means the customer has actually experienced the service.

Every automated review request needs at minimum: customer first name, contact channel (email or phone), service date, location ID. Without these four, you can't personalize the request, deliver it, time it correctly, or route it to the right Google profile. Audit your customer-creation flows to make sure all four are captured at intake — not in a 'nice to have' field, but as actual required validation.

{
  "customer_id": "abc123",         // Internal ID, used for dedup
  "first_name": "Sarah",            // For personalization in templates
  "contact_channel": "sms",         // "sms" or "email"; never "either"
  "contact_value": "+15551234567", // E.164 phone or RFC 5322 email
  "service_date": "2026-05-06T15:30:00Z", // ISO 8601 with timezone
  "location_id": "loc_main",        // Maps to Google Business Profile
  "opt_in_at": "2026-04-22T10:14:00Z" // TCPA consent timestamp; null = no SMS
}

If a customer gets a portal message, an SMS, and an email — all firing from different systems with no shared state — they read it as spam. Deduplication needs to live at the system level: one canonical 'last review request sent' timestamp per customer, checked before any channel fires. The check is cheap; the cost of getting it wrong is unsubscribes and complaints.

Network failures, webhook retries, and queue reprocessing all create the risk of double-firing. Every review-request automation needs an idempotency key — typically the customer ID + the service event ID — so retries are safe. The dumbest version: a database table with a unique constraint on (customer_id, event_id). The retry inserts; if it fails the unique constraint, you know you already sent.

Most automation tutorials use server time. Most customers don't live in your server's timezone. A request scheduled for '6 PM' in a Pacific-time customer's local context goes out at 9 PM their time if your server is on Eastern. The fix: store the customer's timezone (or infer from area code / billing zip), schedule sends in their local time, and avoid 8am / late evening windows in the recipient's clock.

Even when triggering on the completion event, build in a 24-hour delay before the request fires. Edge cases: the job was marked complete prematurely, the customer reported an issue overnight, the order was shipped to the wrong address. The 24-hour buffer catches these without meaningfully reducing conversion (customers still write reviews 24 hours after service when prompted). The cost of accidentally asking a customer for a review during a complaint resolution is much higher than the conversion lift from immediate firing.

When a customer replies 'STOP' to an SMS or hits the email unsubscribe link, the opt-out has to propagate everywhere — not just to the channel that received it. A customer who opts out of SMS but still gets review-request emails files a complaint. Build a single 'review-request opt-out' flag on the customer record; check it before any channel fires. TCPA requires SMS opt-out be honored within 24 hours; treat it as instant.

If Google's review team ever flags your collection pattern, the documentation you'll need: timestamped event logs showing which customers got which requests when, opt-in records for SMS-eligible customers, and proof that opt-outs were honored. Keep at least 24 months of logs (more if your jurisdiction requires it). Most operators don't have any of this until the day they need it. Build the logging early; it's a one-day project that prevents an existential one.

Your primary trigger source — Toast, ServiceTitan, Stripe, your CRM — will go down. Plan for it. Build a manual-trigger fallback: a dashboard view that shows 'eligible for review request, not yet sent' with a one-click send button. The fallback runs once a week or so during normal operations, but becomes the lifeline when the automation breaks. Most operators discover this need only after the first multi-day outage.

Automation runs in the background; humans verify it works. Build a daily summary email that goes to the operator: 'Yesterday we sent 47 review requests across 3 locations. 3 deliveries failed (see logs). 12 customers replied to SMS with a non-STOP message — flag for human review.' The summary is the verification layer. Without it, automation can run incorrectly for weeks before anyone notices.

Don't aggregate. Each physical location, each service area, each franchise gets its own Google Business Profile. The local-pack ranking algorithm treats every profile independently — there's no benefit to combining them, and the dilution of pooled reviews actively hurts smaller locations. The discipline is unambiguous: one location, one profile, one review URL.

Every Google Business Profile has its own review URL — the format is https://search.google.com/local/writereview?placeid=<PLACE_ID>. Each location gets its own. Never share a single review link across multiple locations; the reviews land on whichever profile the link is registered to, leaving the others starved. SignalRoute routes by location automatically; if rolling your own, encode the location in the URL path or token.

When the customer scans a QR or clicks an SMS link, the system needs to know which location they're reviewing. Three patterns work: location-coded short URLs (yourbusiness.com/review/r-loc1), location encoded in a per-send token (/l/<token> where token resolves to a location), or location detected from the customer's service record at request-time. The third is the most robust; the first two are simpler to build.

Staff who work at multiple locations (techs who cover multiple service areas, multi-location stylists, traveling consultants) create a routing edge case: which location does their work get attributed to? Two options: tag the location on the service record (best — captures actual service location) or default to the staff member's home location (easier — but creates attribution drift). Pick one; document it; train the team on it.

Reports that aggregate review counts across locations hide the per-location story you actually need. A 5-location chain with one location at 200 reviews and four at 5 reviews each looks 'healthy' on the aggregate but is failing at four out of five locations. Always report per-location for the metrics that drive ranking decisions; aggregate views are for executive summaries only.

Every location gets its own targets for velocity, conversion, edit rate, and response rate. The targets can be uniform or tiered (newer locations vs. mature ones), but they're set at the location level. When a location drifts below target, the alert fires for that location specifically — not a roll-up dashboard that an underperforming location can hide inside of.

When a customer interacts with multiple locations (e.g., books at Location A, picks up at Location B), which location asks for the review? The right answer is usually the one that handled the substantive customer experience — typically pickup or service location, not the booking location. Document your rule and apply it consistently; otherwise reviewers will mention Location A but the review lands on Location B's profile, which confuses readers.

In franchise systems, the review-collection compliance posture has to hold at every franchise location — not just at corporate. One franchisee running an incentive contest (illegal under FTC § 465) puts the entire brand at regulatory risk. Build the compliance rules into the corporate-issued tooling so franchisees can't accidentally cross the line; provide a compliance one-pager every new franchisee signs at onboarding.

Sometimes a single Google profile covers what's actually two distinct service experiences (e.g., a restaurant that added a takeout window with different hours, or a service business that opened a satellite location at the same address). When the customer experience diverges enough that reviews of one don't represent the other, split the profile. The friction is real (Google verification, separate management) but the alternative is a profile where reviews contradict each other and customers can't tell which experience they're reading about.

In a team larger than 5 people, the owner can't train everyone individually — but the owner has to train the people who do. Designate 1-2 senior staff per location as review-collection trainers; the owner runs the same training session with them quarterly so the message stays consistent. The trainers then onboard new hires. The pattern keeps the founder's voice in the program even at 50+ employees.

Telling staff 'ask for reviews after every service' produces 10% compliance. Role-playing the verbal ask in 1-on-1 practice produces 70%+ compliance. The mechanism is muscle memory, not knowledge. Spend 15 minutes with each new hire in their first week practicing the script with feedback. Repeat at the 30-day mark. The compounding effect across a team of 20 is enormous.

Round 1 (5 min): Trainer plays a happy customer. New hire delivers the ask. Trainer responds yes — new hire confirms the link will arrive shortly. Trainer gives 30 seconds of feedback on tone and word choice.

Round 2 (5 min): Trainer plays a hesitant customer. New hire delivers the ask. Customer says 'I'm not really a Google reviews person.' New hire responds gracefully without pushing. Trainer gives feedback.

Round 3 (5 min): Trainer plays a customer who had an issue. New hire identifies that this isn't the moment to ask, switches to the recovery conversation, and offers to follow up directly. Trainer gives feedback.

Debrief (1 min): What was easiest? What was hardest? What do you want to practice again next week?

Record a short (60-90 second) training video showing the ask done well and a separate one showing it done poorly. Share with every new hire on day one before any role-play. Visual learning compresses an hour of explanation into 90 seconds; the contrast between good and bad examples teaches faster than either alone. Refresh the videos yearly so the cultural references don't age into distraction.

30 days after hire, sit down with the new staff member and review the reviews mentioning them by name (if any) and the reviews of customers they served. Two purposes: catch any pattern issues early (multiple complaints about the same staff member's handoff, or compliments worth amplifying), and reinforce that the review program is real and visible. The 30-day review is the differentiator between 'we sent them to training' and 'this is operationally important.'

Most review-collection regression isn't about staff ability — it's about the verbal-ask habit decaying without reinforcement. Build a monthly 1-on-1 check-in with managers where each direct report reports their personal asks-per-shift average. The number doesn't have to be perfectly accurate; the act of reporting it surfaces drift. Staff who report 'maybe 2-3 a shift' know they're below par; staff who report 'every customer' calibrate against the team.

Trigger a retraining session when a staff member's per-customer review-conversion rate drops 30%+ below their personal baseline for two consecutive weeks. The trigger isn't the absolute number (different staff have different customer mixes) — it's the personal-baseline drift. Most drift traces to a single change (a new product line, a workflow shift, a personal stressor) that 15 minutes of recalibration fixes; the data just helps you see it before the customer does.

Tying staff bonuses to review counts creates the incentive to ask in ways that violate Google's policy and the FTC rule (e.g., offering customers something off the bill 'so we can get a 5-star review'). The compliant alternative: bonuses for the asking behavior, not the review outcome. Track whether staff verbalize the ask; reward consistency, not conversion. The legal exposure of outcome-based bonuses isn't worth the marginal lift.

If your CRM or PMS lets you tag the staff member responsible for each customer interaction, build a per-staff review-conversion report. The data isn't for blame — it's for training. Staff at the top of the list get studied; staff at the bottom get coaching. Most teams have a 3-5x spread between best and worst; closing half that gap is one of the highest-ROI ops moves available.

Build a one-page daily-glance dashboard with three numbers: reviews collected yesterday, average rating of those reviews, and unanswered reviews older than 48 hours. Three numbers. No charts. The owner or review-ops lead checks it once per day at the same time. Anything outside the normal range gets a 5-minute investigation that day; everything within range gets ignored. The discipline is the dashboard's value, not the design.

Track reviews collected per week per location as a 13-week rolling chart. The shape of the line matters more than any single week's number. Steady-or-rising lines mean the system is healthy; a sustained decline (3+ weeks below the 13-week average) means something operational has broken. Most operators spot the decline 2-3 weeks earlier on the chart than they would have noticed it from the average rating alone.

Group reviews by the month they were posted. Look at the average rating per cohort over time — not just the rolling average. Sometimes a recent decline in average rating isn't a recent quality problem; it's that an old great cohort is getting drowned out by a recent mediocre one (or vice versa). The cohort view distinguishes 'we've been getting worse' from 'the historical mix changed.'

Per-staff conversion data shows a 3-5x spread between best and worst askers. Use the data to train, not to penalize. Schedule shadowing sessions where lower-converting staff observe higher-converting staff during real customer interactions. The lift from one shadowing session is typically larger than three months of generic training material.

Multi-location operators benefit from a single visualization that shows every location's velocity, conversion, and average rating side-by-side. The locations that are off-pattern jump out instantly — the one with high conversion but low velocity is operationally weak; the one with high velocity but declining rating is collecting reviews but losing customers. The heatmap surfaces these in a glance.

Tag every review with the request channel that drove it (SMS, email, in-person ask, QR scan). After 90 days, pull the conversion by channel. Most operators discover that 60-80% of reviews come from one channel and the rest of the channels are theater. The action: invest in the dominant channel; consider deprecating the long tail. The data is uncomfortable but actionable.

Track the percentage of resolved 1-star reviews that get edited up (covered in /guide/respond-to-bad-reviews chapter 6). The metric reflects recovery quality. Below 20% means your recoveries close the ticket but don't actually satisfy the customer; above 40% means your recoveries are excellent. Track monthly; trend up is the goal.

Define a service-level agreement for owner replies: e.g., negative reviews replied to within 24 hours; positive reviews within 7 days. Track compliance weekly. Replies that miss the SLA get auto-escalated to the owner's inbox the morning of the deadline. The SLA discipline keeps replies from drifting into 'we'll get to it' territory; auto-escalation prevents a single busy week from becoming a 30-day backlog.

Three rough volume thresholds where automations break: 50/month (manual triggers stop scaling), 500/month (deduplication and TCPA opt-out edge cases surface), 1,500/month (rate limits, deliverability throttling, and reply-volume saturation hit). Each threshold needs a different solution: trigger automation at 50, deduplication discipline at 500, dedicated review-ops headcount at 1,500. Knowing which threshold you're at saves you from solving the wrong problem.

At ~1,500 customers per month, owner-reads-every-review stops being feasible — but the ritual still has to happen. The pattern that scales: hire a dedicated review-ops person whose job is exactly the work the owner used to do. Read every review, draft replies, escalate negatives to the owner for sign-off, run the weekly review-of-reviews meeting. The hire is full-time at ~3,000 customers/month, half-time at 1,500/month, and contractor-based at 500-1,500/month.

At 5,000+ customers/month, review-ops becomes its own team. The pattern: one owner-of-the-program reporting to operations, with 2-4 reviewers handling daily reads and reply-drafting per shift. Replies are drafted by the team and sent under the owner's signature for negative reviews; positive reviews go out under the team-member name. The owner spot-checks 10% weekly. This separation lets the program scale while keeping the owner-voice signal where it matters.

At very large scale, some operators outsource positive-review reply drafting to virtual assistants. The pattern works only with: a tight style guide (60-90 words, sign with first name, no boilerplate), spot-check sampling (owner reviews 10% weekly), and explicit boundaries (negatives never go to the VA — they always come to the owner). Done well, it scales 10x without losing voice. Done poorly, it produces customer-service-bot replies that hurt the brand.

At low volume, every review matters individually. At 5,000 customers/month, individual reviews matter less and the aggregate pattern matters more. The temptation is to optimize purely for volume — but the brand-voice consistency in replies, the response-time SLA, and the recovery quality on negatives all matter more, not less, at scale. Quality discipline is the moat; quantity at the cost of quality is a liability.

When 4 different reviewers draft replies, they sound like 4 different people unless you build the voice discipline explicitly. The pattern: a 1-page voice guide with 5-10 example replies labeled 'use this style' and 5 labeled 'avoid this style.' New reviewers read it on day one and reference it during drafting. Spot-check sampling catches drift; quarterly recalibration sessions reset the standard.

Past a certain point — usually around 8,000-10,000 reviews per location — incremental reviews stop moving the needle on local-pack ranking and stop influencing customer perception. The 8,000th review doesn't add what the 80th did. Most operators don't ever reach this ceiling; the ones who do should redirect the review-ops headcount to higher-leverage work. Reviews are an asset, but every asset has diminishing returns. Know what your ceiling looks like.