先换掉衡量的指标
360 智慧生活在讲这组落地数据时，没有把「机器人接待量」或「分流量」放在最前面，而是选了「独立解决率」。理由给得很直白：AI 参与过一次服务，不等于 AI 真正创造了价值。只有问题在智能体这一侧真正结束、不再继续消耗人工，产能才算成立。
按公开披露，目前在线独立解决率达到 83% 以上，热线独立解决率超过 60%。
两层结构：一层分流，一层排障
做到这个水平的方式，不是拿大模型直接替换传统 IVR。360 智慧生活把服务过程重新拆了一遍，采用「分流智能体 + 单品智能体」的双层结构。
上层只承担快速识别与路由：原则上在 3 句话内判断用户对应的是哪类产品，准确率达到 90% 以上。进入下层之后，再由摄像机、门铃、记录仪等不同品类的智能体，按照各自产品的特点完成深度排障。
起点选得很具体——「摄像机无法联网」这类高频售后问题。这个选择本身有讲究：高频意味着样本足够，边界清晰意味着效果容易验证。
热线那条线的数字
热线侧的变化幅度更大。原来平均需要 5.6 分钟的 IVR 流程，缩短到 1.1 分钟；智能服务满意度从 30% 提高到 70%；整体交互时长下降约 80%。热线智能体日均可以分流人工 800 次以上。
满意度从 30% 到 70% 这个跳幅，反映的其实是原来的起点有多低——传统 IVR 的按键式导航本身就是一个容易让人中途放弃的环节。
「46 名等效人力」这个口径该怎么读
按当前服务量折算，这部分能力相当于约 46 名人工客服的等效服务产能，企业测算年化降本超过 400 万元。
这里有一个容易被误读的地方。46 名等效人力不等于减少 46 个人，它更接近一次产能换算：原本要靠增员才能承接的增量服务量，现在可以由智能体分担。公开案例真正强调的是「下一轮业务增长时还需要增加多少人」这个变量，而不是裁掉了多少人。
年化 400 万元同样要连着口径看。它来自企业测算，覆盖的是这部分能力的折算价值，公开信息没有披露测算的具体构成。
这套结构的复用边界
双层结构之所以在售后场景成立，是因为「判断品类」和「深度排障」这两件事的能力要求差异足够大，拆开之后各自都能做得更好。
换一个条件就未必。如果品类单一、问题高度同质，分流层的价值会下降；如果品类之间的排障逻辑差异很小，单品层的重复度会变高，拆分的收益也随之变小。
所以这套结构更像一条判据，而不是一个模板：什么时候该拆，取决于「识别」与「解决」之间的能力跨度有多大。
独立解决率与分流量，差的不是一个词
这两个指标衡量的是服务链条上不同的位置。
分流量统计的是「有多少次对话被智能体接走了」，衡量的是覆盖范围。独立解决率统计的是「有多少次问题在智能体这一侧结束」，衡量的是结果。一个智能体可以承接大量对话却把绝大多数转回人工，这种情况下分流量好看，独立解决率却很低。
把独立解决率当作主指标，会改变优化方向：团队不再追求「接得更多」，而是追求「结束得更干净」。这两件事对知识库质量、排障话术深度和转人工时机的判断，要求并不一样。
这个指标也有边界。它没有区分问题的难度——如果智能体接的都是简单问题，高独立解决率并不说明能力强。要看这个数字有没有意义，还得同时看它承接了哪些类型的问题。
从按键到对话，改变的不只是等待时间
IVR 从平均 5.6 分钟缩短到 1.1 分钟，容易被理解成「快了」。更关键的是交互形式本身换了。
按键式导航要求用户先把自己的问题翻译成系统预设的菜单选项，翻译错了就得退回重来。对话式服务允许用户直接描述问题，把「翻译」这一步交给系统。这也是满意度能从 30% 跳到 70% 的主要原因——原来的低分有相当一部分来自导航本身，而不是来自客服能力。
同样值得注意的是热线场景的约束：语音输入没有撤回键，用户中途改口的成本比打字高，所以热线侧的独立解决率（超过 60%）低于在线侧（83% 以上）是符合预期的，这两个数字不适合直接比较。
这套做法里还可以追问的几处
公开信息里没有披露两层结构之间的转接率，也没有说明分流层判断错误时会发生什么。这两项对实际体验影响很大：分流错了，用户会多经历一次「问错人」的过程，而那正是这类改版想要消除的东西。
另外，「单品智能体」的维护成本会随着品类数量增长。品类变多之后，这套结构能否保持同样的效果，公开材料没有给出答案。
把这两点放在一起看，这套双层结构的适用条件其实很具体：品类数量可控，且品类之间的排障逻辑确实存在差异。条件变了，结构就要重新评估。
还有一层容易被忽略的成本：分流层与单品层都需要持续维护，但维护内容并不相同。分流层随品类增减调整，单品层随产品迭代调整。前者变化慢，后者变化快，两者的更新节奏要分开安排。
什么样的售后问题适合交给智能体
从公开描述看，360 智慧生活挑的是「高频、可枚举、排障步骤相对固定」的问题。摄像机联网失败是典型例子：症状明确，原因可以穷举，每一步的处理动作都能写下来。
与之相对的是另一类问题——症状模糊、原因跨多个系统，或者需要结合订单与账户历史才能判断。这类问题即便智能体能接，也需要先做大量信息归集；转人工之前的那段准备是否由智能体完成，对整体效率影响很大。公开信息没有披露这部分是怎么处理的。
这个区分对准备上智能体的团队有直接参考价值：先判断问题的「可枚举程度」，再决定这一层交给谁。把不可枚举的问题硬塞给智能体，独立解决率会很快给出反馈——只不过那时问题已经发生在用户侧了。
另一个常被忽略的环节是分流本身的成本。判断品类需要读取用户描述与可能的上下文，这一步如果做重了，整体响应时间会被拉长；做轻了，判断准确率就掉。90% 以上这个数字背后，是这层取舍的结果。
可以带走的几条
其一，把衡量指标从「接待量」换成「独立解决率」。前者衡量覆盖，后者衡量价值。
其二，先做高频且边界清晰的问题。这两个条件决定了样本量与可验证性。
其三，识别与解决分给不同的智能体。一项任务要求的能力跨度越大，单个智能体越难两头都做好。
其四，报告等效人力时说明折算方式，避免把产能当量读成裁员数字。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。