## 高价值客户续约风险预警 {.case data-case-id="024"} | 字段 | 值 | | --- | --- | | 案例编号 | `024` | | 行业 / 部门 | SaaS / 客户成功 | | 角色 | 客户成功负责人 | | 难度 | `复杂` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取用量与续约日期） | 高价值客户的用量在悄悄下滑，等续约谈判时才发现为时已晚。目标：每周定时让获授权 Agent 读取高价值客户的用量与续约日期，逐个评估续约风险；一般波动（未触红线、用量正常且高置信）发回执归档（Loop 内留档），高风险信号必须人工确认后通知 CSM 与销售 Owner（受控令牌）。为防"真流失信号被当成正常波动归档"，设一条最高优先级红线：高价值客户且出现用量大幅下滑或明确流失信号时，无论置信度如何一律强制进入人工确认，绝不自动归档。指标：高风险客户从评估到 CSM 收到通知的中位数 < 4 小时；被红线捕获的客户 0 例自动归档。 - **覆盖**：定时读取用量与续约日期、逐客户评估风险、一般波动发回执归档并抽样核验、高风险经人工确认后通知 CSM 与销售 Owner（受控令牌）。 - **不覆盖**：自动制定挽回方案、自动改合同或折扣、自动联系客户。 - **假设**：有一个经授权能读取客户用量与续约日期的 Agent（通过 App/Extension）；客户清单以安全引用（令牌化批次）作为调用输入提供，原始客户资料不进入工作流；销售 Owner 受控令牌仅用系统记录，缺失标"待确认"。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：每周定时由获授权的评估 Agent 经 App/Extension 读取高价值客户的用量与续约日期，逐个评估续约风险并返回（客户标识、风险等级、置信度、理由、是否触及红线）。App/Extension 在读取侧即完成聚合与脱敏，Agent 只接收客户标识（伪名化）、用量区间、续约日期与风险要点等白名单字段，不接收客户名称、联系人、联系方式、合同金额等原始字段。客户商业数据最小披露：评估与通知只用客户标识与风险要点，不外带用量明细与合同金额。 触发：定时（计划）发起调用，调用时带入客户清单安全引用（令牌化批次）与价值分层、团队频道、评估 Agent 和审批人；原始客户资料留在数据源系统，App/Extension 凭引用在进入工作流前抽取白名单字段。 结果分流（按优先级从高到低依次判断，先判红线再判风险与置信度，最后才归档）： 触及红线（高价值客户且出现用量大幅下滑或明确流失信号）：无论风险等级与置信度如何，一律强制进入人工确认，绝不自动归档——这是最高优先级，命中即短路，不会落到下面的"一般波动"路径。 高风险或低置信（未触及红线但续约风险高、或判断置信度低于阈值）：进入人工确认，客户成功负责人能看到风险要点、命中的规则和理由，确认后通知 CSM 与销售 Owner 受控令牌（仅用系统记录携带的令牌，缺失标"待确认"）并留审计时间戳；驳回则本次失败结束、归档为一般波动并留审计，不自动改判。 一般波动（未触及红线、用量变化在正常范围且置信度不低于阈值）：发回执归档（Loop 内留档、发汇总回执）并留审计时间戳，不打扰客户成功负责人；按抽样口径抽出一部分留待事后核验，发现漏判即人工补升级。 本期无可评估客户（查询成功但名单为空或全部数据无效）：发一条"本期无可评估客户"汇总回执并留时间戳，不静默结束，也不当作取数失败。 审批：红线命中与高风险/低置信必须经客户成功负责人确认后才通知，审批本身不设自动超时、无默认通过或否决；驳回即本次失败、归档为一般波动并留审计，不自动改判。 取数失败（用量或续约数据源不可达、数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"本期无可评估客户"，也不进入归档路径。 异常：评估 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：归档、通知、零结果回执各自留审计时间戳后结束。 ``` ![案例 024 高价值客户续约风险预警：定时让获授权 Agent 读取用量与续约日期并评估风险；触及红线（高价值且用量大幅下滑或明确流失信号）无论置信度强制进入人工确认、绝不自动归档，高风险/低置信也进人工确认，确认后通知 CSM 与销售 Owner 受控令牌（令牌缺失标待确认），一般波动（未触红线、用量正常且高置信）发回执归档并抽样核验，本期无可评估客户发零结果回执，数据源不可达按取数失败告警留审计重试升级；回传不合结构停在原等待点，驳回则失败结束](../../../media/cases/fig-case-024-01-flow.svg){#fig-case-024-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **定时触发**：计划到点（每周）发起一次调用，带入客户清单安全引用（令牌化批次）与价值分层、团队频道、评估 Agent 与审批人。 2. **评估风险**：获授权 Agent 经 App/Extension 读取每个高价值客户的用量与续约日期，逐个评估并回传（客户标识、风险等级、置信度、理由、是否触及红线）；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **多路分流（先判红线，再判风险与置信度，最后才归档）**： - **触及红线**：高价值客户且出现用量大幅下滑或明确流失信号，无论风险等级与置信度，强制进入人工确认，绝不自动归档（红线是路由条件，不是仅返回的字段）。 - **高风险或低置信（未触及红线）**：进入人工确认。客户成功负责人能看到风险要点、命中的规则和理由，确认后通知 CSM 与销售 Owner 受控令牌（仅用系统记录携带的令牌，缺失标"待确认"）并留审计时间戳；驳回则本次失败结束、归档为一般波动并留审计。 - **一般波动（未触及红线、用量正常且高置信）**：发回执归档（Loop 内留档、发汇总回执）并留审计时间戳，不打扰客户成功负责人；按抽样口径抽出一部分留待事后核验，发现漏判即人工补升级。 - **本期无可评估客户（查询成功但名单为空）**：发一条零结果汇总回执并留时间戳，不静默结束，也不当作取数失败。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时评估 + 红线强制人工 + 多路分流"流程——它知道"评估风险"需要一个发消息并等待回调的 Agent 环节、"先判红线再分流"需要一个条件路由且红线优先级最高、"人工确认"需要一个审批环节、"归档与通知"各需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **真流失信号被误判为一般波动**：这是最危险的漏判。靠两层兜底——规则里把"高价值且用量大幅下滑或明确流失信号"设为永远强制人工确认的红线；再对一般波动归档结果抽样核验，发现漏判即人工补升级并留审计。 - **用量或续约数据源不可达、数据陈旧**：不当作"本期无可评估客户"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。 - **销售 Owner 令牌缺失**：Agent 不从客户名或历史记录反查 Owner，通知中该字段标"待确认"，由客户成功负责人确认时补全或指定。 - **负责人驳回升级**：本次失败结束、归档为一般波动并留审计；要重新升级就再发起一次确认，没有"AI 自动改判"。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **本期无可评估客户（结果为 0）**：仍发一条零结果汇总回执并留时间戳，让"没消息"变成可核验的记录。 - **评估 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知负责人。 红线命中与高风险/低置信必须经客户成功负责人确认后才通知，一般波动不打扰任何人。确认时负责人能看到风险要点、命中的规则和理由（含脱敏后的客户标识），所以是"有依据的快速决策"而非盲目拍板。审批只有确认或驳回两种结果，驳回即本次失败、归档为一般波动并留审计，没有"AI 自动改判"。若要更严（如红线命中的必须双审），在提示词里写明，AI 会在流程里多加一个审批环节。 本工作流对客户用量与续约数据的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统。团队频道作为调用输入提供；数据源的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），可回溯个人的字段（姓名/邮箱/证件/联系方式等）在源头即被令牌化/伪名化，并按 10% 抽查四层实际记录。数据源不可达或数据陈旧属于取数失败，走失败回执与升级，不当作"本期无可评估客户"。评估与通知遵循客户商业数据最小披露：只用客户标识与风险要点，不外带用量明细与合同金额。 - **回放集与基准**：取最近 6 个月 60 个高价值客户快照（含一般波动、高风险、明确流失样本）回放，人工基准答案为既定风险分层；一般波动判定与基准一致率 ≥ 90%。 - **红线防线**：基准为高风险或明确流失的客户（红线样本）100% 进入人工门，无豁免；被红线捕获的客户自动归档 0 例，置信度高低不影响红线路由。 - **抽样核验**：对一般波动归档结果按 10% 抽样由客户成功负责人复核，漏判率 < 1%。 - **Owner 字段**：系统记录提供 Owner 受控令牌时 100% 原样带出；缺失时 100% 标"待确认"，不出现猜测或反查的 Owner。 - **最小披露**：通知内容 100% 不含用量明细与合同金额，按 10% 抽样核对。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。 - **结果可见**：归档、通知、本期无可评估客户、取数失败四类结果 100% 各有可见回执，不出现静默成功；高风险客户从评估到 CSM 收到通知的中位数 < 4 小时。 - **分母与口径**：一致率分母为回放总数；每次运行记录评估与通知时间戳。 ### 复用与变体 - **同构迁移**：大客户健康分预警、订阅退订风险预警、渠道伙伴活跃度预警。 - **双审红线**：对红线命中的客户加签销售负责人（按令牌回填），在提示词里写明。 - **写回系统**：确认后在流程里再加一个 Agent 环节，由获授权 Agent 经 App/Extension 把风险结论写回可信的 CRM 客户档案（仅风险结论这一业务维度，伪名化标识映射回真实档案由 CRM 侧完成），以客户标识加周期为稳定幂等键、响应未知先查后写，配有限重试、升级、待处理与审计。