餐厅外卖评价监控：差评即时预警加菜品口碑周报

原文要点

原模板每30分钟轮询HTTP评价接口或经webhook（路径/restaurant-reviews）接收Swiggy/Zomato推送，把两个平台的评价规范化为含id、评分、文本、日期、下单菜品的统一结构；从Google Sheets读取已记录的review id去重，并加载菜单供菜品匹配。每条新评价连同菜单上下文发给gpt-4o-mini，输出情绪/紧急度分类、菜品提及与问题提取、公开回复草稿和内部处理建议；每评价写一行到"Reviews Log"、每菜品提及写一行到"Dish Mentions"。差评或高紧急度推Telegram并经Gmail升级，普通评价只推可粘贴回复草稿；每周一9点汇总两周数据做平台与菜品维度环比，OpenAI写洞察，Gmail发HTML周报、Telegram发摘要、归档到"Weekly Reports"。

这次做成什么

为餐饮店铺搭好这条评价监控流：新评价半小时内完成去重、AI分析和分级通知，差评即时升级，每周一自动收到菜品口碑环比周报；先用合成评价跑通单次流程再启用定时。

准备什么

• n8n实例并已导入该免费模板
• Google Sheets文件（含Reviews Log、Dish Mentions、Weekly Reports三个标签页）及含dish_name列的菜单页
• n8n中配好Google Sheets、Gmail、Telegram(bot token)、OpenAI凭据；用轮询方式还需评价接口的HTTP Header Auth
• Swiggy/Zomato评价的获取途径：可POST推送的评价源，或可轮询的评价feed URL

具体怎么做

1. 建表和菜单页

   在Google Sheets新建文件，建"Reviews Log""Dish Mentions""Weekly Reports"三个标签页，另建一个菜单页（如"Menu"）并确保有一列dish_name，把自家菜品名逐行录入，供AI做菜品提及匹配。

2. 配置四套凭据

   在n8n的Credentials页添加Google Sheets OAuth2、Gmail OAuth2、Telegram（bot token）和OpenAI凭据；如果采用每30分钟轮询评价接口的方式，再加一个HTTP Header Auth凭据并在请求节点选中。

3. 填写两处配置节点

   打开Set Monitor Config和Set Report Config，填入各Sheet id、菜单Sheet id、Telegram chat id、升级邮箱和店主邮箱、品牌语气（brand voice）以及差评/紧急度阈值，这些值控制全流程的写入位置与通知对象。

4. 选择评价入口

   二选一：用webhook则复制Receive Reviews via Webhook节点给出的URL，把你的评价源配置为向/restaurant-reviews路径POST评价；用轮询则把占位的https://YOUR-REVIEW-FEED.example.com/reviews?since=last_30_min替换成真实评价feed地址。没有现成评价接口时，可先用另一个n8n测试webhook手工POST合成评价。

5. 核对规范化与去重

   确认规范化节点把Swiggy和Zomato两种载荷统一成含review id、rating、text、日期和ordered items的结构；去重逻辑是先从Reviews Log读出已记录的review id再过滤重复，因此Reviews Log里的id列名必须与节点引用一致。

6. 检查AI分析与两级写入

   gpt-4o-mini节点的输入是单条新评价加菜单上下文，输出应包含情绪、紧急度、菜品提及与问题、公开回复草稿和内部建议；确认写入逻辑是每条评价追加一行到Reviews Log、每个菜品提及追加一行到Dish Mentions（一条评价提到两道菜就写两行）。

7. 验证分级通知与周报车道

   低评分或高紧急度的评价走Telegram推送加Gmail升级，其余评价只把回复草稿推到Telegram供人工粘贴；周报车道在每周一9点读取近两周数据做环比聚合，OpenAI生成洞察后由Gmail发HTML报告、Telegram发摘要、写入Weekly Reports归档。先用一条2分合成评价和一条5分合成评价分别验证两条通知路径，再激活定时触发器。

可直接复制的材料

你是餐饮外卖运营助理。本店菜单（JSON数组）：{{$json.menu}}。请分析这条顾客评价：平台{{$json.platform}}，评分{{$json.rating}}分（满分5分），内容：{{$json.text}}，下单菜品：{{$json.items}}。只输出JSON，字段如下：sentiment（positive/neutral/negative三选一）、urgency（high/medium/low三选一，涉及食安、异物、严重超时判high）、dish_mentions（数组，每项含dish和issue，未提及具体菜品则为空数组）、public_reply（不超过80字的公开回复草稿，礼貌、致歉、不推卸责任、不承诺赔偿金额）、internal_action（一句话内部处理建议）。不要输出JSON以外的任何内容。

{"review_id":"ZOM-100234","platform":"zomato","rating":2,"text":"宫保鸡丁太咸，而且送来时已经凉了，等了50分钟","items":["宫保鸡丁","米饭"],"created_at":"2026-10-05T12:40:00+08:00"}

输入与输出示例

本站虚构演示，输出为示意结构，实际分类与措辞由gpt-4o-mini生成，本站未运行。

输入

{"review_id":"ZOM-100234","platform":"zomato","rating":2,"text":"宫保鸡丁太咸，而且送来时已经凉了，等了50分钟","items":["宫保鸡丁","米饭"],"created_at":"2026-10-05T12:40:00+08:00"}

对应输出

预期AI输出（示意）：{"sentiment":"negative","urgency":"high","dish_mentions":[{"dish":"宫保鸡丁","issue":"太咸"},{"dish":"米饭","issue":"送达时已凉"}],"public_reply":"非常抱歉本次餐品口味与温度未达标，我们已反馈厨房与配送环节整改，期待您再给一次机会。","internal_action":"复核宫保鸡丁盐量标准并排查该时段配送保温与出餐时长"}；随后Reviews Log新增1行、Dish Mentions新增2行，Telegram收到预警且Gmail发出升级邮件。

做完检查这些

• POST同一条合成评价两次，Reviews Log中只新增一行，第二次被去重逻辑过滤
• 一条提到两道菜的评价在Dish Mentions中产生两行且dish名与菜单页dish_name能对上
• 2分差评触发Telegram预警和Gmail升级邮件，5分好评只推Telegram回复草稿、不发升级邮件
• 周一9点过后Weekly Reports新增一行归档记录，邮箱收到含平台与菜品环比的HTML周报
• Reviews Log中每行都含review id、评分、情绪、紧急度和回复草稿字段，无缺列

容易卡住的地方

• 模板不含Swiggy/Zomato官方抓取能力，评价数据需你自己有合法的推送或feed来源，否则只能用webhook手工喂数据
• Reviews Log里review id的列名若与去重节点引用不一致，去重会失效导致重复分析和重复通知
• 菜单页缺dish_name列或菜名与顾客口语叫法差异大，会让菜品提及匹配落空
• 差评阈值和紧急度判断标准在配置节点里，默认值未必符合你的门店，需要先用十几条历史评价校准
• 周报依赖近两周数据积累，启用第一周发出的环比报告会因缺少上周数据而不完整
• OpenAI、Telegram、Gmail任一凭据失效会导致对应分支静默失败，建议给通知节点加错误输出检查