方向：AI 副业实操 / AI 工具变现
案例性质：供应商公开客户案例，结果为案例方披露，非独立审计；把它当作交付结构参考，不当作收益承诺。
很多人卖“AI 自动化”，交付的却是一堆节点截图。客户不会为节点付费，只会为一个原来很慢、很容易错、又影响成交的业务动作付费。
n8n 公布的 System AI 案例给了一个较完整的样本：这家服务房地产客户的自动化咨询机构，把团队原本在 WhatsApp、Zoho CRM 和 Google Sheets 之间反复搬运的信息，改造成可核验的工作流。客户发文字或语音，系统识别意图、转写语音、查询或更新 CRM/表格，并把写入位置回传给团队确认。[3]
这不是“做个机器人”的故事，而是一个可以出售的业务流程改造包。
1. 客户真正购买的是什么
案例中的人工环节是重复数据录入：团队从 WhatsApp 把线索和房源信息复制到 Zoho CRM、表格和备注系统。System AI 的交付不是替客户换掉全部系统，而是保留员工原本使用的 WhatsApp，把它做成入口；后端负责结构化、路由、写入与确认。[3]
按 n8n 记录，单个任务从约 4–5 分钟缩短到约 10–20 秒；案例方还称，按该客户的业务量估计每周约节省一天，房产从 onboarding 到销售的周期从 62 天降到 44 天。[3]
这里最值得学的不是“97%”这个数字——它属于特定客户、特定流程，不能照搬到你的报价单——而是它把价值锚定在三件可测的事上：
- 任务耗时：一条消息从进入到完成写入需要多久；
- 错误与返工：错写、漏写、重复录入的数量；
- 业务后果：线索响应、交付周期、销售推进是否改善。
没有这三项基线，AI 自动化就是演示；有了它们，才可能是一项服务。
2. 这个方案的最小可售版本
不要一上来承诺“给你做 AI 员工”。先卖一个 7–14 天能上线、边界清楚的流程。
适合先做的流程
- 微信/WhatsApp/表单 → CRM 的线索录入与分配；
- 语音消息 → 转写 → 结构化字段 → 待确认的工单；
- 报价、预约、售后记录的跨表格同步；
- 每日汇总：未处理线索、异常订单、缺失字段。
交付包应该包含什么
| 层 | 必须交付 | 为什么不能省 |
|---|---|---|
| 业务定义 | 触发条件、输入字段、完成标准、例外清单 | 避免“什么都能做”的无限范围 |
| 工作流 | 读取、判断、写入、回执四段 | 让客户知道系统实际做了什么 |
| 人工确认 | 高风险写入前的审批或回执 | 防止模型把猜测当事实写进 CRM |
| 观测 | 执行日志、失败告警、每周错误复盘 | 上线后才能持续证明价值 |
| 交接 | 账号权限表、回滚方式、维护边界 | 不把客户锁死在个人手里 |
System AI 的案例中，系统会把已创建表格记录的确切链接回传给团队；它也记录成本和消息日志。[3] 这两个细节很重要：自动化不是“跑了就行”，而是要能让业务人员快速确认“它到底写到哪里了”。
3. 报价前先问的 8 个问题
把下面的问题做成诊断表，而不是直接报价：
- 这个动作一周发生多少次？
- 每次人工完成需要几分钟？
- 错一次会造成什么后果？
- 输入来自哪些系统，谁拥有访问权限？
- 哪些字段允许自动写入，哪些必须人工确认？
- 失败时谁接手，多久必须处理？
- 是否包含个人信息、客户合同、财务或健康数据？
- 客户是否愿意用上线前后同一套口径测量结果？
如果对方答不清前四题，先做流程梳理；如果答不清后四题，不要直接接“全自动”项目。
4. 变现路径：先服务，后产品化
这类项目的合理路径通常是：
- 付费诊断：画出现有流程、数据权限与损耗基线；
- 固定范围试点：只改一个高频流程，约定验收指标；
- 月度运维：监控失败、更新接口、复盘异常；
- 可复用模板：当同一行业连续出现相同流程时，再沉淀为行业包。
不要把“会 n8n / 会调模型”作为商品。把商品定义为“让某类团队的某项业务动作可追踪地更快、更少错”。
5. 三条不能省的底线
- 权限最小化：模型不应天然拥有删除、付款、发送合同或批量改库权限。
- 人留在关键节点：金额、客户状态、法律承诺、对外发送，应有审批或抽检。
- 不承诺万能 ROI：案例数据只能说明该案例方的结果；你的项目必须在客户自己的数据上重新测。
结论
AI 自动化服务最容易卖出的不是“一个聪明的 Agent”，而是一个有输入、有完成标准、有回执、有异常处理的流程。先用一个能量化的痛点拿到第一个交付，再谈把它扩成“AI 员工”。