Recommendation Signal Guide
如何在 Twitter 上找到正在问工具推荐的人，让团队看到更暖的 intent signal
公开 asking for recommendations 的人，常常会顺带说明 use case、紧迫度和 buying context。更强的流程，不是把所有工具词都当成 lead，而是看 recommendation language 加来源 qualification。
1. 先定义你关心的 recommendation use case
更好的起点，是先定义一个场景，比如 social listening、brand monitoring、customer research 或 analytics。
问题越具体，这些 request 离你的真实 demand pattern 就越近。
- 先选一个 recommendation use case。
- 列出 request 和 recommendation language。
- 定义什么样的请求算 strong intent。
2. 保留请求背后的上下文
一条有价值的推荐请求，往往会说明为什么要问、在考虑哪些工具，以及想解决什么问题。
这些上下文决定它是不是值得进入商业流程。
- 保留 problem 和 workflow language。
- 有 comparison 和 urgency 就一起记录。
- 把 general curiosity 和 active evaluation 分开。
3. 先做来源 qualification
不是所有 recommendation thread 都适合进销售流程。更好的做法，是先看 role、company 和商业相关性。
这一步能帮助团队长期保持 signal 质量。
- 重要 request 都看 role 和 company 背景。
- 把 likely buyer 和生态评论者分开。
- 记录为什么这个 request relevant。
4. 最终做成 recurring recommendation list
一份 recurring 的 qualified request list，通常比零散截图更适合 founder-led sales 或市场学习。
它也能帮助团队看到哪些 use case 的 demand 在变强。
- 每轮都用固定 request-list 模板。
- 按 use case 或 urgency 分组。
- 根据真实 request 质量不断修正搜索逻辑。
团队在 Twitter 上找推荐请求时，常会问这些问题
这些问题通常会在 recommendation language 需要服务真实需求发现时出现。
为什么 recommendation request 是强信号？
因为发帖人往往会顺带说明自己要解决什么问题和想找什么工具，这比被动 mention 更接近真实需求。
是不是所有 recommendation thread 都是 lead？
通常不是。更好的做法是先看 use-case fit、来源相关性和是否有 active evaluation 迹象。
什么样的 request 值得保留？
workflow need 具体、来源可信，而且有评估或紧迫语境的 request，通常更值得保留。
团队怎么验证这条流程？
选一个 use case 跑一轮 recommendation review，看看 resulting list 是否比一般市场浏览更接近真实 demand。
和 recommendation signal 常一起看的页面
如果 recommendation 和 replacement intent 高度重叠，可以接着看这页。
如果 request 大多来自 startup founder 和 operator，也可以看这页。
如果 recommendation signal 需要进入更大的销售监测流程，可以接着看这页。
如果下一步想看如何把这条流程技术化，也可以看这页。
把 recommendation request 变成稳定的 demand list
如果你的团队已经会在 Twitter 上看到有价值的 recommendation thread，下一步通常就是把它整理成 recurring discovery 和 qualification 流程。