n8n + Claude AI 自動回應 Google 商家評論完整流程

本文是《實體店自動化 — n8n + AI 串接訂位、客戶回訪、評論監控》系列的深入文章。先看總覽可回到完整版指南。

TL;DR：Google 評論自動回覆是用 n8n 定時抓新評論，交給 Claude 判斷情緒、意圖與風險，再把低風險評論自動草擬，高風險客訴升級給店長確認。

為什麼要自動回應評論

連鎖品牌通常有客服或行銷每天巡 Google Maps，個體店多半是老闆想到才看。差別不是有沒有禮貌，而是速度。Google 商家評論會影響搜尋與顧客決策，官方也提供商家回覆評論的管理說明；對餐飲店來說，半天後才看到一星評論，現場記憶和補救機會都會下降。台灣服務業人力吃緊，可從行政院主計總處查到服務業就業與工時資料，這也是小店要把巡查交給流程的原因。

流程總覽

Cron 定時啟動
  ↓
Google Business Profile API 抓新評論
  ↓
去重與存檔
  ↓
Claude API 情緒與意圖分類
  ↓
分流：自動草稿 / 人工升級
  ↓
回寫狀態與發送 LINE 通知

Cron 是定時器，白話就是「每 15 分鐘叫 n8n 做一次事」。評論不需要秒級即時，餐飲和美業通常 15 到 30 分鐘抓一次就夠。

Google Business Profile API 是較乾淨的評論來源，前提是商家已驗證並有權限。官方整合可先看 n8n Google Business Profile integration。

去重與存檔是避免同一則評論被回兩次。做法是把 reviewId、rating、comment、createTime 存到資料表，每次抓回來先查是否存在。

Claude API 負責輸出結構化判斷，不是直接自由發揮。你要要求它回 JSON，讓 n8n 可以穩定讀取 risk_level、intent、reply_draft。

分流規則決定哪些可以自動送出，哪些只能通知店長。五星純稱讚可自動草稿，一星食安、退款、員工衝突一律人工確認。

最後回寫狀態，讓你知道這則評論是已回覆、待審核、已升級或忽略。沒有狀態欄，兩週後就會分不清誰處理過。

節點 1 — 抓評論

Google Business Profile API 設定先從 Google Cloud 建專案、啟用 API、設定 OAuth consent screen，再建立 OAuth client。OAuth 是授權流程，讓 n8n 取得可讀取商家資料的 token，而不是保存你的 Google 密碼。

token 取得後，把憑證放到 n8n credential。建議用單一商家帳號先測，不要一開始接所有分店。每次先拉最近 50 則評論，確認欄位包含 reviewId、starRating、comment、reviewer、createTime、updateTime。

頻率調整要保守。新店一天可能只有 1 到 5 則評論，每 30 分鐘查一次就足夠；熱門餐廳或連鎖店可改 10 到 15 分鐘。若 API 額度不足，先加快營業尖峰時段，離峰降低頻率。

如果暫時拿不到 API 權限，可用 Apify 或 Make.com 做過渡，但要把資料來源、頻率、條款風險記錄清楚。長期正式流程仍建議回到官方 API 或官方通知來源。

這個節點還要處理「更新過的評論」。有些顧客會先留一星，店家處理後改成四星；也有人補充第二段文字。流程要比較 updateTime，只要內容更新，就重新分類，但不要重複發布回覆。

節點 2 — 情緒與意圖分類

Claude prompt 要把「品牌語氣」和「風險邊界」寫清楚。不要只丟一句「幫我回覆評論」，那會讓輸出不穩。

System prompt:
你是台灣實體店的評論處理助理。
任務是分類 Google 商家評論，產生可審核的回覆草稿。
請使用繁體中文，語氣真誠、簡短、不爭辯。
遇到食安、退款、歧視、員工衝突、法律威脅、個資內容，一律標為 high_risk。
不要承諾固定補償，不要編造不存在的事實。

User input:
店名：{{store_name}}
產業：{{industry}}
星等：{{rating}}
評論內容：{{comment}}
顧客姓名：{{reviewer_name}}
店家回覆規範：{{brand_policy}}

請輸出 JSON：
{
  "sentiment": "positive | neutral | negative",
  "intent": "praise | suggestion | service_complaint | product_complaint | pricing | safety | refund | other",
  "risk_level": "low | medium | high",
  "should_auto_reply": true,
  "summary": "30 字內摘要",
  "reply_draft": "120 字內回覆草稿",
  "escalation_reason": "若非 high_risk 則填空字串"
}

JSON schema 輸出的價值是讓 n8n 後面能用 If 節點判斷。risk_level = high 就發 LINE 給店長；should_auto_reply = true 才進自動回覆草稿。

Claude API 的串接可以用 n8n HTTP Request 節點。若店內還有菜單、退費政策、常見客訴 SOP，可延伸到 n8n RAG 企業知識庫實作，讓回覆更貼近真實規範。

測試時不要只用好評。請準備至少 30 則樣本：10 則正評、10 則建議、10 則負評。每則都人工標一次，再和 Claude 輸出比對，分類準確率低於 80% 時先修 prompt，不要急著上線。

若輸出不是合法 JSON，n8n 後續節點會讀不到欄位。實作上可以加一個重試節點，要求 Claude 只修正格式，不重新改寫判斷，避免同一則評論前後結論不一致。

節點 3 — 自動回覆 vs 人工升級的分流規則

低風險可自動草稿：四星或五星、內容是稱讚餐點、環境、服務，且沒有提到具體事故。這類可以直接回覆或進待審核，看你的品牌風險接受度。

中風險要人工看過：三星、價格抱怨、等待時間、口味建議。回覆需要承認感受，但不要承諾「一定改善」。可以說已記錄給現場團隊，並邀請私訊補充資訊。

高風險直接升級：一星、食物不適、退款爭議、員工衝突、個資、法律字眼、媒體曝光威脅。LINE 通知要附評論連結、AI 摘要、建議優先順序，並標記「未確認前不公開回覆」。

時間段也要設規則。營業時間內，高風險 10 分鐘內推播店長；非營業時間只發一次摘要，避免凌晨連續通知。隔天開店前再發待處理清單。

語氣上，正評可以溫暖但短；負評要克制，不要反駁。若是餐飲店，回覆不要公開討論健康細節，先請顧客私訊或來電，保留後續處理空間。

分流規則建議每兩週調一次。若太多評論被丟給店長，代表規則過度保守；若店長常退回 AI 草稿，代表語氣或風險條件還沒寫清楚。流程要看審核結果回頭修。

30 天上線 + 第 1 週要做哪些事

30 天拆成四段：第 1 週只盤點資料與權限，第 2 週抓評論與存檔，第 3 週接 Claude 分類，第 4 週小流量開啟回覆草稿與店長審核。

第 1 週最重要，不是寫 workflow，而是把商家帳號、分店、負責人、回覆規範整理好。沒有這些資料，AI 只會寫出漂亮但不準的文字。

第 1 天確認 Google Business Profile 擁有者與管理員。第 2 天建立 n8n credential。第 3 天整理過去 30 則正負評。第 4 天寫品牌回覆規範。第 5 天定義升級條件與店長 LINE 群組。

若你正從 Zapier 或 Make 搬流程，先看補看舊工具遷移到 n8n 的實作坑位。舊工具最常遺留欄位命名、重試次數、錯誤通知三類問題。

部署方式也會影響穩定度。小店可先用 n8n Cloud，若多分店、內部系統多，再看 n8n 自架 vs 雲端版完整選擇指南。

第 1 週不要開自動發布。先讓 n8n 抓評論、分類、送草稿到表格或 LINE，人工照常回。等你確認分類穩定、草稿語氣可用，再把低風險評論改成半自動審核。

常見問題

Google 評論自動回覆會違反平台規範嗎？

重點是來源與內容。用官方 API、商家有權限、回覆不造假、不要求顧客改評，風險較低。若用爬取服務，要自行確認服務條款與頻率。

Claude API 可以直接發布回覆嗎？

技術上可以接自動發布，但實務上建議先做草稿與審核。至少高風險評論不能自動發布，避免客訴升級。

n8n 評論監控多久跑一次比較好？

一般個體店 30 分鐘一次足夠，熱門餐廳可 10 到 15 分鐘一次。若 API 額度有限，營業尖峰加快，離峰放慢。

負評升級通知要傳給誰？

先傳店長或老闆，不要丟到大群組。通知應包含星等、原文、AI 摘要、建議回覆與評論連結，讓負責人能快速判斷。

回到總覽：實體店自動化完整版指南。想直接拿模板開始 → N8Nmarket 1700+ 工作流模板