一、项目背景

我们给一家 SaaS 企业做客户成功数字化，它的问题是客户从试用到增购，中间的动作是断的。销售盯签单，成功经理盯上线，客服盯工单，各管一段，谁也没对客户的整体状态负责。结果试用快到期的用户没人提醒，刚上线的用户遇到问题没人跟，等到要续费了才发现关系早就凉了。

这家公司其实有数据，CRM、工单、用量监控都有，但数据是孤岛，没人把它们串成一条客户旅程。我们进场时的目标，就是用多智能体把这条旅程编排起来，在关键节点主动做动作，而不是等问题找上门。

这件事的难点在协调和节奏。触达太频繁用户烦，太少又错过时机；不同阶段的动作还互相冲突，比如续费前还在推试用功能就是添乱。所以不是一个机器人发消息，而是一组角色各管一段、彼此通气。

二、落地场景

我们把客户旅程拆成几个阶段：试用、上线、成长、增购、续费、流失预警。每个阶段由一个智能体负责，它读这一阶段相关的数据，判断该不该动作、动作什么。阶段之间由一个编排智能体协调，保证一个客户同一时间只收到一个主线动作，不会被不同智能体同时打扰。

具体动作包括：试用第七天没激活的，推引导任务；上线满两周用量低的，安排成功经理介入；出现增购信号的，转销售跟进；用量骤降的，进流失预警并触发关怀。所有动作先生成建议，关键节点的人工确认后才真正触达，避免全自动翻车。

我们把它接进 XpShop 的会员和消息体系，触达渠道统一走站内信加企微，触达结果回写旅程，形成闭环。

三、关键技术挑战与解决思路

第一个难点是阶段划分。客户状态是连续的，硬切阶段容易误判。我们没有用单一阈值，而是用一组信号加权，比如活跃度、功能覆盖、工单情绪、支付记录，综合判断落在哪个阶段，边界模糊的客户会被标为待人工复核，不强行归类。

第二个难点是防打扰。多个智能体同时想触达一个客户是常态。编排层做了一道合并：同一客户的待办动作按优先级排队，只保留主线，其余延后或合并成一条消息。这个机制上线前我们没重视，结果灰度时一个客户一天收到三条，被投诉，赶紧加了合并。

第三个难点是效果回收。触达有没有用，得有反馈。我们把每个动作和后续的行为变化挂钩，比如推了引导任务后七天内激活率有没有提升，用这些数据反过来调触发条件和时机，形成一个自优化的环。

案例片段（已脱敏）：某批试用客户编排规则片段，触发条件为"注册满 7 天且核心功能使用次数小于 2"，动作是推送分步引导任务并由成功智能体标记。该批 320 个客户中，收到引导后 7 日内激活 118 个，激活率 36.9%，较对照组自然激活率 21.3% 提升明显。编排层同期拦截了 47 次跨阶段重复触达，避免了同一客户被试用引导和续费提醒同时打扰。

案例片段（已脱敏）：编排层防打扰合并配置片段，同一客户的多智能体待办进入编排队列后按优先级排序，仅保留主线动作，其余标记为延后并附原因。灰度期间该机制拦截了 47 次跨阶段重复触达，客户单日接收消息数上限设为 1，超出转入次日队列。被拦截的客户里约六成在次日收到了合并后的单条引导，投诉率随之回落，成功经理也省了重复跟进。配置上线后我们还加了一条兜底：若客户连续三天无任何触达，编排层主动触发一次关怀，避免因为防打扰而彻底失联，反而把客户弄丢了。我们把这条兜底和流失预警打通，连续静默的客户会自动升级给成功经理，既不打扰又不怕彻底失联，两端都顾到了。灰度后期的流失率因此又往下走了一截。

四、效果数据

跑了一个季度我们看几个核心数。关键节点的触达覆盖率，也就是该动作的客户端真正收到并处理的比例，提升到九成以上；试用转付费率较之前提升约八个百分点；流失预警客户的挽留成功率有改善，流失率同比下降约两成。

最关键是投诉没涨，因为防打扰机制兜住了体验。文中数据为项目复盘口径，已做脱敏。

五、可复用经验总结

客户旅程这种事，单智能体做不了，它既要懂全局又要管细节，必然顾此失彼。我们用多智能体分工加一个编排层协调，效果比一个万能机器人好，前提是编排层必须把防打扰做扎实，否则好心办坏事。

节奏比内容更影响体验，这是我们灰度时被投诉换来的教训。另外效果回收不能省，不回收就不知道触发条件对不对，旅程会越跑越歪。阶段加编排的思路能迁移，员工培训和售后安装我们也拆了各自的阶段来跑，只是阶段定义不同。