SaaS 礼宾式 MVP：先人工服务客户，再决定哪些环节自动化

开场：不是所有 MVP 都要先写完整系统

很多 SaaS 创始人把 MVP 理解成“功能少一点的软件”。

但在真正不确定的早期，你还不知道客户是否愿意改变流程，也不知道结果是否足够有价值。此时先写完整系统，可能是在自动化一个没人愿意买的流程。

礼宾式 MVP 的思路是：先用人工和半自动方式替客户完成关键结果，再决定哪些环节值得产品化。

礼宾式 MVP 验证的是结果

客户不关心你背后是脚本、表格还是完整系统。客户先关心结果是否有用。

例如你想做客服质检 SaaS，可以先：

• 让客户导出一批会话。
• 你用脚本和人工标注生成质检结果。
• 每周交付一份问题报告。
• 和客户一起复盘是否能改善管理。

如果客户连这个结果都不愿意看、不愿意付费，再做自动化意义不大。

什么时候适合礼宾式 MVP

如果结果已经确定、流程很标准，可以直接做轻量产品；如果不确定，礼宾式 MVP 更稳。

设计一条可交付流程

礼宾式 MVP 不能随意服务。要像产品一样设计流程。

没有流程的人工服务，很快会变成混乱外包。

把人工步骤当成未来产品需求

每次人工处理时都要记录：

• 哪一步重复最多。
• 哪一步最容易出错。
• 哪一步客户最关心。
• 哪一步需要专业判断。
• 哪一步客户愿意自己配置。

产品化不是把所有人工都自动化，而是先自动化高频、低判断、可规则化的部分。

收费不要等到完全自动化

如果礼宾式 MVP 交付了真实结果，就可以收费。

收费方式可以简单：

• 一次性试点费。
• 每月固定服务费。
• 试点费可抵扣正式订阅。
• 按处理数据量收费。

客户愿意为半自动结果付费，是很强的需求信号。

防止礼宾式 MVP 变成外包

危险信号：

• 每个客户都要求不同输出。
• 结果无法标准化。
• 客户只买你的人工时间。
• 没有任何步骤可复用。
• 你越来越忙，但产品没有变清楚。

每做一个客户，都要沉淀模板、规则、脚本和界面草图。否则就是服务生意，不是 SaaS 验证。

退出标准要提前定

礼宾式 MVP 不能无限做。

可以设置 4 周周期：

周期结束必须有判断，而不是继续“再服务看看”。

落地建议

选一个客户最想要的结果，用人工和脚本设计一条 4 周交付流程，并明确价格、输入、输出和成功标准。

SaaS 从 0 开始，礼宾式 MVP 的价值是用最低开发成本发现客户真正愿意为哪个结果付费。