先把话说清楚：关于加好友，系统里能可靠查到的只有「当前状态快照」——每条客户线索现在停在哪个状态。它有三个硬限制（历史会被覆盖、库里没有「谁通过了」的数据、没有逐次加友流水），所以它能告诉你「现在卡在哪」，但算不出真正的通过率，也做不出可信的逐日趋势。这份报告只讲能确定的，不确定的地方明确标出来——不再拿快照硬凑成漏斗。
⚠ 以下均为 2026-07-02 某时刻查 Supabase enterprise_leads 的快照；线索状态实时变动，数字会随运营进展变化。
论断来源标注：实测 查库确凿 · 推测 系统备注里的猜测、未证实 · 未知 当前数据答不了。
当前有 232 条线索停在「加不上」（占名单 58%），其中 221 条系统标记为「搜不到人」。请求根本发不出去，是最大的一段流失。
Supabase 里「已通过」记录 = 0 条、通过标记也全空——系统根本没在记录「谁通过了」（见 §4）。真实通过率库里没有这个数据，得人工核对好友列表，本页不显示推测值。
这张表只存每条线索的最新状态、会被覆盖，也没有逐次加友流水。所以「逐日趋势」「尝试成功率」都做不出来，本页不再给这两个数（见 §5）。
「能不能把请求发出去」（真问题，需甲方一起想办法）和「发出去后通过率多少」（测不准，先得把统计修好）是两回事。在把通过检测修好、加友流水补上之前，任何「通过率 = X%」都不可信，包括这个 0%。
401 条名单此刻各停在哪个状态，来自生产库 enterprise_leads，2026-07-02 查询。注意：这是「此刻的分布」，不是「累计尝试了多少、成功多少」——同一条线索被反复处理时只保留最新状态，历史看不到（详见 §5）。
你可能会问：「已发请求」(103) 怎么比「加不上」(232) 还少？发出去的不该更多吗？ 两个原因叠加——① 这是快照不是累计：「已发请求」是个会流走的中间状态（对方一通过就该转走），「加不上」是终态、会一直攒着；② 这批名单「搜不到人」的比例本就高（真因见 §3，跟"缺微信号"无关——手机号在中国基本就是微信号）。所以在快照里「加不上」多于「已发请求」并不违背逻辑——但要注意，它不能被读成「我们总共只发了 103 个请求」。
系统给每条失败自动打了原因标签。注意这些是脚本按结果自动贴的，不是逐个客户人工核实的诊断。
| 失败标签 | 条数 | 占加不上 | 说明 |
|---|---|---|---|
| 搜不到人 | 221 | 95% | 按名单信息在企微里找不到这个人，请求发不出去 |
| 搜到但卡片打不开 | 8 | 3% | 找到了但无法进入添加 |
| 未记原因 | 3 | 1% | — |
先澄清：在中国，手机号基本就是微信号——名单里「只有手机号、没单独填微信号」不影响加好友，手机号本身就能搜到人。加企微好友主要就是「按手机号搜人」。所以别把"搜不到"归因成"名单缺微信号"。
那还是搜不到，真因待验证 推测：这 221 条系统备注是「搜不到（可能没开手机号搜索）」——但「可能没开手机号搜索」是脚本预先写死的默认文案（wecom_add_agent.py），只要搜不到就统一贴，并没逐个核实。真正可能的原因：① 对方关了「允许通过手机号搜索」隐私开关 ② 号码是错号 / 空号 / 已注销 ③ 搜索被风控限频 ④ 自动化误判。要定位到底哪个为主，得抽一批人工核。
· add_status = '已通过' 的记录：0 条
· 通过通知标记 passed_notified_at：全部为空
· 同时「已发请求」挂着 103 条。
结论只有一个：系统里根本没有任何一条「谁通过了」的数据。这 103 条请求发出后有没有被接受，库里没记。
0 的意思是「没有记录」，不是「确认没人通过」——这两者在数据上无法区分。系统当前没有在可靠地回填「已通过」这个状态。
按你的要求，库里没有的数据本页不显示：所以这里不给任何「通过率 = X%」（包括 0%），它现在就是「无数据」。
真实通过率Supabase 里没有——要拿到，只能人工核对一遍企微好友列表（数已发出的 103 条里实际加上几个），或先把「已通过」的自动回填修好。在那之前，「通过率」这一栏是 「无数据」，不是 0%。
这一节是为了不再犯「拿快照硬凑趋势」的错。把家底摊开。
passed_notified_at 全空——库里没有通过数据。enterprise_leads 只存最新状态、会被覆盖，没有逐次加友流水表，按更新时间硬切每天会失真（这是上一版被指出的错，已撤下）。系统里只落了 一条运营当日汇总：07-02 某运营处理 27 条 → 待通过 20 / 失败 7 / 通过 0。这条的比例（大部分发出去了、失败少）反而是健康的，和上面「累计快照里加不上占多数」正好相反。为什么相反、哪个更代表真实情况，需要运营侧一起核对——很可能累计快照被早期批次和自动化跑批里的大量「搜不到」拉偏了。在补齐流水前，这条留作线索、不作结论。
甲方侧 是「有大有小」对自己客户有话语权、能改善的；我方侧 是 Akke 工程 / 运营要补的。
① 先对齐「0% 是测不准、不是定论」；② 聚焦真问题——怎么让请求发得出去（核号码有效性 + 引导客户主动加 / 开手机号搜索，甲方主导）；③ 我方并行补流水表 + 修通过检测，下一轮复盘才有可信的通过率和趋势。