The email came in at 11pm on a Saturday. A guest at one of our units had written a two-star Yelp review that afternoon. It mentioned a wait time, a cold entree, and a server they described as dismissive. It was still unanswered. The general manager saw it in her Sunday morning scroll, cross-checked the ticket, and wrote a careful reply on Monday afternoon. Fifty-six hours from post to response.
The review had by then been read a few hundred times. The three-star average on that unit had ticked down. And the guest, when we reached out separately, told us she would have been fine with a same-day acknowledgment. What lost us the customer was not the wait or the entree. It was the silence.
Across a five-unit group we were getting somewhere between 60 and 100 new reviews a week between Yelp, Google Business Profile, Resy, and OpenTable. Two managers were handling triage manually. It was taking them roughly three hours combined, and the response window on the ones that mattered kept slipping past 48 hours. The math was not going to get better with more volume.
What the pipeline actually does
The system we built is small. Four moving pieces, all off-the-shelf, all glued together by a person who is not an engineer. Total build time was about two weekends. Monthly tool cost lands under a hundred dollars for a five-unit group.
Fig. 1 · From four review platforms to one manager decision.
Zapier watches four sources: Yelp via a paid connector, Google Business Profile through its native trigger, Resy and OpenTable through their partner exports. Every new review lands in one row of an Airtable base within about two minutes of posting, tagged with the location, the star rating, and the raw text.
Airtable fires a webhook to a Claude prompt that returns four fields: a normalized sentiment score from minus one to plus one, a primary theme cluster from a fixed list of twelve, a severity flag (green, amber, or red), and a first-draft owner response written in the voice we defined in the system prompt. Those four fields land back in the same Airtable row inside about seven seconds.
A second Zap looks at the severity flag. Red and amber rows push a Slack message to the location channel with the review text, the classifier output, the draft response, and a link back to Airtable. Green rows batch into a once-a-day digest that lands in Slack at 8am the next morning.
The general manager opens Slack, reads the review, edits the draft in Airtable if they want to, and posts the reply themselves from the native platform. That last part matters. Nothing posts through the pipeline. The pipeline drafts. The human ships.
What the classifier does well
After eight weeks of tuning, the classifier is right about the theme cluster roughly 94 percent of the time. The categories it handles cleanly:
- Service pace. Slow seating, slow ordering, slow food, slow check drop. The language pattern is stable across platforms.
- Food temperature. Cold, lukewarm, arrived at the table wrong. Almost always tied to expo or a runner problem, which is useful to know at the kitchen debrief.
- Ambiance and noise. Music too loud, too dim, too bright. Cleanly separated from service complaints, which the human eye sometimes conflates.
- Cleanliness. Restrooms, table wipes, glassware. Small volume but high severity when it comes up.
- Value and portion. The distinction between "expensive" and "not worth it" matters, and the model separates them well.
- Reservation and hosting. Especially on Resy and OpenTable, where the friction is often before the guest even sits down.
Sentiment scoring is accurate on the clear cases. A one-star with a paragraph of complaints scores minus 0.9. A five-star with a compliment about the server scores plus 0.8. Those we trust.
What it still gets wrong
The classifier is not good at sarcasm. A review that opens "loved the wait" is not usually loving the wait. It is also not good at reviews that mix a five-star meal with a three-star parking experience, because the star rating collapses two very different signals. And it is weakest on culturally specific complaints, particularly around service norms in an ethnic concept, where a guest may frame a warm interaction as intrusive or a formal one as cold. Those still need a human first read.
The other blind spot is the sincere-sounding false accusation. A guest can write a fluent, calm, high-detail review describing a scene that did not happen. The AI has no way to know. The manager, cross-checking the ticket, the reservation log, and the camera timestamp, usually can. That is one of the reasons the human stays in the loop.
The LLM is a fast reader with excellent grammar and no memory of what actually happened on the floor last Tuesday. Treat it that way.
The severity flag saved us twice
The red flag exists for one reason: reviews that mention foodborne illness, allergy reaction, injury, or discrimination. Those never get a templated response. Those get a phone call from the operator, a case number opened with the platform, and a documented followup within 24 hours.
The classifier is tuned to flag conservatively. We would rather have three false reds a month than miss one real one. In practice we get about one or two true red reviews a month across the group. The classifier catches them within five minutes of posting, which means the operator is calling the guest before the guest has stopped thinking about the meal.
Two of those calls in the last six months turned into resolved cases that would otherwise have ended in health department complaints or public escalation. Neither is a scale story. Both are the reason the flag exists.
Never let AI post unedited
I want to be direct about this because it is where most operators get in trouble. A large language model will happily agree with a false accusation, promise a refund the operator will not honor, apologize for something that did not happen, or use a phrase in a language it does not natively read that comes out condescending. It will also, occasionally, write a beautiful three-paragraph response that reads like corporate PR and lands worse than silence.
Every reply gets a human read before it posts. That guardrail does not move for volume, for speed, or for cost. If the pipeline generates a hundred drafts a week and the manager only ships forty, the other sixty are fine as raw material. The drafting was cheap. The posting is not.
The prompt has explicit rules in it: never promise a refund, never quote a menu price, never name a staff member, never claim a policy that has not been checked, and never use the words "unacceptable" or "we failed you" or any phrase that sounds like a lawyer wrote it. The manager can still say those things. The draft will not.
The manager review loop
The manager opens Airtable once at the start of the shift and once at the end. Amber and green reviews get read in a batch, edited in place, and posted. Red reviews were handled in real time and are already closed by the time the review pass starts.
During the review pass, if the theme tag is wrong, the manager fixes it. Those corrections feed a running examples file that gets pasted back into the classifier prompt weekly. Classification accuracy on the theme clusters climbed from about 82 percent in week one to around 94 percent by week eight. It is still climbing slowly. The prompt is a living document that a person maintains, not a one-time setup.
The manager also tags a review with the shift it belongs to, so the kitchen and floor debriefs on Monday can pull "every service-pace complaint from last week" in one Airtable view. That closes the loop back to the operating floor, which is the point of the whole exercise. Reviews that never make it to the debrief change nothing.
The numbers, six months in
Some real figures from the group across the first two quarters after we shipped this:
- Median time from review posted to owner response, on reviews under four stars: 3.9 days before, 6.5 hours after.
- Percent of sub-three-star reviews with a personal owner reply inside 24 hours: 34 percent before, 92 percent after.
- Manager time spent on review triage per week: 3.1 hours before, roughly 22 minutes after.
- Trailing 90-day rating change across the five units: plus 0.2 stars on three units, flat on one, minus 0.1 on one (that one has a service problem the pipeline cannot fix).
- Red-flag reviews handled inside one hour: 100 percent, up from a prior baseline we cannot measure because we were not tracking it.
The rating movement is the softest number of the five. Ratings move slowly and for many reasons. What I trust more is the response time cut, because that is a lever the operator directly controls, and it is the one guests told us mattered.
What I would do differently if I were starting over
Three things. First, I would build the Airtable base and the Slack loop before I built the Claude classifier. The place where we lost the first two weeks was fighting Zapier's rate limits on the Yelp connector. If I had the review flow working and the manager posting manually on day one, I could have added the AI layer as pure upside instead of a load-bearing dependency.
Second, I would write the voice prompt with the operator in the room. Our first drafts sounded like a chain restaurant's crisis-comms team wrote them. We rewrote the prompt with the actual owner-operator at the table, pulling phrases from replies she had already written by hand, and the drafts snapped into the brand voice inside an afternoon. The lesson was that voice cannot be reverse-engineered from scratch by a model. It has to be handed to the model as raw examples.
Third, I would tie the review dashboard directly into the weekly operating meeting from week one. The first version of this program sat in a Slack channel that nobody read on Monday morning. Once the theme-cluster view became a required slide in the weekly service debrief, everything about the loop got sharper. The kitchen saw the food-temperature trend. The floor saw the pace complaints. The operator saw where two units were drifting on ambiance while the other three held. Data without a meeting is a hobby.
The point
Review triage is a good first AI project for a multi-unit operator because the shape of the problem fits what LLMs do best: read a lot of text quickly, cluster it, and produce a first-draft response for a human to edit. The stakes are meaningful but not catastrophic. And the feedback loop, in Slack and Airtable, is short enough that you can tell every week whether it is working.
Do not automate the post. Do not skip the manager read. Do not let the tool run without someone maintaining the prompt. Those three rules are the whole guardrail. The rest is plumbing.