# 拿到 SaaS 前 100 位激活用户：从 0 到 1 的分发指南

> 面向技术创始人的实操指南：定义激活动作、选择合适渠道，并用可重复的方式获得 SaaS 前 100 位真实用户。

Source: https://tomako.ai/zh/blog/first-100-saas-users-zero-to-one-distribution-guide
Updated: 2026-09-19

SaaS 的前 100 位用户，不是数据库里的 100 个邮箱。这份指南会帮助技术创始人定义激活、选择渠道、从早期用户身上学习，并建立可重复的分发路径。

## 先定义“激活”，再谈注册量

SaaS 的前 100 位用户，不应该只是数据库里的 100 个邮箱。只有当用户完成了一个能证明产品价值的关键动作，才应计入“激活用户”。

对开发者工具来说，这个动作可能是第一次成功调用 API；对账单工具来说，可能是第一次完成发票核对；对监控产品来说，可能是第一次收到有效检测结果。

选渠道前，先写清楚你的**激活单位**：

> 一个符合目标画像的新账号，在 **[时间窗口]** 内完成 **[关键动作]**，就算激活。

这个定义能让获客数据更真实。它也能帮你判断：某个渠道带来的到底是潜在用户，还是只会点一下链接的人。

## 把前 100 位用户拆成三个检查点

从 0 到 100 不是一次营销活动，而是三个连续的诊断阶段。是否进入下一阶段，要看证据，不要只看日历。

| 检查点 | 核心问题 | 主要动作 | 可以进入下一阶段的信号 |
|---|---|---|---|
| 最初几位用户 | 目标用户能否在不依赖创始人全程救场的情况下获得价值？ | 直接观察、人工引导 | 多位目标用户完成激活；重复问题已被记录 |
| 早期小规模用户 | 一两个渠道能否持续带来意图相近的用户？ | 先回答问题，再做社区参与和小范围触达 | 同一渠道连续多周带来激活用户 |
| 向 100 位推进 | 有用内容能否持续带来自然发现，而不是依赖一次次上线活动？ | 技术内容、上游免费工具 | 新用户能从可重复的入口完成激活 |

这些是诊断阶段，不是适用于所有产品的硬门槛。企业级产品需要更多观察；简单工具可能更快进入下一阶段。

## 按用户的工作场景选渠道

渠道是否合适，取决于用户在哪里讨论问题，以及他们如何判断一个方案是否可信。

| 产品场景 | 更适合的起点 | 通常不适合作为第一步 | 原因 |
|---|---|---|---|
| 基础设施、API、CLI 工具 | GitHub Discussions、技术论坛、相关 HN 讨论 | 泛消费社交平台 | 用户需要技术细节、限制和实际证明 |
| B2B 工作流 SaaS | 直接联系一线操作者、小型行业社群 | 泛创业社区 | 用户更关心流程适配、风险和交接 |
| 小型开发者工具 | 可搜索的免费工具、针对具体问题的教程 | 泛展示广告 | 需求通常出现在排查问题的当下 |

产品目录可以制造一次集中曝光，但点赞不等于激活。Product Hunt 的[官方上线指南](https://www.producthunt.com/launch)把平台定位为接触广泛社区和收集反馈的机会。用户进入产品后做了什么，才是需要持续跟踪的数据。

如果你还在选择首发渠道，可以参考 [Product Hunt、Reddit 和 Hacker News 对比](/blog/product-hunt-vs-reddit-vs-hacker-news)。

## 引擎一：手工寻找同类用户

在最早阶段，效率来自更短的反馈闭环，而不是自动化。

1. 找到已经有人公开讨论的问题。
2. 用一段简短的技术说明讲清原理和限制。
3. 给对方一个低门槛的试用方式。
4. 观察安装或配置卡在哪里，记录原始报错和缺失信息。
5. 先解决反复出现的问题，再扩大触达范围。

默认先用异步文字和可运行示例。只有实时观察能回答关键问题时，再邀请对方通话。

主动说明限制更容易建立信任。例如：“目前支持 PostgreSQL 14–16，暂不支持只读副本路由。”这比“适用于任何数据库环境”更有用。

这一阶段的目标不是追求漂亮的回复率，而是确认真实用户能否获得价值。需要具体模板时，可以查看[面向开发者的冷启动触达指南](/zh/blog/cold-outreach-for-developers)。

## 引擎二：先解决问题，再提产品

当产品的基本使用路径已经可用，再进入相关社区。不要把求助帖当成广告位。

可以遵循以下做法：

- 在帖子里完整回答问题。
- 提供手动解决所需的命令、查询或判断方法。
- 如果提到自己的产品，明确说明你与产品的关系。
- 只有当产品确实能帮助当前读者时才放链接。
- 发帖前先阅读每个社区的规则。

这也符合 [Reddit 社区礼仪](https://support.reddithelp.com/hc/en-us/articles/205926439-Reddiquette)和 [Hacker News 社区规则](https://news.ycombinator.com/newsguidelines.html)：优先贡献有用内容，尽量引用原始来源，不要把社区参与变成单纯的自我推广。

可以这样做关系披露：

> 我做了一个处理这个流程的工具。上面的手动方法不依赖工具也能完成；如果你需要反复执行同一项检查，工具会更省时间。

读者先得到完整答案，再决定要不要了解产品。

## 引擎三：做一个上游免费工具

“用工程能力做营销”能否有效，关键看免费工具是否紧挨着付费产品的使用场景。

Webhook 产品可以提供浏览器端 HMAC 签名调试器；数据库代理可以提供连接池容量估算表。免费工具解决眼前的小任务，SaaS 解决持续出现的生产问题。

需要守住三个边界：

1. **先给结果，再谈注册。** 主要输出不应被表单挡住。
2. **能在浏览器本地处理的敏感数据，就尽量不要上传。** 如果必须经过服务器，要说明会发送什么、保存多久。
3. **把下一步说具体。** 清楚解释主产品解决的是哪个后续问题。

不要为了流量做与主产品无关的“爆款计算器”。只有能带来潜在激活用户的流量，才有长期价值。

更完整的判断方法见[工程化营销：为 SaaS 做免费工具](/zh/blog/engineering-as-marketing-build-free-tools-for-your-saas)。

## 贯穿案例：PostgreSQL 连接代理

假设一位独立创始人在做轻量级 PostgreSQL 连接代理，目标是帮助容器化应用避免连接数耗尽。

**激活单位：** 符合目标画像的团队在 7 天内，让一个测试工作负载通过代理完成一次有效查询。

**最初几位用户：** 创始人在公开讨论中看到部署期间连接耗尽的问题。三位工程师测试了二进制程序，其中两位因为环境变量说明不清而失败。创始人先改进 CLI 报错和安装文档。

**早期小规模用户：** 后续遇到类似问题时，创始人先解释手动连接池方案，再把开源代理作为可选工具。即使读者不点链接，回答本身也成立。

**向 100 位推进：** 创始人发布一个连接池容量估算表，写清假设条件。只有需要排队和运行时控制的团队，才会被引导到代理产品。

同一个真实问题，由此形成了产品改进、公开答案和长期获客入口。

## 用同批用户计算激活率

选择一批用户和一个固定时间窗口：

**同期激活率 = 在窗口内完成关键动作的合格新账号 ÷ 同期合格新账号总数 × 100%**

| 产品 | 较弱的信号 | 更合适的激活动作 |
|---|---|---|
| 开发者 CLI | 下载次数 | 第一次成功执行命令并得到有效结果 |
| 账单 SaaS | 注册账号 | 第一次完成真实发票或 webhook 核对 |
| 网站监控 | 创建账号 | 第一次配置目标并验证检测成功 |
| API 产品 | 访问文档 | 第一次带有效凭证完成 API 请求 |

建议用 7 天或 14 天作为清晰窗口。留存率、付费转化和收入要单独跟踪。[Amplitude 的免费增值与试用产品指标指南](https://amplitude.com/blog/freemium-free-trial-metrics)也采用相同思路：先定义代表首次价值的动作，再统计新用户中有多少人完成它。

接近 0 的激活率不等于产品一定没有价值。它说明你需要先检查渠道匹配、用户预期、引导流程和数据埋点，再决定是否增加流量。

## 一套可执行的分发清单

### 检查点一：观察

- 定义一个激活动作和时间窗口。
- 从公开讨论中找出 15–20 位可能的目标用户。
- 小范围邀请试用，并提前说明限制。
- 把重复出现的安装问题放进产品待办。
- 当多位目标用户不再依赖定制救场也能激活时，再进入下一阶段。

### 检查点二：重复

- 选择一两个真正匹配产品场景的社区。
- 保存少量问题关键词，持续观察。
- 先发布完整答案，再提产品。
- 测试一个与主产品紧密相连的上游工具。
- 当同一渠道在多个用户批次中都带来激活时，再扩大投入。

### 检查点三：积累

- 把真实支持问题整理成技术说明和示例。
- 让上游工具自然连接到后续生产问题。
- 每周检查从发现到激活的完整漏斗。
- 停止只带来访问、却不带来合格激活的动作。
- 用短而稳定的日常节奏，替代偶尔一次的大型发布。

[独立创始人的 30 分钟日常营销流程](/blog/daily-marketing-routine-solo-founders)提供了一套轻量节奏。

## Tomako 可以帮什么

最初几次用户沟通应该由创始人亲自参与。你需要听懂用户如何描述问题，也需要看到产品在哪里失效。

当信息来源变多后，[Tomako](/)可以帮助整理经过选择的市场信号，把产品上下文转成可审核的 GTM 草稿，并让后续事项保持可见。事实是否准确、内容是否发送、什么时候发布，仍由团队决定。

当协调工作开始占用大量时间时，再使用 Tomako。不要用工具跳过最关键的早期学习。

## 常见问题

### 前 100 位用户必须是付费客户吗？

不需要。本指南统计的是完成核心激活动作的合格用户。试用转付费和收入应作为独立指标。

### 每个创始人都应该去 Product Hunt、Reddit 和 Hacker News 吗？

不应该。先去目标用户已经讨论真实工作问题的地方。小型行业论坛可能比大型综合平台更有效。

### 什么时候适合自动化触达？

当目标人群、消息和引导流程已经通过手工方式验证后。过早自动化只会放大噪声，也会让你更难学到东西。

### 用户注册后不激活怎么办？

先检查路径，不要先加流量。核对渠道意图、落地页承诺、配置步骤、产品报错和数据埋点，再与受影响的用户直接沟通。

## 延伸阅读

- [Product Hunt、Reddit 和 Hacker News 对比](/blog/product-hunt-vs-reddit-vs-hacker-news)
- [面向开发者的冷启动触达](/zh/blog/cold-outreach-for-developers)
- [工程化营销：为 SaaS 做免费工具](/zh/blog/engineering-as-marketing-build-free-tools-for-your-saas)
- [独立创始人的 30 分钟日常营销流程](/blog/daily-marketing-routine-solo-founders)

## FAQ

### 前 100 位用户必须是付费客户吗？

不需要。先统计完成核心激活动作的合格用户，再单独跟踪试用转付费和收入。

### 每个创始人都应该去 Product Hunt、Reddit 和 Hacker News 吗？

不应该。先去目标用户已经讨论真实工作问题的地方。小型行业论坛可能更有效。

### 什么时候适合自动化触达？

当目标人群、消息和引导流程已经通过手工方式验证后。过早自动化通常只会放大噪声。

### 用户注册后不激活怎么办？

先检查渠道意图、落地页承诺、配置步骤、产品报错和数据埋点，再决定是否增加流量。