涨价公告发出去之后，我从群里翻出三个时间点

周五下午三点二十分，你照常打开 Telegram，翻到那个关注了半年的竞品用户群。屏幕上弹出一张截屏——一封涨价通知的邮件正文，发消息的人什么都没写，只配了一个瞪眼的表情。

接下来 72 小时，群里的消息会经历三轮变化。每一轮的内容不同，告诉你的事情也不同。

头两个小时——喊得最响，信息量最少

涨价公告出现在群聊后的几分钟到两小时内，消息列表快速滚动。下面是一段示意性对话（综合多个群在类似场景下的常见表达方式，非真实用户对话，仅用于演示判断过程）：

用户 1（15:22）： [邮件截屏] 😳 用户 2（15:25）： 含税还是不含税？一个月涨快两百，年付的话受不了。 用户 3（15:31）： 有没有别的可以用？求推荐。 用户 4（15:40）： 我们团队二十多人，这一涨一年得多交好几万。老板迟早要问。 用户 5（15:48）： 刚发工单问老客户能不能锁价，有回复了说一声。

这一轮的特点是情绪密度高、信息颗粒粗。用户 2 关心价格含不含税，但没说自己能接受的价位；用户 3 问替代方案，但没有点名任何具体产品；用户 4 提到”好几万”，但没有给出精确数字；用户 5 在等客服回复——他的下一步不取决于自己，取决于对方说什么。

这时候最自然的冲动是记录一条”竞品涨价引发群内大量不满，可能存在客户流失风险”。这条记录不能说错，但也说不上有用——你不知道谁会走、什么时候走、走向哪里。

第 12 到 24 小时——有人停下来了，在算账

涨价公告贴出半天到一天后，群里的发言频率明显下降。但留下来的消息比第一轮更容易读出信息。

下面是这段时期的示意性对话（综合表述，非真实用户对话）：

用户 6（凌晨 1:02）： 刚算完。标准版 ¥499→¥699，我们 16 个席位，年付差额 16×200×12 = 38,400。[配了一张 Excel 截屏] 用户 7（凌晨 1:20）： 我们是 30 个席位，用量还大。我导了去年一年的用量报表，发现预留的冗余空间超过 40%。真要省的话完全可以降级到低一档方案。 用户 8（凌晨 1:45）： @用户 6 你们合同什么时候到期？我们 11 月，刚好在 8 月涨价之后，到时候续约肯定按新价格。 用户 6（凌晨 1:50）： 我们 10 月。我打算下周约销售聊一下，看能不能锁老价格续一年。

这一轮的变化不在于人数多少，而在于行为类型变了。

用户 6 花了时间算差额——16×200×12。这个乘法本身很简单，但他愿意做这件事，说明价格变动已经进入他的个人工作清单。用户 7 做了更多：他导出了用量报表。不管他说的”冗余 40%“是否准确，导出报表这个动作本身比发一条”太贵了”的消息至少多花 15–20 分钟。

用户 8 和用户 6 之间出现了一个新的对话元素：合同到期日。10 月、11 月——这是两个具体的决策截止时间。涨价生效日是 8 月 1 日，合同到期在 10 月或 11 月，中间有 2–3 个月窗口。如果你关心这批用户接下来的动向，可以把回访时间设在这些时间段附近。

但这一轮仍然有不确认的东西。用户 6 说”下周约销售聊”——这个”下周”会不会被其他事情挤掉，从群消息里看不出来。用户 7 导出了报表，但他导出之后是降级、换供应商还是什么都不做，消息里没有下文。凌晨的发言时间也可能只是因为白天工作太忙，不是因为他焦虑到睡不着。

第 48 到 72 小时——问题从”有什么替代”变成了”怎么换”

涨价公告过去两天到三天。如果你一直看着这个群，你会注意到一个转折点：有人开始问迁移的细节了。

下面是第三段示意性对话（综合表述，非真实用户对话）：

用户 9（第三天的上午 10:30）： 有人在用 Product A 吗？我想确认几件事：application programming interface（以下简称 API）的调用次数限制是多少，每分钟还是每小时？历史数据能不能批量导出、导出的格式和字段映射怎么处理？从现在的平台迁移过去大概要多少时间？ 用户 10（10:45）： 我之前试用过 Product A。API 限频文档写的是每分钟 500 次，实际测试大概能到 420 到 450。批量导出有，默认是 CSV，字段映射要自己配。如果数据量在 20 万条以内，一个周末应该能跑完。 用户 9（11:20）： Product B 有人试过吗？我想要一个两边的对比，不只看价格。 用户 11（12:05）： 我们去年从你现在用的这家换到了 Product B。遇到一个坑：导出历史记录时，附件链接的格式不兼容，弄丢了大概一百多张关联图片。前后花了一周半处理完。如果数据完整性要求不高，Product B 的价格确实低一截。

到了第三天，群里的核心问题是”怎么换”——这是第一轮和第二轮都没有出现的新行为。

用户 9 问的三个问题指向同一个方向：迁移可行性。API 调用次数限制决定了他的技术系统能否顺利对接；批量导出决定了他能不能把自己的数据拿回来；迁移时间决定了他需要投入多少人力。这三个问题同时出现，说明他已经跳过了”要不要换”的初步阶段。

用户 10 和用户 11 的回复里有具体数字——每分钟 420–450 次、20 万条、一个周末、一百多张图、一周半。不管这些数字的真实精度如何，在群聊语境中它们构成了可供参考的迁移成本估算。

跟第一轮说”求推荐”的用户 3 比，用户 9 的提问质量完全不同。说”求推荐”只需要 5 秒；列出三个具体迁移问题需要先想清楚自己的技术环境和关键约束条件。能做到后者的用户，至少已经在自己心里完成了”值得考虑换”的判断。

现在你能做的三件事

把三轮变化放在一起，你可以为每条线索标注不同的优先级。

第一轮出现的账号，你需要的是时间——等到至少有人开始算账，再判断这批人中哪些是认真的。

第二轮留下的几个具体信息——38,400 元的年差额、“冗余 40%“、10 月和 11 月的合同到期日——足够你决定在哪个时间点再次关注这些用户的行为。

第三轮出现的用户 9、用户 10 和用户 11，是你目前最值得花时间人工核对的三个账号。核对的优先级不是因为他们”要走了”，而是因为他们留下了可供交叉验证的具体信息：Product A 的真实 API 限频、Product B 的数据导出兼容性。这些信息你可以用几分钟对照公开文档或试用环境验证——如果验证后与群内描述存在差异，这条线索的价值还会更高。

下一次打开群的时候

从公告截屏到第三天中午，刚好过去 72 小时。现在再往下翻，群里的最新消息可能已经和涨价无关——有人在问版本更新，有人在贴使用技巧。

涨价的讨论没有消失，但它的内容已经从”太贵了”变成了”我算过了”和”怎么迁移”。这两句话之间隔着的，是你在从第一轮到第三轮的判断过程中得到的东西——不是每一个喊”太贵了”的人都会走到”怎么迁移”那一步，但你至少知道了走到那一步的人长什么样。

下次再看到另一家竞品的涨价通知贴进群里，你打开手机，先把时间点标好。第一波消息刷过去之后，第二天和第三天才是真正值得你翻开看的。

研究与定义

值得关注的潜在线索 Signal 是怎样被发现的

了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。

查看方法论与核心定义 →