RV-01 · 差评回复话术（数据驱动版）

① 场景引入

一、这件事现在是什么样

评价治理与申诉 · 真实业务触发

周一早上九点，老广炭火烧烤（洛溪店）收到一条二星差评：「等了 50 分钟才上齐，服务员态度还差，不会再来」；同店过去 90 天已有两条同主题差评（上菜慢），其中一条当时的处理是发了一张免排队券；运营同时在管 40 多家店的评价，通用 AI 工具生成的话术是「亲爱的顾客您好，给您带来不好的体验非常抱歉……」——和上一条、上上一条的回复一字不差。商家在群里问：能不能说点别的。

二、痛点 · 每条都有来源

1一条带图差评导致门店 3 天内自然搜索曝光下降 8-15%、到店转化率下降 5-10%；月均 6000 客流门店单条差评损失1.8-3.6 万元营收依据 · 餐饮代运营实测：一条带图差评导致门店 3 天内自然搜索曝光下降 8-15%、到店转化率下降5-10%；月均 6000 客流门店单条差评损失 1.8-3.6 万元营收2诚恳回复 + 补偿方案的门店评分恢复速度是沉默门店的 2.3倍——回复质量直接影响损失金额的收敛依据 · 同源实测：诚恳回复 + 补偿方案的门店，评分恢复速度是沉默门店的2.3 倍——回复质量直接影响损失金额的收敛3代运营商实态：一名运营同时挂几十家商家的后台，差评回复是「多数时间在打电话回微信」缝隙里挤出来的活依据 · 代运营实态：一名运营同时挂几十家商家的后台，日常是商品上下架、价格调整、活动报名、差评回复、数据报表，多数时间在打电话回微信；浅层服务商续约率不足 40%4通用 AI 回复工具（惠店掌「30 秒生成回复」等）已是红海，但产出是万金油道歉——没有商家私有数据，「这是他第三次投诉上菜慢」这种话通用工具说不出来依据 · 厂商覆盖证据：惠店掌「AI 智能回评」宣称 24 小时监控美团/饿了么、30 秒生成回复——差评回复已是 SaaS 红海，通用模板没有私有数据5同模板回复被消费者视为无视、公开处刑；美团风控已警告「疑似机器人回复」——模板化不只是无效，有反作用依据 · 探店内容过剩实态：博主用 AI 剪辑软件批量拼接素材 + 雷同文案 + AI 配音的「云探店」泛滥，「30-50 个达人里靠谱的只有 10%」——内容产量是瓶颈的反面

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 一条带图差评导致门店 3 天内自然搜索曝光下降 8-15%、到店转化率下降 5-10%；月均 6000 客流门店单条差评损失 1.8-3.6 万元营收诚恳回复 + 补偿方案的门店评分恢复速度是沉默门店的 2.3 倍——回复质量直接影响损失金额的收敛代运营商实态：一名运营同时挂几十家商家的后台，差评回复是「多数时间在打电话回微信」缝隙里挤出来的活通用 AI 回复工具（惠店掌「30 秒生成回复」等）已是红海，但产出是万金油道歉——没有商家私有数据，「这是他第三次投诉上菜慢」这种话通用工具说不出来

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 差评主题归类与历史回溯这条差评是首犯还是惯犯：同主题历史、上次处理、效果如何
2. 责任初判订单时间线 × 菜品结构：是高峰期全店慢，还是某单品瓶颈，还是服务态度
3. 回复口径生成按历史处理记录生成差异化回复——上次给过什么、这次在改什么
4. 补偿方案匹配在商家授权范围内匹配补偿档位，超授权的标注待确认第 5步回复发布与效果登记回复内容进商家档案，下次同主题差评自动带出本次记录

要准备什么：当条差评原文与订单信息星级、内容、时间、关联订单本商家 90 天历史差评与回复记录同主题出现了几次、当时的口径、补偿发了什么已生效的补偿权限表免排队券 / 代金券 / 赠菜，各档金额与发放规则菜品与出餐结构表判断「上菜慢」是单品瓶颈还是全店瓶颈的依据

为什么这个场景值得做

优先级评分：痛感 4 × AI 适配 5 ÷ 落地难度 2 = 12.0

最大差异点：与通用回复工具的分界线在输入：不是「一条差评 + 一个模板」，而是这条差评 × 本商家 90 天历史差评 × 已生效的处理方案 × 菜品结构 × 补偿权限。同主题差评第三次出现时，回复里应该有「上次我们给过免排队券、这次我们在改排班」——这句话只有吃进私有数据才写得出来，而这恰恰是消费者判断「这家店有没有把我当回事」的依据。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：差评回复话术与处理建议.docx 正式件 · 差异化回复口径 × 2 版 + 根因摘要 · 含商家确认栏
• 可派发清单：同主题差评历史分析.xlsx 90 天同主题差评时间线 · 历次处理与效果 · 根因初判

这套东西不承诺什么：回复内容以商家确认后发布为准，平台侧不代发；补偿承诺的金额与形式必须落在商家授权范围内，超出授权的补偿方案标注「需商家确认」；不承诺删除差评（删除只能走平台申诉或商家协商的合规路径，见RV-02）。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：邻聚生活评价运营阿芳周二处理 23 条上周差评——其中老广炭火烧烤（洛溪店）的「上菜慢」差评是第 3条同主题，前两条都回了「厨房忙」——诚恳回复加补偿的门店评分恢复速度是沉默门店的 2.3 倍，通用模板给不了「这是他第三次投诉上菜慢」。

本周差评23 条 · 6 主题同主题 ≥3 次3 条 · 老广炭火历史口径12 类 · 含同主题纵向回复草稿23 份 · 含分级补偿建议

输入本地生活平台手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_上周23条差评原文与截图.xlsx 上周 23 条差评的原文、订单号、商家当前已回复（如有）商家后台导出 · 周一批量
• 02_老广炭火洛溪店_近90天差评历史.xlsx 老广炭火洛溪店近 90 天差评历史——同主题纵向比对的关键数据商家后台导出 · 每周
• 03_诚恳回复+补偿方案_评分恢复数据.txt 诚恳回复 + 补偿方案的门店，评分恢复速度是沉默门店的 2.3 倍——分级补偿建议的依据公开行业数据 · 2024-2025 餐饮代运营实测
• 04_差评主题分类与补偿建议库.xlsx 差评主题分类与对应补偿建议库——回复草稿的标准化依据评价组 · 上次更新 2025-04

注意标橙色那一份 —— 01_上周23条差评原文与截图.xlsx。它商家后台导出 · 周一批量，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

洛溪店刚来了一条二星差评。这是差评原文和订单信息，这是这家店 90 天的历史差评和当时的回复记录，这是商家的补偿权限表。 帮我出回复：

1. 先看历史——同主题的差评这是第几次，上次怎么处理的，这次别再说一样的话。
2. 出餐慢这个事，看下订单时间线和菜品结构，判断是全店慢还是单品慢，回复里要说到点子上。
3. 补偿在权限表里挑，别超。
4. 给商家的内部摘要：这单的根因是什么、上次免排队券为什么没留住人、要不要改排班。 回复要像真人写的，别用「亲」开头。

回复口径规则（历史引用、责任拆分、补偿档位）在能力包里；现场只需把差评、历史记录、权限表丢进来。

123 条差评分主题——6 主题，老广占「上菜慢」主题 8 条

主题分类是分级回复的前提

差评主题条数代表门店分级建议上菜慢8老广炭火洛溪店（3 条）· 老广市桥店（1 条）· 其他 4 条同主题 ≥3 次需纵向比对菜咸5湘村小炒 2 条 · 其他 3 条标准回复 · 5 元补偿分量少4川味小厨 2 条 · 其他 2 条标准回复 · 5-10 元补偿等位久3潮味牛肉火锅 1 条 · 其他 2 条标准回复 · 8 元补偿送错2茶里茶里 1 条 · 其他 1 条道歉 + 改派或退款其他1茶里茶里标准回复合计23 条6 主题—该拦的信号 · 同一主题 ≥3 次就该升级处理「上菜慢」8 条占总差评 35%——不是回复模板的问题，是这家店出餐环节真的有瓶颈。回复能压住评分，回复压不住经营问题——但回复至少能让老板看见「同一主题 ≥3 次」的信号。

2老广洛溪店纵向比对——90 天 8 次同主题，3 次同一周

通用模板给不了「这是他第三次投诉上菜慢」

日期原文摘录商家已回复距上次本轮处置2026-05-15等了 30 分钟厨房忙——2026-06-02等了 35 分钟厨房忙+18 天—

2026-06-22等 40 分钟饭都凉了厨房忙+20 天—2026-07-10周末 1 小时厨房忙+18 天—2026-08-12等了 45 分钟—+33 天—2026-08-25等了 50 分钟,饭都凉了厨房忙+13 天本轮同主题第 7 次2026-08-25周末等了 1 小时,孩子都哭闹了厨房忙+13 天本轮同主题第 8 次2026-08-26又慢,比上次还慢—+1 天第三次上周同主题从历史差评想起的老客8 月 26 日的「又慢,比上次还慢」——这是一位 7 月来过、8 月来过两次的老客。回复要承认：「您之前 7 月和 8 月两次用餐都有上菜慢的体验,这是我们没有改进到位」，不能继续用「厨房忙」模板。

3分级回复草稿——3 家「同主题 ≥3 次」+ 20 家标准

23 份草稿，3 份是定制版

商家本轮主题回复类型补偿关键句老广炭火（洛溪店）3 条上菜慢 ×3定制版8 元代金券 ×3承认 7-8 月两次用餐延误 ·邀请下次优先老广炭火（市桥店）1 条上菜慢标准版5 元代金券承认延误 · 邀请再试湘村小炒（洛溪店）1 条菜咸标准版5 元代金券承认口味 · 备注主厨川味小厨（洛溪店）1 条分量少标准版5 元代金券承认份量 · 承诺改进潮味牛肉火锅（洛溪店）1 条等位久标准版8 元代金券承认等候 · 介绍预约茶里茶里（洛溪店）1 条送错道歉版免单 / 重配送道歉+ 改派其他 15 条5 主题标准版按建议库—总数23定制 3 + 标准 20——可以排除的补偿方案 · 大额不等于诚意5-10 元代金券的「小金额但可见」——比 30 元代金券更让用户觉得「商家是来解决事的，不是花钱消差评」。对同主题 ≥3 次的 3 条提到 8 元（多 3 元），因为纵向 8 次的老客补偿需要「高于标准」，否则用户会直接判定「又是模板」。

423 份草稿 + 同主题历史分析——含评价治理周报

草稿是给商家回复的，分析是给老板看的

析.xlsxxlsx6 主题纵向 · 老广洛溪店 8 次同主题特别标注老板周会把技术动作翻译成钱带图差评导致 3 天曝光降

8-15%、转化率降 5-10%；月 6000 客流门店单条差评损失 1.8-3.6 万；诚恳回复 + 补偿的评分恢复是沉默的 2.3 倍。老广洛溪店上周 3 条同主题「上菜慢」——23 份草稿里 3 份是定制版，若不写定制版直接发模板，3 条评分继续掉，30 天内评分从 4.2 滑到 3.9，按月 6000 客流估算，单月损失约 5-9 万（3 条 × 1.8-3.6 万）。

3 条定制版 + 20 条标准版 · 8 元补偿区分纵向老客（不放行）老广洛溪店 8 月 25-26 日 3 条同主题「上菜慢」全部走定制版（8 元补偿 + 承认 7-8 月历史），其余 20 条按建议库走标准版。方案一：23 条全用「厨房忙」模板复制——老客 3 条评分继续掉，30 天内老广洛溪店评分从 4.2 滑到 3.9，按月 6000 客流估算单月损失 5-9 万；且 8 月底复盘会上「为什么 7-8 月评分在掉」老板又得解释一遍。方案二：3 条定制 + 20 条标准——3 份定制草稿比模板多花评价运营0.5 小时（每份 10 分钟），换来老广洛溪店评分止跌（按月 6000 客流估算挽回 5-9 万损失，且不把老客推到「给差评就被忽视」的恶性循环）。

之后这一次跑完，公司多了什么

不讲省了多久：讲少了几个隐患、沉淀了什么

• ✓ 回复从模板道歉变成「知道你是谁、知道上次给过什么、知道这次在改什么」——通用工具抄不走的部分
• ✓ 同主题差评的重复出现第一次被当作信号处理，而不是当作又一条差评处理
• ✓ 补偿落在授权范围内，运营不用每单都去问商家「能给多少」
• ✓ 每条回复进档案，下一次的口径自动带上这一次——商家的口碑记忆不再随人员流动丢失

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 商家不想暴露「我们是第三次犯」怎么办？ 口径分两层：对外版只说本次动作（加派人手、叫号），不点破历史；内部摘要里才写「这是第三次」——对外诚恳不等于对外自曝，这个分寸在能力包里有细则。
• 消费者会看出来回复是 AI写的吗？ 看出模板化是最大的翻车点，所以回复里必须有只有这家店才说得出的事实——历史处理记录、当班动作、菜品瓶颈，这些是通用工具给不了的原料。
• 能不能顺便把这条差评申诉掉？ 这条不行（真实消费、内容属实，申诉必败）；但同账号如果继续出现异常打分，会自动进入 RV-02 的恶意差评识别——两件事的边界看的是证据，不是情绪。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

差评回复话术（数据驱动版） —— 通用模板给不了「这是他第三次投诉上菜慢」 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

data-driven-review-reply.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是本地生活平台手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁RV-01 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

• 01_上周23条差评原文与截图.xlsx 上周 23 条差评的原文、订单号、商家当前已回复（如有）
• 02_老广炭火洛溪店_近90天差评历史.xlsx 老广炭火洛溪店近 90 天差评历史——同主题纵向比对的关键数据
• 03_诚恳回复+补偿方案_评分恢复数据.txt 诚恳回复 + 补偿方案的门店，评分恢复速度是沉默门店的 2.3 倍——分级补偿建议的依据
• 04_差评主题分类与补偿建议库.xlsx 差评主题分类与对应补偿建议库——回复草稿的标准化依据

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

洛溪店刚来了一条二星差评。这是差评原文和订单信息，这是这家店 90 天的历史差评和当时的回复记录，这是商家的补偿权限表。 帮我出回复：

1. 先看历史——同主题的差评这是第几次，上次怎么处理的，这次别再说一样的话。
2. 出餐慢这个事，看下订单时间线和菜品结构，判断是全店慢还是单品慢，回复里要说到点子上。
3. 补偿在权限表里挑，别超。
4. 给商家的内部摘要：这单的根因是什么、上次免排队券为什么没留住人、要不要改排班。 回复要像真人写的，别用「亲」开头。

为什么这么短就够了：回复口径规则（历史引用、责任拆分、补偿档位）在能力包里；现场只需把差评、历史记录、权限表丢进来。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 2 份

XLSRV-01_差评回复话术与处理建议.docx正式件 · 差异化回复口径 × 2 版 + 根因摘要 · 含商家确认栏下载

• ↓XLSRV-01_同主题差评历史分析.xlsx 90 天同主题差评时间线 · 历次处理与效果 · 根因初判

Skill 里固化了什么：这是 90 天内第三次「上菜慢」「态度差」这条被单独拆出来了排除性结论把技术动作翻译成钱

输入清单：当条差评原文与订单信息星级、内容、时间、关联订单本商家 90 天历史差评与回复记录同主题出现了几次、当时的口径、补偿发了什么已生效的补偿权限表免排队券 / 代金券 / 赠菜，各档金额与发放规则菜品与出餐结构表判断「上菜慢」是单品瓶颈还是全店瓶颈的依据

人工边界：回复内容以商家确认后发布为准，平台侧不代发；补偿承诺的金额与形式必须落在商家授权范围内，超出授权的补偿方案标注「需商家确认」；不承诺删除差评（删除只能走平台申诉或商家协商的合规路径，见 RV-02）。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

评价治理与申诉 · 产出即下一步输入

• RV-02 · 恶意差评识别与申诉证据包：一次申诉机会，证据链要一次凑齐

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。