用户反馈分散、处理不透明、判定标准不一，是服务型产品闭环的典型痛点。本文以健康消费服务行业为例，拆解如何通过工单流转、AI 辅助定责与影子模式分阶段落地，将反馈处理周期从三个月压缩至一个月，NPS 提升 8 分，为服务交付型公司提供可复用的闭环设计思路。

一、这个案例讲什么

这次想讲一个案例：用户反馈怎么从接收，一路沉淀为产品能力闭环。整个过程覆盖了用户反馈集成、履约检核、能力培训、整改验收多个场景。

这件事做完，我们拿到的两个结果是：需求到产品功能、服务标准迭代的周期，从三个月缩到了一个月；用户净推荐值也提了 8 分。

这次的案例，我认为对服务行业、教培行业这类产品功能需要通过人向用户交付的公司应该都有借鉴意义。

先说一下背景。我目前所在的这家公司是做健康消费服务行业的，一个典型业务场景是教练给用户提供一对一授课服务。

课后，我们经常会收到用户各种各样的反馈或是投诉。

• 教练侧：授课质量不符合预期，上课过程中的言语、行为让用户不适；沟通方式用户不喜欢。
• 课程侧：课程设计不合理、太简单或者太难。
• 场馆侧：场馆卫生、环境、温度等。

我们是希望能够成为一家「以用户为中心的企业」。那对于用户的合理需求，自然需要对自身的服务质量、产品功能、场馆环境等做出对应的改进改善。

这次的项目就是要把用户的反馈跟最终的产品迭代打穿，形成一个闭环。

二、现在的痛点

1. 用户反馈分散在各个渠道

包括 400 客服、移动端 APP／小程序上的用户反馈入口，此外还有公司组织的神秘体验官、内部员工试课输出等反馈，这些反馈都被分散在各处。

2. 需求处理过程不透明

另一方面，用户反馈上来之后，其他部门不知道这条反馈的最终流向，如果需要整改，整改到哪一步了。这些都只有对应部门的人才知道。这个过程中又有多少该重视而没有重视的需求，被搁置一边，导致用户因反馈没有响应而失望离开。

所以，我们需要有一个地方，能看到目前有多少用户需求反馈在处理中、哪些已经处理完、分别停在什么节点。

3. 需求识别判断的标准有分歧

同一个用户反馈，各部门对定责判断的标准都未达成共识，对处理方案总有微词。

所以我们就需要解决两个点：

• 有一个统一的反馈处理端口；
• 有一套大家共识的判定规则。

判定规则首先要回答：这条反馈属于什么类型、用户投诉是不是合理、对应的责任部门是谁，以及目前有没有对应的标准。

如果目前有标准，但标准没执行，那就进入对应的整改培训；如果目前没标准，那这个反馈先沉淀下来进入需求池，我们后续再去考虑是不是要迭代标准。

三、闭环路径怎么设计

1. 责任判定匹配标准

如果用户反馈判定下来是教练的责任，供给部门会接到一个工单，工单内会说明有无标准可依据。供给部门先去核实是不是存在这个情况。如果确实存在，而且违反了现有的标准，再判断是能力问题，还是执行问题。

工单的好处是每一步都有记录：谁接的、核实结论是什么、走的哪条分支、最后整改到什么程度。这就回应了前面说的痛点——其他部门不用再去问「这条到底处理了没有」，看工单状态就行。

• 能力问题：触发培训名单，流转到专门的培训部门「回炉重造」。培训完之后才能重新上岗。后面还要有验收环节，由督查部门负责验收。验收结果形成工单，再流转到对应的人。
• 执行问题：根据情况主要依靠行政手段，让他后面不要再犯这个错误。

能力问题和执行问题分开走，是因为根因不一样。能力问题是「不会」，得靠培训补；执行问题是「会但没做」，得靠机制约束。混在一起处理，整改就容易变成一刀切。

如果责任判定下来是课程侧、门店侧的问题，也是走类似的逻辑，接单核实，再按各自的方式整改，这里就不逐条铺了。

2. 培训板块要有一套规则体系

既然会触发培训，就要把规则说清楚：什么情况触发什么培训内容、由谁来培训、培训任务怎么跟踪、跟踪到哪些节点。

这套规则要和前面的判定规则能对上。判定说这个投诉对应哪类能力短板，培训就得有对应的课程包；对不上的话，工单流转过去培训那边接不住，闭环就断在这了。

3. 暂时处理不了的需求进需求池

那些目前无法处理、涉及功能开发，或者涉及标准迭代的反馈，要进到需求池，做需求池管理，然后定期处理。

需求池也不是一锅炖。我们按三个维度归：课程迭代、产品优化、标准补充。归到哪个维度，就往哪条线排期；攒到一定量触发一次迭代评审，而不是想起来才处理一次。

四、落地时先把流程重构清楚

1. 基于人机协作方案重构业务流程

这个需求涉及课程研发、供给部门、客服部门、门店端、运营部门。首先要同各个部门把整个流程到底怎么走梳理出来，这个环节的交付物是流程图。

整个流程重构，需要基于人机协作的方案重新设计。流程图中识别并标记：哪些是 AI 做、哪些是人做；需要哪些标准和规则、知识依赖和系统依赖是什么；哪几个接口要打通；以及哪些是 AI 不能做的。

2. AI 做什么

• 需求理解、责任判定；
• 投诉内容是否匹配现有标准

3. 人做什么

人主要负责核实和线下执行。

比如 AI 判定出来，这条属于供给部门的责任，人要核实「是不是我的责任」；如果是，再判断该如何整改。课程研发也一样，需要核实，如果有问题就触发培训。

4. 知识依赖和系统依赖

确定完 AI 做什么、人做什么之后，还要把系统依赖、知识依赖给到它。

知识依赖，主要是标准：

第一类是判定标准：怎么判断这条需求属于供给端、课程研发、门店运营，还是线上运营，标准是什么。

第二类是履约标准：如果属于教练履约这一块，教练本身应该执行的标准是什么。

AI 要干活，就得先把这些规则和标准给它。而且不是把文件丢过去就完了，得是结构化的、能被机器拿去比对的标准。比如「授课质量不符合预期」，对人来说可以理解，对 AI 来说太模糊，得拆成一个个可比对的点位，AI 才能拿它去匹配投诉内容。

毕竟对智能体来说，访问不到的东西等于不存在。公司从来没把「什么叫懂」写给机器，就别怪模型听不懂自己。

说到底，反馈闭环的核心不是技术，是规则——谁负责、什么时候响应、超时了怎么办。技术只是把规则跑起来的工具。而且标准也不用等定全了再动工，边做边完善标准库，比一次性设计完备再上线靠谱得多。

4.2. 系统依赖，主要是接口和数据打通

梳理清楚整个流程需要依赖哪些知识之外，还要考虑需要依赖哪些系统，哪些接口需要调用或者回调。

公司有一套「教练分」体系，这个分数会受履约质量、履约次数、职级等多方面影响。如果判定是教练责任，会影响教练分，所以定责结果也需要同步到教练档案进行记录。

打通这事看着是接口问题，实际是流程问题。定责结果写到哪个系统、什么时候写、写进去之后谁能看到、能不能改，这些都得提前定清楚，不然数据同步过去反而会乱。

5. AI 的边界在哪里

这里有一条边界要特别说清楚：不是 AI 不能扣分，而是准确率没验证完之前，扣分不能直接生效。

为什么这么定？因为「教练分」直接影响收入，定责错了，影响的是具体的人。AI 可以生成得分结果，把扣分的理由和依据也写清楚，但最终生效得人核实一道，先出工单，人确认了才落到「教练分」上。尤其是刚应用的时候，AI 判定可以很快，可快不等于准，投诉这种信息本来就不太完整的场景更是这样。这样又能提升效率，决定权也还在人手里。除非像后面影子模式说的那样，走到全自动、人只处理例外，才能让 AI 的判断结果直接对分数生效。

这条边界不是拍脑袋定的，是吃过亏的。之前在另一个 AI 督查场景，我们试过判定完直接扣分：新规则没缓冲期，一上线就动真格，结果申诉哗一下进来一百多条。教练对 AI 的判定本来就不信任，又直接动到收入，反弹比预想大得多。后来改成过渡期只记录不扣分，先让人适应 AI 督查，再小范围试点扣分，验证过效果了才敢扩范围。

这一条是整个方案的底线：验证完准确性之前，AI 的结果不直接动「教练分」。后面流程怎么迭代，这条我们不打算松。

6. 权限和隐私也要说清楚

• 哪些人可以调用这个 AI 流程；
• 最小权限应该开到什么程度；
• 涉及历史数据，不能随便调用；
• 用户投诉里的姓名、手机号都需要隐藏，只给少部分人可以看到。

五、开发之后，按影子模式分阶段投入使用

方案确认完，就可以进入开发流程。

做完之后先局部测试，投入使用按「影子模式」分阶段推进：AI 先只跟着跑、只记录不执行，拿它的结果跟人的做比对；没问题了再逐步放开，让人保留决策和例外处理。

这样一步一步放，风险可控。