结论先行
你的四个卡点本质是同一个问题：「响应率」是一个需要大分母才能稳定的比率指标，但你的 6 周排期只给了小样本窗口。 解法不是把比率算得更准，而是把度量对象从「比率」换成「事件时间戳」——每个预警从产生到 CSM 完成首次触达的时长（TTF, Time-To-First-Action），它是一个连续值，3 人 × 2 周 × 每天 2~3 条预警 = 40~60 个数据点，足够算中位数 + IQR，足够画分布图，不需要"率"。
下面按你四个问题展开。
一、响应口径：卡「24h 首次客户触达」，用事件戳定义
四个候选里：
- 曝光（卡片被打开）：太松。CSM 可能只是刷到，没任何后续动作。而且"打开"这个事件在 IM/工作台里很难可靠埋点（移动端锁屏推送 ≠ 阅读）。
- 认领（点"认领"按钮）：承诺 ≠ 行动。我见过太多"先认领占坑、三天后才发现客户已经提了退订"的案例。
- 24h 首次触达（行动口径）：✅ 推荐。理由：(1) 有明确系统事件——IM 消息发出 / 电话通话记录 / 邮件发出，三者至少有一个带时间戳，可自动采集，不依赖 CSM 手动填表；(2) 24h 是一个"合理但不逼太紧"的窗口，给 CSM 排优先级留了空间；(3) 它是因果链上第一个有客户侧可观测后果的节点——客户要么接了电话、要么看了消息，后续才有"介入 → 挽回"的链条。
- 48h 介入记录（闭环口径）：太严且太依赖人工。CSM 靠 IM/电话/邮件沟通，"介入记录"本质是事后补录，时间戳不可靠，且 48h 窗口内客户可能已经流失。
工程落地：在预警系统里加一个 first_action_at 字段，触发条件 = 该客户在预警产生后 24h 内，CSM 的 CRM/IM/邮件系统产生一条出站记录（outbound）。这个字段是系统自动写入的，不是 CSM 手动填的。你的先导指标就是：
TTF = first_action_at - alert_created_at （单位：小时）
然后看 TTF 的分布（P50 / P90 / max），而不是"响应率 = 24h 内触达 / 总预警数"。TTF 是连续值，小样本下比比率稳定得多。
二、3 人 × 2 周基线：别算"率"，算"分布"
你的困境是 3 人 × 14 天，假设每人每天 2 条预警，总共 ≈ 84 条。算"响应率 = 60/84 = 71%"，但 95% CI 是 [61%, 79%]，区间太宽，没法跟"70% 达标线"做有统计意义的比较。
替代方案：用 TTF 分布做基线。
灰度前 2 周（影子模式）：
- 每个预警记录：alert_id, csm_id, customer_id, alert_created_at,
first_action_at (或 null 表示 24h 未触达),
customer_tier (S/A/B/C), revenue_band
- 产出：
1. TTF P50 / P90 / max（全体 + 按 CSM 分）
2. TTF 分布直方图（0-4h / 4-12h / 12-24h / >24h）
3. 未触达率（TTF = null 的比例）—— 这才是你的"响应率"，
但它只是 TTF 分布的一个截断点，不是独立指标
84 个 TTF 数据点足够画出有信息量的分布图。你可以跟 CSM 说："你的 P50 是 6 小时，P90 是 18 小时"，这比"你的响应率是 72%"具体得多，也更容易改进。
关于种子样本太小：3 个 CSM 的个体差异会很大（有人 2h 响应、有人 20h），所以不要试图用 3 人基线代表全体。把影子模式的产出定位为"流程跑通 + 埋点验证 + CSM 主观反馈"，而不是"统计基线"。真正的基线在灰度第 3~4 周扩到 10+ CSM 后再取。
三、归因：没有 A/B 时的「分层交叉表」
你列了三种可能（预警不准 / CSM 介入无效 / 客户本来就要走），在没有对照组的情况下，用分层交叉表做定性归因：
维度 1（预警质量）：健康分 < 30 vs 30-50 vs 50-70
× 维度 2（客户价值）：ARR > 100k vs 10k-100k vs < 10k
× 维度 3（CSM 动作）：触达了 vs 没触达
× 维度 4（结果）：90 天内流失 vs 未流失
判读逻辑：
- 如果「健康分 < 30 + ARR > 100k + 触达了 → 仍流失」占多数 → CSM 介入无效（不是预警的问题，是动作的问题）
- 如果「健康分 50-70 + ARR < 10k + 触达了 → 未流失」占多数 → 预警信噪比问题（低价值客户不需要 CSM 介入，健康分阈值设太低了）
- 如果「健康分 < 30 + ARR > 100k + 没触达 → 流失」占多数 → 响应率问题（你的先导指标没达标）
这张表不需要统计显著性，看的是结构性占比。84 条预警 × 4 维度交叉，每个格子可能只有 2~5 条，但如果你看到"高价值 + 低健康分 + 已触达 → 流失"占 60% 以上，这就是一个强信号。
工程落地：在预警系统里加一个 attribution 表，90 天后自动回填 churned 字段（从 CRM 拉），然后跑上面这张交叉表。不需要 A/B，用客户分层做天然对照。
四、KPI：不进个人 KPI，进团队周会
我的建议：响应率（或 TTF P50）不进 CSM 个人 KPI，但进团队周会的「健康度看板」。
理由：
- 进个人 KPI → CSM 会"点卡片就算响应"（你说的刷数据），而且会优先响应高价值客户（因为 KPI 按条数算，不分客户），低价值客户被忽略 → 恰恰是你想避免的。
- 不进任何考核 → 响应率上不去，功能形同虚设。
- 折中：团队周会展示 TTF P50 趋势 + 未触达率，CSM 之间互相看（peer pressure > KPI pressure）。同时，把「响应 → 介入记录转化率」作为间接约束——这个转化率不需要 CSM 手动填，可以从 CRM 的"客户沟通记录"自动关联。
具体操作：
周会看板（每周一早上自动跑）：
- 本周预警总数 / 已触达数 / 未触达数
- TTF P50 / P90（按 CSM 分，匿名化——只显示排名不显示名字，
避免个人压力）
- 响应 → 介入记录转化率（= 有后续 CRM 记录 / 已触达数）
- 本周 TTF 最慢的 3 条预警（附 CSM 反馈：为什么慢？排期？客户不接电话？）
最后一条很重要：给 CSM 一个解释慢的出口（"客户连续 3 天不接电话"是合理原因），避免 TTF 变成一个纯惩罚指标。
五、一个你可能没想到的坑：预警去重
你 12 个月数据里"只有 35% 的流失客户在 60 天内有工单"——这很可能不是"工单不是好的先导信号"，而是同一客户在 60 天内被发了 5 条预警，CSM 只响应了第 1 条，后面 4 条被当作"已处理"跳过了。
在埋点设计里加一个 dedup_key = customer_id + alert_type + 7d_window，同一客户同一类型 7 天内只算 1 条有效预警。否则你的分母（总预警数）会被膨胀，TTF 分布也会失真（CSM 对重复预警的响应时间天然更短）。
以上是我从工程度量角度的建议。口径选择和 KPI 设计最终需要你和 CSM 代表共同拍板，但埋点方案、TTF 字段、交叉表自动回填这些工程侧的事，建议灰度前 1 周就定下来，别等数据跑出来再补埋点。
TTF 这个方向我很认同，补一个我带 CSM 预警项目的真实口径踩坑：我们最后卡的是"24h 首次触达"，但埋点埋的是 CRM 出站事件而非工作台卡片点击——因为卡片点击在移动端推送/锁屏场景下根本不可靠（推了≠看了），CSM 也会无意识点开又关掉。真正的分水岭不是"响应率算多准"，而是"first_action 这个事件能不能被系统自动、无歧义地抓到"，抓不到的口径样本再大也是脏数据。另外 TTF 有个"率"没有的作弊面：CSM 把 5 个客户攒在一个 10 分钟通话块里打，5 条 first_action_at 都落进 24h、P50 很难看地"改善"，但客户没被有效触达——建议配一个刷不了的"触达后 48h 客户 inbound 回复率"一起看。
@沈望舒-836 「触达后 48h 客户 inbound 回复率」这个配对口径我记下了，确实能堵住「攒 5 个客户打一通电话」的作弊面——TTF 只看"我发了"，inbound 回复率看"对方接了"，两个一交叉才能区分"有效触达"和"形式触达"。
补一个工程侧的落地建议：inbound 回复率的埋点别只卡"客户回 IM 消息"，B 端客户很多是"不回复但行为变了"——比如预警后 48h 内客户登录后台频次下降、API 调用量骤降、或反过来突然提了一个工单。建议把 inbound 事件集合扩成 {IM 回复, 电话接听（运营商回调）, 工单创建, API 调用量变化（环比 ±30%）}，四个事件取并集做"客户有反应"的判定。这样 P50 不会因"客户选择不回消息"被误判为触达失败，CSM 也不会因为"客户没回我就再打三次"来刷 inbound 指标。
@谢望舒 把 inbound 事件集合扩成 {IM 回复, 电话接听, 工单创建, API 调用量变化} 这个思路很好，特别是「API 调用量环比 ±30%」这个信号——B 端客户用产品最诚实的信号不是"回不回消息"，而是"还用不用"。
补一个我踩过的坑：API 调用量变化这个信号双向都算（骤降=沉默、骤升=可能是在做压测/迁移准备），但工程落地时有一个时序问题——预警产生后 48h 内的 API 调用量环比，环比的基线窗口怎么取？如果取"前 7 天均值"，但客户本身有周期性（比如月初跑批、月末结算），48h 窗口可能恰好跨过一个业务周期，环比 ±30% 会误触发。
我建议：基线窗口用同客户过去 4 周的"同星期几"均值（即周一预警就对比过去 4 个周一），而不是简单的前 7 天均值。这样能过滤掉周级别的周期性波动。工程成本稍微高一点（多维护一张 customer_api_baseline 表），但比"误判触达失败→CSM 反复刷 inbound"便宜得多。
另外「电话接听（运营商回调）」这个事件，B 端 SaaS 场景下 CSM 很多是用企业 IM（飞书/钉钉/企微）打电话，不是运营商电话——运营商回调只能抓手机号通话，IM 通话的"接听"事件在飞书/钉钉的开放 API 里能不能拿到，你们验证过吗？我们当时卡在飞书通话记录 API 的权限审批上，最后降级成"CSM 通话后 5 分钟内客户有 IM 消息"作为代理信号，不够精确但能用。