Manage every Google review from one dashboard

A new review is not answered the moment it appears. By default the system waits half an hour, and that delay is configurable.

Two reasons. First, a reply posted seconds after the review reads as automated to anyone paying attention, and the point of replying is to look present, not mechanical. Second, reviews are occasionally edited or removed shortly after posting; answering a review that then changes leaves your reply attached to different text than the one you responded to.

The delay is measured from the review's own timestamp, not from when the system noticed it. That distinction matters when a sync brings in a batch of older reviews: those are eligible immediately rather than being held for another half hour each.

You choose the window: half an hour, one hour, six hours or twelve. Half an hour is a hard floor rather than a default you can lower — the setting refuses anything below it, and older accounts that once held a shorter value are raised to it. On a location taking a handful of reviews a month, a longer window costs nothing and reads more naturally. On one taking dozens a day, a long window just grows the unanswered pile. The right value follows your incoming review rate, so treat it as a setting you revisit, not one you set once.

You set a minimum rating. Reviews at or above it are eligible for automation; everything below it is left for a person.

Be deliberate about this number. The default is permissive, which means a fresh account will auto-reply across the full rating range until you raise the bar. For most businesses the useful setting is to automate the positive end and keep one-star and two-star reviews manual — those are the ones where a generic reply does measurable damage, and where a real response can turn the situation around.

The threshold is a filter, not a mute. Reviews below it stay in your inbox flagged as unanswered; they are simply excluded from the automated queue.

The daily reply limit applies to each location separately. A workspace with four branches gets the full daily allowance for each of them.

This sounds like a detail and is not. When the quota is shared across an account, one high-traffic branch consumes the whole day's budget and the remaining locations go silent — and because the failure is a quota check rather than an error, nothing surfaces in the interface. Per-location counting removes that class of silent starvation.

It also makes the limit legible. "Fifteen replies per day" means fifteen for this branch, which is a number you can reason about against your actual review volume.

When several locations have pending replies, they are processed in order of least-recently-served: the location that waited longest goes first, and one that has never been served goes before all of them.

Without this ordering, a stable sort by identifier or creation date means the same location is always first. If the run hits a time limit, the locations at the end of the list are never reached — not once, but every single cycle. Round-robin turns "never served" into "served later".

A location's turn only advances after it is actually served, so a run that ends early leaves the untouched locations at the front of the queue for the next pass.

Before generating a reply, the system claims the review by writing a timestamp to it, and that claim is part of the same conditional update that selects it. If two processes attempt the same review, only one write succeeds — the other finds the row no longer matching and moves on.

This matters because the application runs as multiple processes. A naive "find unanswered reviews, then reply" loop lets two workers select the same review in the same instant and post two replies to Google, which is visible to your customers and cannot be cleanly undone.

Claims expire. If a process dies mid-reply, its claim goes stale after fifteen minutes and the review becomes eligible again. Without expiry, a single crash would leave that review permanently locked and quietly unanswered — the kind of bug that never produces an error, just a gap.

If replying to a specific review fails three times, that review is dropped from the automated queue and the reason is recorded alongside the attempt count.

The important part is how it is dropped. An earlier approach created a fake sent-reply record as a tombstone, which removed the review from the queue but also made it look answered — in the dashboard it appeared handled while Google still showed no reply. The state now lives in its own field: the review is still counted as unanswered, it has simply left the automated flow.

That distinction is what lets you find these. A review that automation gave up on is usually telling you something specific — a permissions problem on that location, a reply the API keeps rejecting — and it stays visible as work to do rather than disappearing into a false success.

"Auto-reply is on but nothing happened" is the hardest complaint to diagnose, because a queue that selects nothing looks identical to a queue with nothing in it.

So when pending reviews exist but none qualify, the run records why, broken down by cause: how many fell below the rating threshold, how many are still inside the delay window, how many were dropped after repeated failures, how many are claimed by another process right now.

That single line turns an unanswerable question into a settled one. Usually the answer is mundane — the threshold is higher than the incoming reviews, or everything is still waiting out the delay — and knowing which one it is takes seconds instead of an afternoon.

After a reply is accepted, the system re-reads the review from Google to confirm the reply is actually attached. This check has a quirk worth understanding: Google's read API can lag one to three minutes behind a successful write.

So a reply can be genuinely published while verification still shows nothing. Treating that as a failure and retrying would post a second reply — the exact duplicate the claiming system exists to prevent. Instead, an accepted write is recorded as sent and the next sync reconciles the true state from Google.

The same lag explains a symptom you may have seen elsewhere: a review that flips between answered and unanswered on refresh. The reply status is derived from both Google's field and our own sent records, so a lagging read does not undo what was already sent.

When a review gets answered, the notification about it is removed — including when you replied from Google's own dashboard rather than here. The next sync sees the reply and clears the reminder.

This is a small thing that decides whether the notification bell stays useful. A bell that keeps showing work you already finished gets ignored within a week, and then it stops working as a signal for the things that do need attention.