The call usually comes from a manager, and it is usually some version of: Google is telling people we don't do takeaway.
Or that the restaurant is cash only. Or that there is a long wait. Or, in the worst version we have seen, that a venue is closed — when it is open, staffed, and watching an empty dining room.
The instinct is to find the sentence and correct it. There is no way to do that. An AI-generated summary is not a field you own, there is no edit box behind it, and no support path treats "the summary is wrong" as a ticket in its own right. Understanding that early saves you a frustrating afternoon.
What you have instead is three moves, and they have to happen in that order, because the first one stops existing the moment anything changes.
Move one: capture it before it moves
Summaries regenerate. The sentence you are angry about may well be gone tomorrow, which sounds like good news until you are trying to explain to a franchisor, a solicitor or a support agent what it said.
Capture, in this order:
- A full-screen screenshot including the search bar, the URL and the system clock. A cropped screenshot of a sentence is worth very little; it could have come from anywhere.
- The device and the route. "Android Chrome, searched restaurant name + town, Maps app result" is a different surface from a desktop search, and the summaries are not always the same. Write down which one you used.
- A second capture from a different device, ideally on mobile data rather than your own wifi, and not signed into the business account. This is the difference between "my phone shows this" and "guests are seeing this".
- The time. Not the date. If you ever need to argue that a wrong closure claim cost you a Friday service, the hour matters.
Two minutes, and it is the only part of this that cannot be done later.
Move two: change what the summary is made of
A summary is downstream of things you do control. It does not invent claims; it compresses the material it has. So the question stops being "how do I fix the sentence" and becomes "which input produced it", which is a question with answers.
Work through these in the order of how often they turn out to be the cause:
Hours and special hours. By a wide margin the most common source of a false claim about being closed, and the one that does the most damage. A missing bank holiday entry, a temporary closure left in place, or regular hours that were right eighteen months ago. Hours deserve their own routine, because this is the failure that produces the review from a guest who never ate your food.
Attributes. Service options, dine-in, takeaway, delivery, payment methods, accessibility. An unset attribute is not read as "unknown" by everything downstream — it frequently reads as absent. A venue that has taken cards for six years and never ticked the box is quietly described as cash only.
Menu links. Open yours on a phone, signed out. A link to a PDF that will not render, a page behind an app wall, or a menu from a previous season all generate the same guest experience and the same unhelpful conclusions about what you serve.
Repeated review language. If eleven reviews in three months describe a forty-minute wait, a summary reporting long waits is not malfunctioning. It is reporting. That is not a profile problem and no amount of escalation will shift it — the fix is operational, and the phrasing in your reviews is the measure of whether it worked. Where those sentences come from is worth understanding properly.
The useful discipline is to settle which of those two categories you are in before you do anything else. Is the summary factually wrong, or is it accurately describing something you do not like? Those need completely different weeks.
Move three: document, then escalate narrowly
If the claim is factually wrong and you have corrected the inputs, you have a case worth raising. Escalate on the specific, verifiable error — never on the summary as a whole.
This works:
Our profile shows open until 22:00 Friday. A search for "[restaurant] [town]" on mobile displayed "Temporarily closed" at 19:40 on 12 September (screenshot attached, second device attached). Hours were last edited 3 August and are correct. Requesting review of the closure status on this listing.
This does not:
Google's AI summary of our restaurant is inaccurate and unfair and is damaging our business.
The first is a discrete claim with evidence and a date. The second cannot be actioned by anyone, however sympathetic.
The internal log
Keep one file, appended to rather than rewritten. Four columns is enough:
| Date and time | What it said | What was wrong | Action and outcome |
|---|---|---|---|
| 12 Sep, 19:40 | "Temporarily closed" | Open until 22:00; hours correct since 3 Aug | Screenshots filed, reported 13 Sep, cleared 16 Sep |
The log earns its keep in two situations. The first is a repeat: the third time the same error appears, a pattern with dates is a far stronger report than another lone screenshot. The second is anyone asking why a week's revenue dipped — a franchisor, an accountant, a partner. "Google said we were closed" is an anecdote. The log is a record.
What not to do
Do not tell guests the summary is wrong in your review replies. Replies are read by people deciding whether to visit, and a reply arguing with Google reads as a venue in a dispute. Fix the input; say nothing publicly.
Do not ask staff or regulars to post reviews to drown it out. It does not work — a burst of favourable reviews is exactly the pattern that gets filtered — and it creates a second problem on top of the first.
Do not rewrite your whole profile at once. If you change hours, attributes, menu link, photos and description on the same afternoon and the summary improves, you have learned nothing about which one mattered. Change the likely cause, note the date, wait.
Do not expect same-day movement. Corrected inputs take time to be reflected. Deciding after thirty-six hours that the fix failed, and changing five more things, is how operators end up with a profile nobody understands.
The part that is genuinely unfair
You are accountable for a sentence you did not write, cannot edit, and may not even be able to see from where you are standing. That is a real asymmetry and it is reasonable to find it irritating.
The practical response is unglamorous: keep the inputs correct so there is nothing true to misread, check what a signed-out phone sees often enough that you hear about problems from your own routine rather than from a manager, and keep the log. OMMU watches profile fields and the repeated nouns in your reviews and flags when either moves, which is how most of these get caught before anyone rings. A monthly diary note and a spare phone does the same job.