一组具有代表性的 B2B 发现情境，展示相关业务讨论怎样被整理成需要人工复核的候选 Signal。
“这几笔是不是系统误判？续约也快了”：KYC 服务商 BD 先核实什么
几笔有争议的 KYC 决定和临近续约时间，可以让一条候选记录进入优先查看队列，但不能证明误拒率，更不能证明已经开始更换供应商。
以下是一个典型场景演示，用于说明产品的判断逻辑，不代表真实客户案例、客户证言、合同、收入结果或转化数据。
01场景描述
02Signal 判断
03可信度与优先级
04人工下一步
判断时关注的线索
- 发言者质疑具体 KYC 决定，而不是泛泛讨论 KYC
- 附近语境提到续约或合同时间
- 总体审核量与最终人工复核结果仍未知
- 是否更换供应商、发言者角色与决策权需要人工确认
一个身份验证服务商的 BD，在 Telegram 支付风控群里看到一小段对话：
“这个月又有几笔 KYC 被拒了。”
“运营复看时觉得其中两笔不太对，但完整复核还没出来。”
“现在的合同也快续约了，我想先弄清楚这算不算正常。”
两个信息同时出现，确实值得停下来：有争议的审核决定，以及合同时间。但消息没有给出总审核量、人工复核的最终结论、准确续约日期、发言者角色，也没有证据表明团队正在评估替代供应商。
“几笔被拒 + 续约临近”只能说明值得先看；在样本口径、最终复核和采购动作没有确认前，它不是误拒率，也不是换供应商机会。
NOTICE：本文中的消息与人物均为合成示意，不代表真实客户、采购、合同、收入或转化结果。
缺少分母，整件事的含义都会变
如果群消息说“三笔被拒，其中两笔看起来不对”，很容易有人直接用二除以三，把结果写成误拒率。这个计算不成立。
三笔被拒不一定是完整样本。真正缺少的分母，是同一时期完成了多少次 KYC 审核。那两笔“看起来不对”，也可能只是运营人员的初步判断，还没有经过最终复核或申诉结论。
这段公开对话只能支持有限的事实：
| 对话中可见 | 仍然未知 |
|---|---|
| 有几笔 KYC 决定被拒 | 总审核量和实际拒绝率 |
| 运营质疑了其中部分决定 | 最终是否推翻、依据是什么 |
| 发言者说续约“快到了” | 准确合同日期、通知期限，以及是否还能改变续约安排 |
| 发言者想知道这种情况是否正常 | 所属公司、岗位、决策权，以及是否在看替代方案 |
小账户里的两笔争议也可能很重要，大审核量也不代表可以忽略。真正需要核实的是错误类型、是否重复出现，以及对运营造成了什么影响，而不是从残缺样本外推出一个比例。
产品能整理到哪一步
在使用者主动连接且有权访问的群里，TOP Prospect 可以把这段讨论筛出并整理成候选 Signal，同时保留不确定性：
| 字段 | 可查看的输出 |
|---|---|
| 原始消息 | 保留信息残缺的原话 |
| 来源与时间 | 可返回原语境的群和消息时间 |
| AI 摘要 | “发言者质疑数笔 KYC 决定，并称续约临近；样本与决策背景仍不完整” |
| 排序理由 | 可能的服务质量问题与可能的合同节点同时出现 |
| 待核实问题 | 分母、最终复核、错误模式、运营影响、准确合同时间、角色和评估状态 |
| 人工状态 | 新线索；尚未核实 |
这条候选记录可以排在泛泛的“KYC 很烦”之前，但仍不能证明现有供应商做错了、发言者代表买方，或供应商替换真的可行。
人工审查时必须先打开原对话。附近如果有人补充“这是沙盒测试”或“证件已经过期”，整条消息的含义都会改变。脱离上下文的摘要不够。
先核实服务问题，再核实商业窗口
第一组问题应先搞清楚 KYC 流程里发生了什么：
- 分母是多少？ 同一时期完成了多少次审核，其中多少次最初被拒？
- 谁复核了争议案例？ 是最终运营复核、申诉结果，还是初步印象？
- 失败发生在哪一环？ 证件采集、活体、制裁筛查、数据不一致，还是政策阈值？
- 是否存在重复模式？ 同一种证件、地区、设备条件、流程或接入路径？
- 造成了什么运营影响？ 增加人工审核、延迟开户、用户放弃、客服工作，还是暂时没有可确认影响？
服务问题说清后，再检查合同时间：
- “快续约”具体是什么？ 续约日、解约通知期和系统切换窗口是三件不同的事。
- 谁在发言，他能决定什么？ 发言者可能只是来问经验的运营人员，不是选择服务商的风控负责人。
- 真的在评估供应商吗？ 临近续约的抱怨，也可能最后通过内部调整、规则修改或原供应商修复解决。
这些是人工核实问题，不是 AI 应该补齐的字段。如果团队有正当联系路径，一个克制的人工开场可以是：
“看到你提到几笔 KYC 决定有争议，合同也快续约了。想先确认一下：这些案例已经完成最终人工复核了吗？同一时期总审核量大概是多少？先把样本口径对齐，才好判断是不是重复问题。”
产品不会替销售发送消息，也不会读取回复或认证发言者。是否适合联系由 BD 决定，记录里只写对方实际确认的事实。
人工状态记录的是工作，不是真相
现有状态字段可以避免候选记录被遗忘，同时不夸大它：
- 待跟进： 原讨论值得继续看，团队写下最重要的未解问题。
- 已跟进： 人已经通过合适渠道采取动作；这个状态不说明对方答了什么。
- 无效： 人工确认消息与规则无关、只是测试、同行推广或其他不相关情况。
- 其他外部业务结果即使由团队另行记录，也只能是用户提供的事实，产品不会从消息或操作中自动认定。
任何状态都不能证明某次拒绝是误判，也不能证明更换供应商的窗口存在。它只是团队追踪自己查看过什么、做过什么的内部记录。
规则只能由团队复盘后手动调整
查看过一批候选后，团队可以比较自己的备注：哪些只是泛泛抱怨，哪些出现了经过复核的争议结果，哪些同时接近真实合同节点。
关注逻辑的任何变化都由人完成：排除供应商推广，要求消息提到人工复核，或者调整某些信源的查看顺序。不能把它写成系统会因为状态变化，自动学会某句话代表真实买家或自动提高权重。
复盘的目的也不是制造一个没有依据的转化率，而是让下一次判断更严谨：没有分母不算比例；内部质疑不等于确认误拒；“快续约”不等于采购已经开始。
回到那几笔有争议的 KYC 决定
开头那段对话有价值，是因为可能的服务质量问题和可能的合同时间同时出现，比普通抱怨更值得查看。
它仍有三条硬边界：
- 样本不完整。 几笔有争议的决定无法说明误拒率。
- 商业窗口未确认。 续约措辞不能证明供应商评估已经开始，也不能证明发言者有决策权。
- 产品止于可复核记录。 原文、来源、上下文、优先级和人工状态帮助团队查看；核实与联系仍由人完成。
真正有用的 Signal 不是“两笔里有几笔误判”，而是“争议决定与合同时间同时出现，现在该把缺失事实问清楚”。
延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。