一组具有代表性的 B2B 发现情境，展示相关业务讨论怎样被整理成需要人工复核的候选 Signal。
“下个月上主网，还缺欧洲节点”：RPC 销售先核实什么
RPC 销售在 Telegram 群里看到上线时间和基础设施缺口。这条消息值得优先查看，但项目身份、链范围、调用量、决策权和选型进度仍需人工核实。
以下是一个典型场景演示，用于说明产品的判断逻辑，不代表真实客户案例、客户证言、合同、收入结果或转化数据。
01场景描述
02Signal 判断
03可信度与优先级
04人工下一步
判断时关注的线索
- 出现主网、TGE、测试网或迁移的时间点
- 消息提到区域节点、故障切换、限流或多链支持等具体 RPC 缺口
- 发言更像项目侧处境，而不是供应商推广
- 项目身份、链范围、调用量、决策权与选型状态仍可由人工继续核实
一个 RPC 服务商销售长期盯着几类 Telegram 群：项目方群、开发者群、节点运维群和基础设施服务商群。难点不是搜不到“RPC”，而是分不清一句话来自正在做基础设施选择的人，还是调试接口、比较工具或推广服务的人。
看这条合成消息：
“下个月上主网。现在用的 RPC 覆盖不了我们需要的区域，正在看别的方案。”
这句话里有两个值得停下来的线索：一个带日期的业务事件，一个具体能力缺口。但它没有交代项目是谁、跑哪些链、调用量多大、发言者负责什么、是否真的要换供应商，也没有说明候选名单是不是已经定了。所以它值得尽早查看，却还不是已核实买家，更不是完整采购 Brief。
NOTICE：本文中的消息与工作情境均为合成示意，不代表真实客户、真实群聊、合同、收入或转化结果。
RPC 需求为什么很容易看错
同一个基建群里，相似的话可能对应四种完全不同的处境：
| 消息片段 | 可能代表什么 | 仍然不知道什么 |
|---|---|---|
| “节点一直报 429” | 项目遇到容量问题，也可能只是开发者调试免费端点 | 发言者有没有真实项目，能不能决定换供应商 |
| “想找有欧洲节点的 RPC” | 区域覆盖确实重要，也可能是同行在介绍自家能力 | 哪些链、哪些区域、什么负载在范围内 |
| “下个月上主网” | 可能临近真实交付节点 | 日期是否当前有效，是否和 RPC 决策有关 |
| “正在看别的方案” | 替换评估可能已经开始 | 现有合同、候选名单和决策人是否存在 |
任何一条都不足以下结论。真正值得优先查看的组合是：业务时间点 + 具体基础设施缺口，并且来源与前后语境足以支持继续人工核实。
信源本身同样重要。项目社区和同行推广群可能出现相同关键词，却代表完全不同的意图。TOP Prospect 只处理使用者主动连接且有权访问的群；哪些群进入处理范围由销售决定，产品不会替他加入群，也不会自动认证某个群一定属于买方。
什么消息该进入候选队列
规则应描述一个业务事件，而不是只堆名词。对 RPC 销售来说，值得查看的事件可以包括：
- 项目提到主网、TGE、迁移或生产环境上线时间；
- 同一条消息或附近语境出现 RPC 能力缺口；
- 发言者询问替代方案、能力或供应商比较；
- 能从语境中排除明显的供应商广告、泛技术排障和公告转发。
消息命中后，产品可以把它整理成一条候选 Signal，保留原文、来源、时间、附近语境、分类、优先级和排序理由。分数只回答一个窄问题：哪条候选记录先看？ 它不能证明发言者代表项目、拥有决策权或准备采购。
一条典型记录可以包括：
| 字段 | 可查看的输出 |
|---|---|
| 原始消息 | 触发候选记录的原话 |
| 来源与时间 | 已选择的群和消息时间 |
| 附近语境 | 记录中可查看的前后回复或讨论 |
| 候选分类 | 可能的 RPC 选型或替换讨论 |
| 优先级与理由 | 上线时间和能力缺口提高了查看顺序 |
| 人工状态 | 新线索、待跟进、已跟进或无效，由人选择 |
分类必须保留条件。“可能的 RPC 选型讨论”有可见文本支持；“真实项目准备采购”没有。
五个问题，把选型讨论和技术闲聊分开
决定是否联系之前，销售先补五个关键未知。
1. 谁在说话？
发言者是项目团队、独立开发者、节点运维，还是另一家 RPC 服务商？用户名或老账号不能认证身份，需要核实他与当前项目的关系。
2. 日期对应哪个事件？
“下个月”可能是主网、测试网里程碑、营销公告，也可能是已经变化的旧计划。事件和日期都要确认，不能直接把它当硬期限。
3. 真正的能力缺口是什么？
区域节点、故障切换、多链、历史数据、延迟和限流不是同一个问题。公开消息可能只给出一个方向，具体运行要求仍未知。
4. 哪些链与负载在范围内？
需要人工继续问链范围、调用模式、峰值负载、读写比例、区域和可靠性要求。这些属于后续技术核实，不能由公开消息补写出来。
5. 供应商决定还开着吗？
项目可能只是探索，也可能正在测试、列名单、和原供应商谈判，甚至已经决定。上线日期不能说明选型阶段，也不能说明发言者有决策权。
如果来源与语境支持项目侧处境，销售可以把候选记录改为待跟进，再决定是否适合人工联系。如果只是同行推广、泛技术排障或过期公告，就标为无效，并由人写下简短原因。
第一次联系，只问消息没说清的事
候选记录给销售的是信源与对方原话，不是外联授权，更不是已核实 Brief。一个克制的开场可以是：
“在基建群看到你提到下个月上线，还有 RPC 区域覆盖的问题。想先确认一下：这是你正在参与的项目吗？目前主要卡在哪些链或区域？”
这句话没有假装知道更多，只做三件事：
- 说明从哪里看到消息；
- 核实发言者与项目的关系；
- 先问技术边界，不直接报价。
私聊里发生的事情不在基础产品工作流内。TOP Prospect 不读取私聊、不自动联系发言者、不验证项目，也不知道后来有没有方案或成交。销售采取动作后，可以人工把状态改成已跟进；人工确认消息不符合规则后，也可以改成无效。外部业务结果不在产品能够自动得知的范围内。
回到“下个月上主网”
开头那条消息值得查看，是因为上线时间与基础设施缺口同时出现。但决定是否继续的关键信息仍然缺着。
- 尽早查看，但别叫它确定需求。 时间点和能力缺口可以提高查看顺序，不能证明身份与采购意向。
- 保留触发判断的证据。 原文、来源、时间和附近语境，让接手的人能看到同一条候选记录，而不是只相信 AI 摘要。
- 由人补齐未知。 项目角色、事件日期、能力缺口、负载、链范围、决策权和选型阶段，决定是否值得跟进。
这些核实没有通过，就停止并标为无效；如果能支持一个仍在进行的项目侧评估，销售再记录待跟进并决定下一步人工动作。产品让散落的消息更容易被找到和检查，商业判断从打开记录之后才真正开始。
延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。