The reply matters more than the review.
A complaint sitting alone on a page is one customer’s bad day presented as fact. The same complaint with a calm, specific reply underneath it is a business that pays attention, and the person reading it in three months is choosing you partly because of that reply.
The difference between those two outcomes is whether anybody noticed in time.
Why Google’s own emails are not enough
Google does email the profile owner when a review arrives. Those emails go to whichever account owns the profile, which is frequently the address of whoever set it up, which is frequently somebody who left.
They also look like every other Google notification, so they get filtered into a folder with the monthly performance summaries and read on the same schedule, which is never.
Checking on a schedule and messaging yourself where you actually look is more reliable. And it gives you the count as a series over time rather than a notification you dismissed.
What you may keep, and what you may not
The Places API returns up to five reviews. It also returns two numbers that are aggregates rather than content: the average rating, and the total review count.
The Maps Platform terms allow only temporary caching of Maps content, no more than 30 calendar days, and forbid mass downloads or bulk feeds. Keeping a permanent archive of review text in a spreadsheet is not a comfortable fit with that.
So this build watches the count. When it goes up, something new has been written. The alert tells you that, gives you the current rating, and links you to the page.
You then go and read it, in the browser, where Google intends you to. Which takes ten seconds and is what you were going to do anyway before writing a reply.
That constraint turns out to make a better tool. An alert carrying the review text tempts you into replying from the notification, and a reply written without seeing the profile, the reviewer’s history or the other reviews around it is usually worse.
Finding your place ID
Google publishes a Place ID Finder tool. Search your business, click the pin, copy the ID. It looks like ChIJ... and it never changes, which is why it is the one field the terms let you keep forever.
Store it somewhere in the workflow. You will not need to look it up again.
The build, seven nodes
1. Schedule Trigger. Every four hours during the working day is plenty. Reviews do not arrive at a rate that rewards checking hourly, and every run is a billed request.
2. HTTP Request, called Place Details. Ask for three fields and no more:
GET https://places.googleapis.com/v1/places/YOUR_PLACE_ID
X-Goog-Api-Key: YOUR_KEY
X-Goog-FieldMask: rating,userRatingCount,googleMapsUriPlaces API (New) bills by the fields you request, so the field mask is a cost decision as much as a tidiness one. Three fields is the cheapest useful request there is.
3. Google Sheets, Get Rows. Read the last recorded count. One row, two columns. A sheet is enough for this and needs no database.
4. IF node, called Changed. Continue only if the new count is higher than the stored one.
Higher rather than different, deliberately. Review counts occasionally go down, when Google removes something as spam or a reviewer deletes it. That is not an event you need waking up for, and treating any change as new produces alerts about reviews that no longer exist.
5. Code node, called Message. Compose the alert. Include the change in count, the rating now against the rating before, and the link.
The rating movement is the part that tells you how to feel before you click. Count up by one with the average unchanged is somebody happy. Count up by one with the average down two tenths is a one-star, and you would like to know that before you open it on your phone in a car park.
6. Telegram, Slack or ntfy. Somewhere with a push notification. This is one of the few alerts genuinely worth interrupting somebody for, because its value halves every day it goes unread.
7. Google Sheets, Update. Write the new count and rating back. Do this after the alert has gone, not before, or a failed send leaves you having recorded a review you were never told about.
The first hour
Read the whole review, then look at what else the person has written if their profile is public. Then wait twenty minutes before writing anything.
The reply is for the next reader, not for the reviewer. Two or three sentences, name the specific thing, say what you have changed if you have changed something, and offer to sort it off the page. No paragraph about how seriously you take feedback, no defensiveness, no arguing about the facts even when you are right, especially when you are right.
For a good review, reply too, briefly. It takes fifteen seconds, it makes the page look attended, and people who get a reply leave another one somewhere else.
Do not automate the reply
It is the obvious extension and it is the one place in this whole library where automation would actively damage a business.
A public reply under your name, read by every future customer, written by something that has not spoken to the person and does not know what happened. Every generated review reply reads like a generated review reply, and enough people have now seen them that it is recognisable at a glance.
The automation is worth it because reading twelve review pages a week is not a good use of anybody’s time. Writing the reply is the entire job, and it takes two minutes.
Published 28 August 2026. Written by the people who run this sort of thing for clients, on n8n, including our own lead pipeline.
Next in knowing when something breaks: The heartbeat that says your automations still run. Or go back to all 4 in this category.