Plumb 失败拆解：工作流做得很顺，为什么市场还是没有启动

G｜增长系统：会搭流程，离留下用户还差四个动作

AARRR 要拆到“结果被采用”

O｜市场机会：自动化工具与工作流市场是两门生意

三层市场

S｜战略定位：把“工作流订阅”当成产品创新，也把它变成了验证负担

创始人的三条“做对”

创始人的三条“做错”

关停与团队去向要分开看

C｜竞品分析：连接器、运行责任和分发入口决定替代压力

P｜产品设计：先把一次成功变成可负责的重复运行

七步责任链

1. 发现任务。 产品先从销售线索、招聘筛选、客服分流或内容再利用等具体职能进入，而不是先让用户浏览一堆通用模板。每个模板都要写清输入、输出、预计运行成本、人工确认点和失败后的处理方式。
2. 试跑真实数据。 用户应使用自己的样本测试流程。产品要同时展示模型输入、结构化输出、错误分支和人工修改，避免演示数据让用户误判结果质量。
3. 接入业务系统。 工作流需要使用稳定的 API trigger、webhook、MCP 或 iPaaS 连接；Plumb 创始人已经指出，早期设计限制了这些接入方式。2
4. 确认高影响动作。 发邮件、改 CRM、筛掉候选人、改变客户状态等动作要在执行前获得人确认，并保存确认人、输入和时间。
5. 监控与回滚。 系统要记录每一步的输入输出、模型版本、重试次数和失败原因，让用户可以重跑单步、恢复上一版本和撤销外部动作。
6. 按结果计费。 平台不能只按 token 或步骤收费。团队要知道一个合格结果花了多少模型、存储、审核、支持和人工修改成本，再决定按次、按席位还是按结果收费。
7. 迁移与退出。 用户要能导出工作流定义、提示词、结构化 schema、运行日志、凭证引用和版本关系；创作者要能带走自己的模板和订阅数据。平台若停止服务，退出能力应当和日常使用一样清楚。

E｜商业模式：创作者分成建立在每次运行有真实价值之上

四条收入路径

L｜洞察提炼：把流程做成商品，先要证明它值得重复购买

1. 技术上能组合，不等于业务上值得运行

2. Marketplace 的冷启动比单一工具更难

3. 集成能力属于价值本身

4. 团队被新的公司接住，不等于旧产品已经成功

D｜决策分析：先做一个可重复的职能，再决定是否开放市场

给创始人

给投资人

1. 要求团队展示从首个有效结果、第二次运行、第二类任务到 D90 的 cohort 表。融资额、模板数和累计运行次数只能说明投入或活动量。
2. 把“技术会被平台吸收”与“独立产品能赚钱”分成两种退出情景。Plumb 的团队去向说明人才有买方价值，不能代替独立经营数据。4
3. 要求团队把连接器、授权、日志、人工确认、回滚和支持成本算进单位经济。只计算模型调用费，会低估工作流产品的真实成本。
4. 在开放 marketplace 前，先问清楚谁承担模板错误、下游系统误写、用户退款和创作者退出后的维护责任。

给采购方与产品负责人

1. 用 20 个真实任务比较 Plumb 式模板、n8n、Zapier、Gumloop 和现有内部工具，记录首个有效结果、第二次运行、人工接管和每次任务全成本。
2. 采购前要求导出工作流定义、提示词、schema、运行日志、版本关系和凭证引用；只允许下载最终结果，团队仍然无法迁移完整流程。
3. 先选择低风险、结果可审计的任务，例如线索整理、会议摘要和内部知识归档，再逐步扩大到发信、改 CRM、招聘筛选和财务动作。
4. 把高影响动作的事前确认、权限撤销、错误回滚、删除证明和供应商退出演练写进验收条件。

90 天验证计划

• 第 1—30 天： 选择一个职能，例如销售线索整理。让 30 个团队使用同一类真实数据，记录首个合格结果率、人工修改分钟数、首次写回时间和第二次运行率。
• 第 31—60 天： 增加第二类任务，例如把线索判断写回 CRM 并生成待确认邮件。记录第二类任务采用率、人工接管、错误副作用、撤销成功率和失败后的继续使用。
• 第 61—90 天： 引入 3 个外部创作者，比较自有模板与外部模板的 D30、运行频次、结果采用率、创作者收入和平台贡献毛利。只有当 D30 第二次运行率超过 45%、第二类任务采用率超过 30%、关键撤销成功率达到 99%、日志完整率达到 99%，并且贡献毛利为正时，团队才应扩大 marketplace 与连接器。