续约谈判前，只靠“销售觉得关系不错”不足以判断客户状态。但印象回答不了三个问题：客户实际用了什么、我们答应过什么没兑现、续约时对方会拿什么压价。做法是给每个进入续约窗口的客户生成一张健康审计卡：AI 从授权系统汇总使用活跃、工单支持、未结承诺与价值证据，事实与风险假设分列，由 CSM 逐项确认，不输出一个看不懂来源的健康分。在资料授权、权限与接入验证后，可由开沿 Agent 逐户整理。
审计卡的五个区块
| 区块 | 看什么 | 常见误读 | 确认角色 |
|---|---|---|---|
| 使用与活跃 | 近期登录、核心功能调用、账号覆盖变化 | 把数据缺失当作客户不用 | CSM 核对数据覆盖面 |
| 支持与工单 | 未结工单、重复报障、严重级别趋势 | 把工单多直接当作不满 | 支持负责人 |
| 未结承诺 | 交付、排期、培训等承诺及到期日 | 把口头承诺当作已兑现 | 销售与 CSM 双确认 |
| 价值证据 | 可向客户展示的改善结果 | 把内部口径当作客户认可 | CSM 与客户核实 |
| 续约事项 | 用量变化、预算线索、竞品动向 | 把竞品线索当作结论 | 销售主管 |
两个最容易做错的判断
活跃数据缺失不等于客户没在用。使用数据可能只覆盖部分产品线，客户可能经由共享账号或线下流程使用，关键动作也可能发生在未接入的系统里。审计卡要为每个区块标注覆盖范围，缺口单列，让 CSM 决定补数据源还是线下核实，而不是默认缺口等于零。
低用量也不等于将要流失。有的客户集中在某个季度用满，有的只用核心模块但多年续费稳定。判断要看客户自身的使用基线和变化趋势，应结合工单变化、承诺履行和对接人状态判断；单项异常也可能值得核查，但不能仅凭低用量断言流失。
事实与假设分列，不给黑箱分
审计卡每一行要么是事实：系统记录、带时间戳、可回查出处；要么是假设：某人基于事实提出的解释，标注提出人与依据。假设不应被折算成一个总分：黑箱健康分的问题不在分数本身，而在续约复盘时说不出依据。可行的做法是规则版本化生成候选，Agent 跨系统补证据，人确认结论，与商机停滞治理的思路一致。
方案示例
以下为场景示例。某 SaaS 公司在续约前 30 天触发审计：Agent 从授权的 CRM、工单与使用系统生成五区块初稿，标出"上线培训承诺未关闭""近一季工单集中在报表模块"这类条目，CSM 逐项核完并补两条例外说明，再据此定续约策略与补救动作。Glean 故事中 Storable 的 CSM 审计机制可参考：让每个账户都能做一次价值回顾，而不是只挑大客户抽查；其公布的工时与百分比数字属厂商自述，本文不引用，也不承诺同等效果。
试点怎么验收
试点先只读：选 10 到 20 个账户，CSM 预先标出关键事实，核对审计卡有无漏项、错归、把假设写成事实。运行期记四个数：事实核对准确率、假设被确认与被推翻的比例、账户覆盖数、单户复核时间。审计发现的补救项要有责任人和回写，不能停在卡片上。
规则如何版本化、异常如何变成责任队列，见商机长期不动怎么自动发现；带证据链的巡检信号怎么设计，见项目交付风险怎么提前发现。更多落地方法可顺着AI Agent 落地专题阅读。要把审计卡接进现有 CRM 与工单系统，可了解AI Agent 服务。
来源说明：机制参考 Glean 客户故事 Storable 的 CSM Account Audit Agent，即客户成功团队对账户做逐户价值与状态审计（原文：https://www.glean.com/resources/customer-stories/storable ）。该故事为厂商发布、未独立验证，本文不采用其效果数字，场景为本土方案示例。
