陈冉（化名）在 2023 年秋季开始公开构建一款面向 20 到 80 人电商团队的订单对账工具。他此前在一家 SaaS 公司做后端，离职后以一人公司形式接了两个小项目维持现金流。他的产品假设不是来自某个大创意，而是来自朋友公司财务每月用 Excel 处理平台账单的抱怨。他把构建过程写在公开日志里，从第 0 天开始记录每一次假设、Demo、访谈和报价。以下复盘以这些记录和后续访谈为线索，不把任何单次结果当作普遍结论。
这些日志的价值，不只是产品进度，而是它留下了“谁在什么条件下愿意继续谈”的痕迹。陈冉后来复盘时发现，早期很多让他兴奋的反馈，并没有进入任何合同；反而是几个不起眼的追问，最后指向了成交。
第一阶段：从模糊抱怨到可演示假设
第 0 到 14 天，陈冉列了五个潜在方向，包括发票识别、库存提醒、物流异常通知等。他用两个粗筛条件缩小范围：问题是否每月重复出现，以及能否对应到一个可量化的损失。他最后选中订单对账，是因为财务朋友反复提到“平台结算单和 ERP 数字对不上，月底要花三天手工找差异”。这个问题的损失可以按小时折算，责任人明确是财务，付费判断也相对直接。
他做的第一版 Demo 只覆盖一个平台的数据导出与差异标记，没有自动修账，也没有多账号管理。这个版本在技术上并不亮眼，但足以让对方点开一个具体场景。
第二阶段：社群曝光与礼貌好评
发布到独立开发者社群和两个电商运营群后，陈冉收到了点赞、转发和“有意思，关注了”等反馈。还有人建议增加汇率换算、多平台汇总、移动端提醒。他一度把评论条数当作验证。但随后做了两个动作，让他从热闹里冷静下来：一是统计七天里主动留下邮箱或预约演示的人数，结果只有 11 人留邮箱、2 人完成演示；二是补发了一份五个问题的问卷，其中“如果明天没有这个工具，你们会损失什么”几乎无人回答。
这些只是礼貌好评。它们说明话题有共鸣，但不能说明有人愿意为此承担一笔预算。
第三阶段：三次访谈里出现真正的付费信号
真正让验证往前走的是三次访谈。对象是一位电商公司财务、一位财务主管，还有一位代运营负责人。陈冉没有演示完整功能，而是问他们月底对账的流程。财务主管说，她每月最后三天要加班，如果差一分钱都要找原因；代运营负责人说，他需要给客户出对账单，但现在只能截图加 Excel。陈冉在访谈末尾加了一个试探性问题：“如果价格定在每月 300 美元，你会从哪个预算里出？”两位说有部门软件预算或代运营服务费，但不是马上；一位表示不会，因为已经在用另一套流程。
这个差异比社群数据更重要。预算归属、损失量化和替代方案意识，才是接近付费的信号。礼貌好评不会回答“从哪个预算里出”。
第四阶段：免费试用不等于成交
陈冉选了有预算归属的那家电商公司做 21 天免费试用。试用期内，对方只用上了订单匹配，没有用自动报告。每周反馈是“这里的数据格式要调整”“有几天漏了退货单”。21 天结束时，对方没有主动提出付费，只说“内部再讨论一下”。陈冉判断试用可能没有结果。转折发生在第 28 天，对方财务发来消息：如果加入“月度差异报告自动发送给主管”的功能，他们愿意签首年合同。合同金额约合每月 200 美元，按年预付。
这个客户不是从社群曝光直接来的，而是经过了访谈、定制条件、试用后的追加要求，才进入合同。免费试用只能证明功能可用，不能自动证明付费意愿。只有对方开始提出“加上什么就签”时，意愿才落到合同条款上。
第五阶段：把续约与流失分开看
之后三个月，陈冉签下第二个客户，来自那位代运营负责人推荐。第一位客户在首年结束后没有续约，原因是业务量下降，对账从每周一次降到每月一次，继续付费不划算；第二位客户续约并增加了两个席位。到复盘时，陈冉的公开记录里有 3 个付费合同：一个流失、一个续约、一个仍在免费试用后未决。这个结构很难用“成功”或“失败”一句话总结。如果只看社群反馈，会误以为产品被需要；如果只看首年流失，又会忽略仍有续约客户存在。
这个阶段更合理的描述是：早期收入只能覆盖一部分工具和云成本，距离稳定商业闭环还有明显距离。
哪些反馈能证明付费意愿
结合陈冉的记录，可以拆成两类信号。以下并非评分公式，只是一个基于案例的工作清单。
| 更接近付费的信号 | 只是礼貌好评的信号 |
|---|---|
| 明确说出预算归属：“走部门软件预算” | “这个想法不错” |
| 量化损失：“月底我要多花三天” | 点赞、转发、收藏 |
| 给出成交条件：“加 X 功能就签” | 只提功能建议，不给场景 |
| 追问合同、发票、数据安全 | “以后有需要再找你” |
| 试用后进入价格或条款谈判 | 社群活跃但不约演示 |
这个表的目的不是把反馈分成非黑即白，而是提醒：同一句话在不同语境下含义不同。比如“能不能加导出”如果是财务负责人在试用结束前提出，并且后面跟上“有导出我们就签”，更接近付费；如果只是社群评论，可能只是使用习惯。
这个案例成立的边界
陈冉的产品之所以能走出几个合同，有一些特定条件：
- 问题高频：电商对账每个月重复，损失可折算成加班时间。
- 决策链短：20 到 80 人团队里，财务负责人能直接动部门预算，不需要多部门审批。
- 交付可标准化：订单匹配和差异报告可以由一人维护，不依赖复杂实施。
- 客户量级可控：如果团队更大，会涉及数据权限、审计、集成和销售周期，一人交付风险显著上升。
这些条件不是所有 B2B 工具都具备。面向医院、政府、大型企业或强合规行业，同样的验证节奏可能失效。公开构建可以作为获客和记录，但不能替代对决策链和交付能力的判断。
结论：把曝光、试用、合同、续约拆开记账
陈冉的复盘说明了一件事：公开构建日志带来关注，但首批企业客户来自几件更冷静的事——追问对方的预算归属，接受试用后的追加条件，以及只承诺自己能交付的一个小结果。社群曝光和早期好评处在漏斗最上方，它们只是让开发者有机会进入访谈；真正能区分“有没有人愿意付钱”的，是合同、续约和流失这三个数字。3 个合同、1 个续约、1 个流失、1 个试用未决，这不是一个被验证的稳定生意，而是一个还在测试边界的早期样本。
暂无评论内容