2024 年 11 月，我接手过一个美国站的 3C 配件链接。它在 21 天里评分从 4.6 掉到 4.1，日均订单从 120 单掉到 43 单，广告 ACoS 从 28% 冲到 61%。运营的第一反应是申诉差评，客服的第一反应是给买家发站内信，产品经理的第一反应是"再观察一周看看"。三周后我们坐下来复盘，发现真正的问题根本不是评价本身，而是评价信息在团队内部走了三周，才走到那个唯一能解决问题的人手里。
这篇文章我想讲的，就是这件事背后的方法论：围绕评价管理，把软件工具、数据口径和团队责任重新搭一遍。它不是一篇"如何删除差评"的教程，而是一篇"如何让差评不再白挨"的协同进阶课。
绝大多数亚马逊团队把评价管理放在客服组下面，KPI 是"差评处理率"和"买家满意度"。这个设置从第一天就决定了天花板。客服能做的事情只有三件：安抚情绪、争取修改、记录问题。这三件事都不改变产品本身，所以同样的问题会在下个月、下个季度、下一个新品上再犯一次。
我的判断是：评价管理的归口部门应该是产品，客服只是数据入口。因为一条 1 星评论的真正价值，不在于它能不能被删掉，而在于它暴露了一个可以被修复的、可复现的缺陷。删掉它只是把症状压下去，修掉它才是治病。
很多团队在做评价管理优化时，第一刀砍向"响应速度"，要求客服 4 小时内回复所有买家消息。我做过统计，这个指标提升对复购和评分的影响非常有限，因为它解决的是"表层响应"，不是"深层归因"。
真正拖慢一切的，是信息路由。一条关于"充电口松动"的差评，从买家发出到质检部门看到，中间要经过：评论被抓取 → 客服看到 → 运营看到 → 运营判断是产品问题 → 运营在群里 @ 产品经理 → 产品经理在下次周会提出 → 质检才收到。这条链路上每多一个节点，平均多消耗 1.5 到 3 天。
这个观点反常识，但我在多个类目验证过。当你的采集覆盖率提升、买家触达变主动时，短期内差评数量会上升，因为它把原本被你忽略的、散落在各个站点和变体下的负面反馈集中暴露了出来。这是好事。
真正危险的状态是：评分缓慢下滑，但每月新增评论数量也在同步下降。这意味着买家用脚投票了，他们不评论，直接不买了。沉默的流失比吵闹的差评难对付得多。
我把那次事故的完整时间线拉了出来，用来给团队做内部培训。它不是特例，而是我见过的大多数中腰部卖家的标准剧本。
第 1 到 3 天：新品批次上线，前 3 条差评出现，内容都提到"充电到 80% 就停止"。客服当天回复，认为是偶发。评分 4.6，没人拉警报。
第 4 到 7 天：差评增加到 3 条，其中 1 条带图，能看到接口处有明显氧化痕迹。运营在报表里看到星级波动，判断是"季节性波动"。
第 8 到 12 天：新增 7 条差评，开始出现"用了两周就坏"的表述。评分 4.4，订单下滑约 18%。客服主管在群里提了一句，被当天的大促排期讨论盖过去了。
第 13 到 16 天：新增 9 条差评，退货率从 4.2% 升到 9.7%。运营开始申诉，成功率约 1/9。产品经理第一次看到这个问题是因为老板转发了差评截图。
第 17 到 21 天：新增 12 条差评，评分跌到 4.12，日均订单 43 单。质检部门终于介入，用同批次留样复现了问题，某供应商的接口镀层厚度不达标，盐雾测试 48 小时就出现氧化。
复盘时我让每个人写下那 21 天里自己实际在忙什么，结果非常说明问题。
五个人都没偷懒，但五个人之间存在四个信息断点。这就是我说的"信息路由"问题。
我用一个更直白的方式说明：每个角色"第一次感知到问题"的时间差。
如果重来一次，我不会先去申诉那 32 条差评，我会先做三件事，按优先级排序。
这三件事加起来，能把 18 天的延迟压到 2 到 3 天。这才是软件工具在评价管理里真正该发挥作用的地方，不是帮你回消息更快，而是帮你把信息送到正确的人面前更早。
星级是一个结果指标，语义才是过程指标。4.3 星和 4.3 星可能是完全不同的两种状态：一种是有 10 条差评分布在物流、包装、使用错误各种原因上；另一种是有 10 条差评全部指向同一个接口故障。
前者是常态，后者是警报。只看星级数字，你永远分不清这两者。我要求团队看板里星级只占一个卡片，语义标签的趋势线必须放在同一屏。
挽回率指的是通过站内信沟通，让买家修改或删除了差评的比例。这个指标看起来漂亮，但极其容易造假，只要客服只挑最好说话的买家去沟通，挽回率就能做得很高，而系统性问题一条都没解决。
我见过的健康指标体系是三段式的：响应覆盖率（是否所有差评都被看到）、有效归因率（是否被正确分类）、改进行动率（是否产生了可追踪的改进项）。挽回率只能作为第四个补充指标。
我见过有团队把"差评申诉成功率"当成运营的核心能力来卷。问题是，亚马逊允许申诉的场景非常有限，主要集中在违反评论政策（如包含不当内容、竞品恶意攻击、与商品无关的评价）这几类。产品本身有缺陷导致的差评，申诉基本不可能成功。
盲目申诉的代价不只是白费人力，更严重的是时间被消耗在了不可能有结果的动作上，真正需要修的缺陷被推迟了。我们的做法是把申诉率控制在 15% 以内，只针对明确符合政策的案例。
Vine 计划的价值不是"快速攒够 30 条评论把星级撑起来"，而是在上市第一周拿到高质量、带图、带详细使用场景的真实反馈。这批反馈的语义质量远高于普通评论，是产品迭代最快的输入源。
但如果你的团队没有能力处理这 30 条反馈，它很快就会变成一堆没人看的文本。我见过太多团队把 Vine 评论导出成 Excel 之后就再也没打开过。
这是最普遍也最难改的一条。评价问题的协同如果全部发生在微信或企微群里，会带来三个后果：信息被后续消息淹没、责任无法追踪、经验无法沉淀。
我坚持的一个原则是：任何需要超过 24 小时才能关闭的评价问题，都必须有一条对应的工单记录。工单不是为了管控人，是为了让下一个遇到同类问题的人能查到上次怎么解决的。
这两个是完全不同的东西：商品评价（Review）影响的是链接的转化与排名，店铺反馈（Feedback）影响的是账号健康与 Buy Box 资格。它们的责任归属也不同，前者主要归产品和运营，后者主要归客服和物流。
把它们合并成一个"用户满意度"指标，会让两类完全不同的改进动作混在一起，最后谁都说不清该改什么。分开看、分开管、分开考核，是最低要求。
第一层决定后面三层的质量。采样要解决三个问题：覆盖哪些站点和变体、拉取频率是多少、哪些评论属于噪声。
我的建议是：全站点全变体覆盖，每天拉取一次，噪声单独标记而不是直接丢弃。评分 3 星以下全部进池，3 星及以上里带具体问题描述的也进池。噪声评论（如"just ok"、"fine"这类无信息量内容）保留但标记为低优先级，因为它们在有足够样本量时能反映情绪基线。
归因分类是整个体系的枢纽。我的做法是建立一套两级标签字典：一级标签对应责任部门，二级标签对应具体问题点。
{
"review_id": "R3XXXXXXX",
"asin": "B0XXXXXXX",
"marketplace": "US",
"star": 2,
"date": "2024-11-08",
"level1_tag": "PRODUCT_DEFECT",
"level2_tag": "CONNECTOR_OXIDATION",
"severity": "HIGH",
"owner_department": "QC",
"sla_hours": 72,
"evidence": "has_photo",
"repeat_group": "LOT_2024Q4_A"
}
这套结构里最关键的两个字段是 level2_tag 和 repeat_group。前者让问题可统计，后者让同批次问题可以聚类。没有 repeat_group，你只能看到"有 30 条差评"；有了它，你能看到"有 30 条差评，其中 22 条来自同一生产批次"。
归因之后必须立刻分派，分派之后必须有 SLA。我见过最容易失败的团队是把这两步分开：先归因，攒到周会上再统一分派。周会一到，问题已经发酵了一周。
我的做法是在归因规则里直接写死责任人字段，系统打标即分派，不经过任何人工中转。下面是我们在用的责任映射表。
| 一级标签 | 责任部门 | 首次响应 SLA | 关闭 SLA | 验证方式 |
|---|---|---|---|---|
| 产品功能与质量缺陷 | 产品 + 质检 | 24 小时 | 15 天 | 同批次复现 + 留样检测 |
| 物流与包装破损 | 供应链 + 仓配 | 24 小时 | 7 天 | 包装跌落测试 + 入库抽检 |
| 期望管理偏差 | 运营（文案与视觉） | 48 小时 | 5 天 | Listing 修改上线 + 转化率对比 |
| 使用错误与说明书 | 运营 + 视觉 | 48 小时 | 10 天 | A+ 图文更新 + 包装内卡片 |
| 兼容性与变体混乱 | 运营 + 产品 | 48 小时 | 7 天 | 变体命名重构 + 对照表上线 |
| 政策类可申诉差评 | 客服 + 合规 | 12 小时 | 按平台周期 | 申诉结果记录 |
第四层是绝大多数团队缺失的一层。闭环验证的意思是：改完之后，你要能用数据证明问题真的消失了。
我们的验证标准是改进行动上线后的 30 天内，同 level2_tag 的新增差评占比下降 70% 以上。如果没达到，说明归因错了或者改错了，要重新回到第二层。
知识沉淀则是把这次的处理过程和结论写进内部知识库，包括复现方法、供应商沟通记录、替代方案对比。这样下一次同类问题出现时，处理周期可以从 15 天压到 3 天以内。
我踩过一个很典型的坑。2023 年我帮一个团队 redesign 评价处理流程，做了漂亮的泳道图、开了三次培训会，结果三个月后全部回到原样。原因是流程要求每个人手动更新状态，而手动更新的成本高于收益。
后来我换了个顺序：先把数据层做通，让流程附着在数据上，而不是让数据迁就流程。数据自动流转的地方，人就不需要额外动作；不需要额外动作的流程，才能活下来。
我用的工具是数跨境，它的定位是跨境电商的数据分析与协同平台。我选择它作为这套体系的承载，主要理由有三个：能把多站点多店铺的数据统一到同一个口径下、能自定义分析模型而不是套固定模板、以及看板可以直接分发给不同角色的成员。
接入之前，我们团队有个很隐蔽的问题：运营说的"差评"和客服说的"差评"不是一回事。运营指的是 3 星以下 Review，客服指的是包含负面情绪的买家消息。两边在周会上对不上数。
所以我先在数据层做了三件事。
这三件事做完，团队第一次能用同一组数字开会，光这一点就省下了每周至少 3 小时的对齐时间。
在数跨境里我搭了三层看板，对应三种不同的决策场景。这是我摸索出来最有效的结构，因为不同角色需要的不是同一份数据的不同视图，而是完全不同的信息密度。
第一层是执行层看板，给客服和运营一线用。核心是三张卡：今日新增差评清单（带归因标签和责任人）、我的待处理工单、超 SLA 未关闭项。信息密度低，但每一条都可直接操作。
第二层是管理层看板，给运营主管和产品经理用。核心是趋势线：各标签差评的月度占比变化、重复问题聚类、改进项的关闭率。这一层看的是结构，不是个案。
第三层是决策层看板，给负责人用。只放四个数字：评分与转化率的关联曲线、评价问题导致的预估损失金额、本月产生的改进提案数与落地数、跨站点风险热力分布。
单看评价数据，你只能看到"用户不满意什么"。把评价数据和其他经营数据打通，你才能看到"不满意造成了多少损失"。
我做过几个交叉分析，效果比单纯看评价报表好得多。
说一个具体案例，这样更容易理解整套机制怎么跑起来。
2025 年 3 月，我们的自动归因系统在 72 小时内捕捉到一个异常：level2_tag 为"线材连接处断裂"的差评从每周约 0.5 条跳到 4 条，同时有 3 条退货把这些记录标记为同一原因。触发告警，自动分派给质检部门。
质检在 5 天内完成了两件事：一是从 FBA 库存中调取同批次留样做弯折测试，发现在 8000 次弯折后开始出现内部断丝；二是把这个结果和供应商沟通，确认对方在这批货里更换了内部编织层的材料。
第 9 天，产品侧决定做两件事：短期在包装内加一张使用提示卡（说明正确收纳方式），中期更换供应商并重新做测试标准。第 15 天，改进方案上线。
第 45 天回看数据：该标签的新增差评从每月 16 条降到 3 条，降幅 81%，超过我们设定的 70% 验证线。同时这条改进被写成知识库文档，后面两个同类产品直接复用了这套检测标准。
从发现问题到闭环沉淀，全程 45 天。同样的流程在建立体系之前，我们花了接近 5 个月，而且没有沉淀下任何可复用的东西。
如果你的团队只有 1 到 3 个人，负责全部店铺，我强烈建议不要一上来就折腾自动化流程和复杂看板。这个阶段你的核心矛盾是"样本量不足"，不是"效率不足"。
具体做法：
这个规模是绝大多数中腰部卖家的真实状态。人够多，但每个人负责的边界开始模糊，评价问题最容易在交接处掉地上。
这个阶段的关键动作是把责任写死在数据里，而不是写在文档里。归因标签和责任部门一一对应，系统打标即分派，不给"这条该谁看"留讨论空间。
同时要开始看"重复率"这个指标。重复性差评占比超过 15%，说明你的闭环是假的，问题被处理了，但没有被解决。
如果你有研发能力，评价数据就不该只服务于售后，而应该进入产品需求池。具体做法是每月从评价标签里抽出 top 3 高频问题，转成产品改进需求，进入正式的评审流程。
这里有个细节很重要：转成需求时，不要写"用户反馈充电口松动"，要写"接口镀层厚度需从 X 提升到 Y，通过 48 小时盐雾测试"。前者是感受，后者是可验收的标准。
铺货模式的 SKU 数量决定了你不可能对每条评价做深度归因。这个模式下的最优策略是把评价管理压缩成一个风险监控系统。
只看三个信号：单 SKU 评分单周跌幅超过 0.3 分、单 SKU 差评数量周环比增长超过 200%、单 SKU 退货率超过类目均值的 2 倍。任一条件触发就人工介入，其余时间不做动作。
工具选型上，铺货卖家对聚合能力的要求远高于分析能力。能不能一次性接入几百个 SKU 并自动分级，比能不能做复杂图表重要得多。
如果你已经做了品牌注册、有 A+ 页面、在跑站外，那评价管理的重心应该往前移一步，从"处理差评"转向"管理预期"。
我观察到的一个规律：品牌化团队里，期望管理偏差类差评的占比通常比铺货团队高，因为你的文案更精致、图片更漂亮，买家的预期被抬得更高。这类差评不需要改产品，只需要改内容。
具体做法是把每个季度的期望管理类差评做文本聚类，找出买家"以为有但没有"的功能点，然后针对性地在主图、五点描述、A+ 里补上说明。这件事的投入产出比，远高于申诉差评。
把归因做深必然拖慢响应速度，这是绕不开的矛盾。我的判断标准是：按标签分级处理，而不是全局提速或全局放缓。
产品缺陷类必须快，24 小时内分派，因为每晚一天就可能多 20 条差评；期望管理类可以慢一点，48 到 72 小时分派完全没问题，因为它的边际伤害低得多。全局统一 SLA 是懒人做法，实际效果最差。
很多人担心自动化会把归因做错。我的经验是：关键词规则适合做粗筛，语义模型适合做归类，但高风险标签必须保留人工复核。因为 1 星差评里的"产品缺陷"和"使用错误"在文本上高度相似，模型最容易在这里出错。
我们目前的配置是：所有评论自动打标，但 level1_tag 为"产品缺陷"的条目 100% 人工复核，其余标签抽检 10%。这个比例让我们的误判率控制在 6% 以内，同时人力只增加了 0.3 个人天/天。
我的经验法则是：当评价处理占用的人力超过 0.5 个全职当量时，工具投入就开始划算。
按行业常见的人力成本算，一个客服岗位月成本约 8000 到 12000 元。如果评价处理占用半个人，一年就是 5 到 7 万元。一套能把这部分工作量压缩 70% 的工具，只要年费低于 4 万元就是净收益，还没算上因为响应变快而挽回的订单。
但要注意，工具的成本不只是订阅费，还有接入、建模、培训的隐性成本。我通常按订阅费的 1.5 倍来估算第一年的真实投入。
这是最容易被做错的一刀。我的判断标准很简单：申诉的期望收益 = 成功率 × 单条差评的边际损失；迭代的期望收益 = 问题发生率下降 × 影响的所有订单。
绝大多数情况下，迭代的期望收益高一个数量级。原因很直白：一条差评影响的是看到它的人，一个缺陷影响的是所有拿到这批货的人。
所以我们的资源分配是 80% 投在迭代，20% 投在申诉，且申诉只在明确符合平台政策时才做。
我见过太多"看板很漂亮但没人看"的案例。这个问题通常不是看板做得不好，而是看板解决的问题和看它的人的日常决策不匹配。
判断标准是：如果一个人看完这个看板之后，不能立刻说出"我今天要做哪一件具体的事"，那这个看板对他就是无效的。执行层看板必须落到待办，管理层看板必须落到趋势，决策层看板必须落到钱。三个层次混在一起，就等于没有层次。
回到开头那个 21 天掉 0.5 分的案例。它真正的教训不是"要早点发现差评"，而是一个组织如果没有能力把用户的抱怨变成可执行的改进，那它所有的评价管理工作都只是在做情绪劳动。
我对评价管理的核心观点可以归结成三句话。第一，评价是唯一同时连接消费者语言、产品质量、运营动作和供应链改进的数据源，把它只交给客服是巨大浪费。第二，协同的瓶颈从来不是响应速度，而是信息路由，软件工具最大的价值在于压缩"问题被发现"到"解决者看到"之间的天数。第三，闭环的唯一证据是重复率下降，不是差评数量下降。
如果你现在就要动手，我建议按这个顺序走：这一周先把所有站点和变体的评论采集口径统一，做一张最朴素的表格，记录日期、ASIN、星级、问题描述、可能原因；接下来两周人工过两轮，把高频问题归纳成自己的标签字典，一级标签对应部门，二级标签对应问题点；一个月后把标签字典搬进工具，配上责任字段和 SLA，先跑通"打标即分派"这一步；再往后，才开始考虑看板分层、自动告警和跨数据源交叉验证。
不要跳过前面的人工阶段。我见过太多团队直接买工具、建看板，结果三个月后系统里堆着 5000 条未处理标签。工具能放大的只有已经存在的判断力，放大不了还没有的判断力。先把判断力建起来，再谈自动化，这是我在这个问题上最愿意重复的一句话。
我们店铺一年做几百万美金，评价这块一直是最头疼的：客服每天在后台翻评论，运营在 Excel 里登记，产品只有在群里被 @ 了才知道出了问题。结果经常是同一条差评，三个人重复看、重复讨论，最后谁也没跟进到底。我想知道有没有一套能真正落地的协同办法。
先做一个最小闭环：统一入口、统一字段、统一节奏。统一入口是指新评价只从一个地方进来，不要再出现后台、表格、群聊三个来源；统一字段是指每条评价必须带上站点、ASIN、星级、原文、归类、责任团队、状态、结论这八个字段；统一节奏是指固定处理节点。
具体做法是：每天固定时段拉取新增评价，1，3 星差评必须生成一条独立工单，工单里写清 ASIN、站点、评论 ID、归类（产品质量／物流时效／描述不符／使用问题／恶意评价），并且只指定一个责任人，给 24 小时出内部结论、48 小时完成定性、7 天验证效果三个节点。
判断依据上，我建议设一条升级线：同一 ASIN 同一类问题在 30 天内重复出现 3 次以上，就从「个单处理」升级为「产品或 Listing 改进项」，交给产品、供应链或内容负责人立项。这条线很关键，否则团队会一直陷在一条条回差评里，永远在救火，但差评产生的源头没被碰过。
工单可以放在某项目管理工具里用看板管理，字段做成必填，剩下的就是执行纪律问题。
我们团队就 3 个人，一个运营一个客服加我自己，Excel 加日历提醒用了两年，感觉也还行。但最近开始做欧洲站，多了三个语种，客服一走我就彻底懵了，很多差评不知道回没回、跟到哪一步。我又怕上系统是过度管理，小团队搞一堆流程反而拖慢速度。
判断标准不是团队人数，而是三个变量：评价量、站点／语种数、协同人数。如果单站点、日均新增评价少于 10 条、固定 1，2 人处理，表格加提醒完全够用，我不建议这个阶段上系统。但只要出现下面任一情况，表格就会开始出现信息黑洞：多站点多语种并行、处理人超过 2 个、或者同一问题需要产品／供应链介入。
这时最明显的信号是，你每周至少有一次因为「这条差评到底回过没有」而产生重复沟通。我给你算个账：重复沟通一次平均 5 分钟，一周 10 次，一年就是 43 小时左右，已经超过一个人一周的工作量，这笔账比工具成本高得多。
还有一个容易被忽略的点是交接风险：用表格时，「谁在处理、处理到哪一步」只存在当事人脑子里，人一走就断档。你可以先做一次最小验证，把现有表格加上「责任人」「状态」「最后更新日期」三列并强制填写，如果能坚持两周不乱，说明流程本身没问题，可以再等；如果两周就崩，那就不是工具问题，是流程该换了。
之前老板要求我们考核「差评删除率」，团队压力特别大，我总觉得这个方向不太对。后来我们改成考核响应时效，但口径又吵起来了，是按发现时间算还是按评论发布时间算？联系买家算不算响应完成？我想把这块指标定清楚，别再每个月开会扯皮。
第一条判断是：不要把「删除差评率」当 KPI。它既不可控，又容易把团队往灰色路径上逼，比如违规联系买家、诱导修改评价，这类操作在亚马逊上的风险远大于收益。正确的目标应该是让同类差评不再产生。
我建议用四个可执行口径：一是差评首响时效，定义为工作日 24 小时内完成内部定性和归类，注意这里指的是内部结论，不是联系买家，因为联系买家的合规边界很窄，不能作为常规动作；二是归类完成率，要求 100% 的差评都有明确归类，并且「其他」这一类占比不能超过 10%，超过就说明分类维度设计有问题；
三是重复问题收敛率，看同一 ASIN 同一类问题在 30 天内的复发次数环比变化，这个指标直接反映改进是否有效；四是改进项关闭率，统计立项的问题里有多少在规定周期内完成验证并关闭。时间口径上我建议统一按评论发布时间起算，因为发现时间取决于你的抓取频率，用它考核等于在考核抓取工具，会失真。
另外提醒一句，星级均值只能作为结果指标月度观察，不要拆到个人，否则团队会为了保住均值去做无意义的动作。
我们最典型的场景是：一条差评说产品用了两周就坏了，客服说这是质量问题要找产品，产品说这是使用方法问题让客服去解释，运营说我改 Listing 就好，最后这条评论在群里被转了三圈没人认领。每个月复盘会都在讨论流程，但下个月还是这样。
根子在「多人负责等于没人负责」。我的做法是每条评价工单只允许一个 Owner，并且把「归类」字段设计成固定枚举加必填，选完自动指派，不让责任靠人判断。具体分工可以这样定：评价监测和初判由运营或评价专员担任 Owner；物流时效类归客服或物流对接人；产品质量、批次问题归产品或 QC；
描述不符、图片与实物差异归 Listing 内容负责人；使用疑问类归客服，但结论必须回流成 FAQ 或说明书改进建议。判定规则上要有一条硬线：如果一个类别的差评占比连续两周超过 30%，那就不再是执行问题，而是产品或供应链问题，必须在月会上上升到决策层，而不是继续让一线团队回评论。
当 Owner 不是万能的，他负责推进和记录，不负责独自解决，比如产品类工单 Owner 是产品经理，但采购和供应链必须回填根因和预计完成时间。复盘节奏我建议周会只看两件事：新增差评的 TOP3 归类和重复率；月会只看改进项的关闭情况。这样会议时间能压到半小时以内，也不会变成互相甩锅的现场。
读者评论
文章把差评归因到产品职能，我认同，但落地时最难的是标签字典谁维护。小团队运营兼客服，每天全站点全变体拉取根本不现实，最后往往还是只看美国站和带图差评。我的做法是先抓1-2星，按周人工过一遍，等量级上来再考虑工具自动化，不然字典建了也没人校准。
关于‘差评数量上升不一定是坏事’我有点保留。暴露问题确实是好事，但亚马逊评分和转化是实时的，等研发复现、换供应商，链接可能已经掉出类目流量池。我们之前一个链接也是同样情况，三周损失比全年利润还高。所以我会再加一条：看差评增速和退货率，先做止血动作，比如暂停广告、切批次，再谈归因。
把评价管理归到产品，方向对，但很多公司产品经理的KPI是新品数量和上市时间，评价处理不进考核，工单最后还是会堆在客服那里。我见过用某项目管理平台建了评价工单，但没有SLA和升级规则，两周后没人看。问题不是有没有工具，而是谁对关闭负责。另外，Vine评论导出Excel没人看，这点太真实了。