SaaS 人工交付实验：在写自动化之前，先用服务验证客户是否真要这个结果

开场：很多 SaaS 第一版不该先写代码

从 0 开始做 SaaS 时，创业者天然想写产品。注册、后台、自动化、报表、权限、通知，似乎这些东西上线后才算开始。但有些场景下，最好的第一步不是写代码，而是人工交付一次结果。

人工交付实验，也可以叫 concierge MVP。它的核心是：先不完全自动化，用人工、表格、脚本和简单工具帮客户完成目标结果，观察客户是否真的需要、是否愿意配合、是否愿意付费、哪些步骤最值得产品化。

这不是外包，也不是咨询。区别在于你不是靠人工永久赚钱，而是用人工学习产品应该长什么样。人工交付是早期 SaaS 的显微镜，它能让你看见客户价值和交付成本的真实结构。

什么场景适合人工交付

不是所有 SaaS 都适合先人工交付。适合的场景通常有几个特征。

第一，客户要的不是一个按钮，而是一个业务结果。比如生成一份可用于周会的质检报告、找出广告预算异常、整理销售线索优先级、输出门店整改清单。

第二，结果可以先用半自动方式做出来。你可以让客户给 CSV、截图、表格、文档，然后用脚本、表格模板、人工判断生成结果。

第三，客户愿意为了结果配合。比如愿意提供数据、参加复盘、解释字段、给出反馈。如果客户连这些都不愿做，说明痛点可能不强。

第四，交付过程能暴露未来产品模块。你可以通过人工步骤看到数据导入、规则配置、异常判断、责任分配、结果展示、复盘追踪等环节。

如果一个方向必须先开发复杂系统才能看到任何结果，人工交付难度会很高。但即使如此，也可以尝试拆出其中一个可手工验证的片段。

设计一个交付包

人工交付不能随意做，否则会变成无边界服务。要把它设计成一个小交付包。

一个交付包至少包括：

• 目标客户：谁适合参与。
• 输入材料：客户需要提供什么。
• 交付结果：你会给客户什么。
• 时间周期：多久完成。
• 客户配合：客户需要参加哪些会议或确认。
• 成功标准：什么结果算有价值。
• 不包含范围：哪些事情暂时不做。

例如：

“我们为电商客服主管做一次 7 天质检复盘实验。客户提供上周 200 条脱敏会话和现有质检规则。我们在 3 个工作日内输出问题分类、Top 5 高频问题、整改责任表和一次 45 分钟复盘。不包含自动系统对接、不包含客服绩效考核、不包含历史数据迁移。”

这个交付包很清楚。客户知道自己要提供什么，也知道能得到什么。团队也知道边界在哪里。

收费还是免费

人工交付实验是否收费，要看你的目标。如果你还完全不确定问题是否存在，可以免费做 2 到 3 次高质量样本，换取深度观察和反馈。但不要长期免费。只要客户已经认可问题，并且交付会消耗明显时间，就应该测试付费。

早期可以用付费试点，而不是正式订阅。比如 3000 到 20000 元不等，视客户类型和交付深度而定。价格不只是收入，更是信号。愿意付费的客户，会更认真提供材料、参加复盘、推动内部讨论。

免费客户也有价值，但要设条件：必须提供真实样本、必须参加复盘、必须允许引用脱敏反馈、必须讨论是否进入下一阶段。如果客户只想免费拿结果，不愿给任何承诺，就不是好样本。

交付过程要记录成本

人工交付实验的一个核心目标，是看清成本结构。每次交付都要记录：

没有成本记录，你会误判产品化难度。客户觉得结果很好，但如果每次交付都要 10 小时高级人工，未来价格和产品能力就要重新设计。反过来，如果某个步骤反复出现且规则稳定，就很适合进入产品。

人工交付不是为了证明你很努力，而是为了找出哪些努力可以变成软件。

不要把客户的定制要求都当成需求

人工交付时，客户会提出很多定制要求：“能不能顺便帮我看这个表”“能不能按我们部门格式输出”“能不能再加一个老板喜欢的图”“能不能把历史三个月也做了”。这些要求有些有价值，有些只是服务扩张。

判断时可以问：

• 这个要求是否和核心结果有关。
• 是否多个目标客户都会需要。
• 是否能形成标准流程。
• 客户是否愿意为它额外付费。
• 不做它是否影响试点成功。

如果答案大多是否，就先不做。可以记录下来，但不要让一次人工交付变成无限项目。早期团队资源很少，必须保护学习目标。

交付结果要能被客户内部使用

一个好的人工交付结果，不只是让对接人觉得有趣，而是能被他拿去和内部沟通。比如一页问题摘要、一张整改清单、一份预算异常列表、一张风险客户表、一份复盘模板。

如果结果只能停留在“你看这个分析不错”，很难转化为付费。要让客户能用它开会、汇报、分配任务、追踪责任。SaaS 价值往往不是分析本身，而是分析进入组织流程后产生的动作。

交付后可以问客户：

• 这份结果你会给谁看。
• 哪一页最可能进入周会。
• 哪个结论会改变你们下周动作。
• 如果每周都有这份结果，你会怎么使用。
• 这件事如果持续做，谁应该付钱。

这些问题能帮助你判断结果是否进入真实工作流。

从人工服务提炼产品模块

连续做 5 到 10 次人工交付后，应该整理产品化清单。不要凭感觉做，而是从交付记录里提炼。

常见产品化路径包括：

• 输入标准化：字段模板、导入校验、样本说明。
• 规则模板化：常见分类、判断条件、行业默认值。
• 结果自动化：固定报告、异常列表、状态看板。
• 协作闭环：负责人、截止时间、提醒、评论。
• 复盘沉淀：历史趋势、改进记录、成功案例。

优先产品化那些高频、高成本、规则稳定、客户明确认可的步骤。低频、强定制、需要大量专家判断的步骤，可以继续人工服务或暂时不做。

人工交付也要有退出标准

人工实验不能无限持续。开始前就要写退出标准。

可以设几类：

• 价值退出：连续 5 个客户都认为结果没有实际用途，暂停。
• 配合退出：客户不愿提供数据或参加复盘，暂停。
• 成本退出：每次交付人工成本过高且看不到产品化路径，暂停。
• 付费退出：客户认可结果但无人愿意讨论预算，重新审视客户类型。

退出不是失败。它说明你用较低成本发现了方向不成立，避免花更多时间开发。真正危险的是人工交付做了很多次，却没有复盘，没有收费测试，也没有产品化判断。

一次交付后的复盘模板

人工交付最怕做完就结束。每次交付后，团队应该用固定模板复盘。模板可以很简单：

复盘时要特别关注“客户最认可”和“客户最犹豫”。客户认可的地方，可能就是未来销售页面和产品主流程；客户犹豫的地方，可能是信任、数据质量、结果解释或组织推进问题。不要只听客户说“挺好”，要追问具体哪里好，准备用在什么场景。

另外，人工交付要沉淀样板。每做完一次，把输入模板、处理步骤、输出样式、复盘问题都保存下来。下一次交付不要重新发明流程，而是在上一次基础上改。连续几次后，你会拥有一套准产品流程：客户如何开始、系统未来要接收什么、结果如何呈现、客户如何行动。

当交付模板稳定到新人也能照着执行一半时，就说明产品化机会变强了。真正的 SaaS 不是把人工全部消灭，而是把最有规律、最有价值、最影响体验的人工步骤逐步变成系统能力。

判断是否继续人工交付

如果连续几次交付后，客户都能明确使用结果，并愿意讨论下一次交付或付费，说明这个方向值得继续。如果客户每次只是礼貌反馈，却没有内部使用场景，也不愿给下一步承诺，就要停止或调整。

一个简单标准是：人工交付是否同时带来客户价值和产品学习。只有客户价值，没有产品学习，会变成服务公司；只有产品学习，没有客户价值，说明结果不够重要。两者都有，才适合继续推进。

结尾：人工交付是为了更快做出软件

从 0 开始做 SaaS，不要把人工交付看成低级方式。早期最重要的是验证客户是否在乎某个结果，而不是证明你能写出完整系统。人工交付能让你先交付结果，再倒推产品；先看客户反应，再决定自动化；先理解成本，再设计价格。

只要边界清楚、记录完整、复盘严肃，人工交付就是高质量的产品发现方法。它会告诉你客户真正要什么、哪些步骤必须自动化、哪些服务可以收费、哪些需求应该拒绝。等你开始写代码时，产品就不是凭空想象，而是从真实交付中长出来的。