RPC 服务商销售怎样在主网上线前发现真实选型需求

判断时关注的线索

项目方给出主网或 TGE 的明确时间点
提到更换 RPC 或现有供应商能力缺口
给出欧洲节点、故障切换或多链支持等具体要求
能够补充调用量级、链范围或技术决策人

凌晨一点，一个卖 RPC 服务的销售又刷完了一轮群。项目方群、开发者群、Web3 基建群，他盯了十几个，翻了三个小时，最后确定了一件事：群里聊 RPC 的人很多，但没一个是他能跟进的。

不是没有需求。需求每天都在出现——有人抱怨“节点又挂了”，有人问“有没有支持欧洲节点的 RPC”，有人发“主网上线前想换一家”——但他分不清哪些是真需求、哪些是技术讨论，等他确认了，对方往往已经定了。

这个行业的窗口短得离谱：项目方 TGE（代币生成事件）前 2-4 周才需要 RPC 方案，窗口一过就没了。 他看到需求的时候，通常已经是对方比完价、准备签约的时候。

但同一个周四，他的工作方式变了。他打开的不是群列表，而是 TOP Prospect 的工作台——前一天系统已经把他连接的高相关群里的消息整理成了候选记录。他花了十五分钟看完，标掉两条技术讨论，把一条“主网上线前要换 RPC”的消息标成待跟进，然后才去私聊。

晚上他算了笔账：以前刷三个小时群，抓到的是“看起来像需求”的东西；现在看十五分钟记录，抓到的是“值得去核实”的东西。差别不在时间，在抓到的对不对。

这篇文章就写这一个人：一个卖 RPC 服务的销售，用上 TOP 之后多了什么。你会看到产品帮他整理了什么、排序了什么、保留了什么，也会看到哪些事产品永远不替他做——判断、开口、成交，一直在人这边。

NOTICE：本文中的团队、群消息与业务条件均为合成示意，用于演示产品工作方式，不代表真实客户、真实群聊、合同、收入或转化结果。

用之前：三个让他原地打转的问题

问题一：这个群里，买卖双方说同一种话。

RPC 生态有个特殊之处：需求方和供给方挤在同一个群，而且说几乎一样的话。 项目方说“求推荐 RPC”，服务商也说“推荐我们的 RPC”——同一个词，一个在花钱，一个在赚钱。他每天看到的“RPC 讨论”里，一半是同行在吆喝，一半是技术交流，真需求混在里面，像大海捞针。

问题二：技术讨论和真需求，长得一模一样。

“节点 429 了”——这是技术讨论，还是想换供应商的前兆？“主网上线前要换带 failover 的 RPC”——这是随口聊聊，还是已经进入选型？光看单条消息，根本分不出来。 他吃过亏：有一次追着一个“429 报错”聊了半天，结果对方只是路过吐槽，自己项目用的不是他家的竞品；另一次，“下个月上线想换 RPC”他没当回事，两周后对方已经签约了别家。

问题三：窗口太短，看到了也来不及。

就算认出了真需求，RPC 的选型窗口也就 2-4 周——从项目方开始找，到确定供应商，快到超出想象。他经常是“看到了需求，但看到的时候对方已经比完价了”。 不是需求不存在，是他看到的永远是需求的后半程。

这三个问题叠在一起，就是“天天在群里，月月没单子”。

用之后：产品帮他做的三件事

第一件：把“项目方群”和“同行群”分开，信号源先对了

他重新整理了监控源。TOP Prospect 只处理他主动连接、有权访问的群——他把项目方聚集的群（Web3 项目讨论群、基建选型群、开发者群）设为需求来源，把 RPC 服务商交流群设为行情观察（只用来摸市场动态，不进销售队列）。

结果：以前十几个群混着看，现在需求源只剩五六个，但每一条都更值得看。 因为真正会买 RPC 的项目方，在项目讨论群里，不在同行互推群里。他第一次意识到：不是群不够多，是之前把一半时间花在了看同行身上。

这一步对应的产品能力是监控源管理：群由你选，不是系统替你加群。需求源和行情观察分开，同行群只做行情，不进销售队列。

第二件：一条“想换 RPC”的消息，变成一张带证据的线索卡片

他以前靠肉眼从讨论里捞的“想换 RPC”，现在在系统里长这样：

字段	内容
业务分类	RPC 服务替换需求（商机类）
原文	（完整消息原文，一字不差）
来源	XX Web3 基建选型群 · 发言者 ID
时间	2026-08-07 01:32（UTC+8）
AI 分数	按基础分、信号强度、重要程度、关键词数量、时效、重复提及次数等因子计算，给出 0-100 的排序分和“高优先级/重要/一般”分级
判断依据	命中“主网上线/换 RPC/failover”；语义判断为真实项目方表达替换需求，非技术讨论或同行引流
状态	新线索

这张卡片解决了他前两个问题： 原文、来源、时间、上下文全在，能跳回原消息核实——“技术讨论还是真需求”，他不用靠猜，看记录里的上下文就能判；分数只告诉他“先看哪条”，判断还在他手里，但他终于不用从讨论里肉眼捞了。

这一步对应的产品能力是提取规则 + 线索整理：你用业务语言定义“什么算值得看的事件”（比如“主网上线/换 RPC/需要 failover”），关键词粗筛、AI 判断意图。产品整理和排序，事实判断永远由人结合原文核实。

第三件：给每条线索标状态，让“窗口期”不再靠记

他现在给每条线索标状态：新线索 → 待跟进 → 已跟进 → 已转化（终态），或标为无效（可恢复）。标无效时顺手记一句原因——“对方是技术讨论”“窗口已过”“已选别家”。

月底复盘时，这些“无效原因”变成了最值钱的数据：哪类消息其实是技术讨论（该排除）、哪类需求老是跟进太慢（该提速），一眼就看得到。他把“节点 429”这类纯技术讨论加了排除词，把“主网上线 + 时间点”的组合提了权——下个月的候选，更像他真会点开看的。

这一步对应的产品能力是状态流转：状态是团队在系统里手动更新的，产品不读取私聊、不知道你们有没有成交，它只记录团队标的状态。谁跟进、怎么谈，永远是人的决定。

一条完整链路：从“想换 RPC”到一单试客户

用他真实的处理流程走一遍。

周二，一条消息出现在 Web3 基建选型群：

“我们项目下个月主网上线，现在的 RPC 不支持欧洲节点，也没有故障切换，想换一家，有推荐的吗？”

系统判断： 命中“主网上线/换 RPC/failover”——替换需求。语义判断：有具体业务（“我们项目”）、有明确时间（下个月上线）、有具体能力要求（欧洲节点、故障切换）——是真实项目方，不是技术讨论或同行引流。

他打开记录： 原文、来源群、时间、判断依据全在。他点开这个发言者的历史——上周这人还在群里问过“跨链调用用哪家 RPC”，是常驻老号，可信度高。标成待跟进。

他私聊，开场用的是卡片里的上下文：

“在 XX 基建选型群看到您说下个月主网上线，想换支持欧洲节点、带 failover 的 RPC。想先确认下：大概的调用量级是多少？目前主要在哪些链上跑？”

为什么这么问：RPC 不是“有和没有”的问题，是“扛不扛得住”的问题。 调用量级决定需要什么配置，链的数量决定要不要多链支持——先问清量级和链，才能判断能不能接、报什么方案。这不是打探，是帮他定位需求。

对方回话： 主网月活预计 5 万钱包，主要在以太坊和一条 L2 上跑，当前供应商在东南亚区域延迟高，想换一家有欧洲节点的。

这句话就是窗口。 他没急着报价，先发了一份“主网上线前 RPC 选型检查清单”——节点分布、故障切换、限流策略、SLA，让对方的 CTO 按清单自查一轮。对方觉得他懂行。

周五，对方主动问： “你们欧洲节点延迟大概多少？能不能先开个测试 key 跑两天？”

他在系统里把状态从“待跟进”改成“已跟进”，记下：测试 key、决策人是 CTO、选型原因是“欧洲节点 + 故障切换”。 两周后测试稳定，对方进入正式签约流程，状态更新为“已转化”。

复盘时他记了一条规则： “主网上线 + 时间点 + 具体能力要求”这个信号组合，几乎都是真实需求——“下个月上线”这个时间点特别值钱，因为它意味着窗口刚开、还没进入比价，优先级直接提权。

回到那句话：产品到底帮了他什么

他没换行业、没换客户、没换话术。他换的只是把时间花在哪里：

	用之前	用之后
找信号	刷十几个群、三小时，抓到“看起来像需求”的	看整理好的候选记录，十五分钟，抓到“值得去核实”的
分真假	靠猜，技术讨论和真需求分不清	原文、上下文、历史全在，随时核实
赶窗口	看到需求时对方往往已经比完价	在窗口刚开时就标成待跟进
结果	天天在群里，月月没单子	同一个销售，同样的时间，接住了过去会错过的消息

但有三件事产品永远没替他做：

没替他判断真假——AI 分数只排序，“先看哪条”是它的事，“这条是不是真的”永远是他回到原文核实
没替他联系客户——产品不读取私聊、不自动发消息，开场白是他自己写的
没替他成交——状态是他在系统里手动标的，产品不知道他们有没有谈成

产品帮他做的是整理和排序，剩下的判断、开口、成交，一直在人这边。 而恰恰是这层“整理”，把他从“刷群的销售”变成了“看记录的销售”——他抓到的终于不是“看起来像需求”的东西，而是“值得去核实”的东西。

主网上线前三周才看到需求，以前靠运气，现在靠记录——一个 RPC 服务商销售的变化